Re: Latches with weak memory ordering (Re: max_wal_senders must die)
| От | Robert Haas | 
|---|---|
| Тема | Re: Latches with weak memory ordering (Re: max_wal_senders must die) | 
| Дата | |
| Msg-id | AANLkTim1hLMGODNZNcAB2g3FRfNXkNTMhNKObjMUkRY6@mail.gmail.com обсуждение исходный текст | 
| Ответ на | Re: max_wal_senders must die (Bruce Momjian <bruce@momjian.us>) | 
| Ответы | Re: Latches with weak memory ordering (Re: max_wal_senders
 must die) | 
| Список | pgsql-hackers | 
On Fri, Nov 19, 2010 at 9:27 AM, Aidan Van Dyk <aidan@highrise.ca> wrote: > On Fri, Nov 19, 2010 at 9:16 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund <andres@anarazel.de> wrote: >>> So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses >>> spinlocks for that purpose - no idea where that is true these days. >> >> Me neither, which is exactly the problem. Under Tom's proposal, any >> architecture we don't explicitly provide for, breaks. > > Just a small point of clarification - you need to have both that > unknown archtecture, and that architecture has to have postgres > process running simultaneously on difference CPUs with different > caches that are incoherent to have those problems. Sure you do. But so what? Are you going to compile PostgreSQL and implement TAS as a simple store and read-fence as a simple load? How likely is that to work out well? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: