Re: Latches and barriers
От | Andres Freund |
---|---|
Тема | Re: Latches and barriers |
Дата | |
Msg-id | 20150112162730.GC2092@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Latches and barriers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Latches and barriers
Re: Latches and barriers |
Список | pgsql-hackers |
On 2015-01-12 11:03:42 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > While it might not be required for existing latch uses (I'm *not* sure > > that's true) I think at least syncrep.c might not be correct. In SyncRepWakeQueue() it sets PGPROC->syncRepState without the necessary barriers (via locks), although it does use them in SyncRepWaitForLSN(). It is, perhaps surprisingly to many, not sufficient to take a spinlock, change the flag, release it and then set the latch - the release alone doesn't guarantee a sufficient barrier unless looking at the flag is also protected by the spinlock. > I still think that we should fix those XXX by actually > > using barriers now that we have them. I don't think we want every > > callsite worry about using barriers. > > > Agreed? > > Yeah, now that we have barrier code we think works, we should definitely > put some in there. The only reason it's like that is we didn't have > any real barrier support at the time. Master only though? If we decide we need it earlier, we can backport that commit lateron... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: