Re: Atomic ops for unlogged LSN
От
Nathan Bossart
Тема
Re: Atomic ops for unlogged LSN
Дата
Msg-id
20231109212733.GA1219183@nathanxps13
Ответ на
Re: Atomic ops for unlogged LSN (Andres Freund)
Список
Дерево обсуждения
Re: Atomic ops for unlogged LSN John Morris <john.morris@crunchydata.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN John Morris <john.morris@crunchydata.com>
Re: Atomic ops for unlogged LSN John Morris <john.morris@crunchydata.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN John Morris <john.morris@crunchydata.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN Stephen Frost <sfrost@snowman.net>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN Andres Freund <andres@anarazel.de>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Atomic ops for unlogged LSN Nathan Bossart <nathandbossart@gmail.com>
Re: Atomic ops for unlogged LSN John Morris <john.morris@crunchydata.com>
Re: Atomic ops for unlogged LSN Stephen Frost <sfrost@snowman.net>
Re: Atomic ops for unlogged LSN Andres Freund <andres@anarazel.de>
Re: Atomic ops for unlogged LSN Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote: > On 2023-11-07 11:02:49 -0600, Nathan Bossart wrote: >> Is there something special about all other backends being shut down that >> ensures this returns the most up-to-date value and not something from "some >> point in the past" as the stated contract for this function seems to >> suggest? > > Practically yes - getting to the point of writing the shutdown checkpoint > implies having gone through a bunch of code that implies memory barriers > (spinlocks, lwlocks). Sure. > However, even if there's likely some other implied memory barrier that we > could piggyback on, the patch much simpler to understand if it doesn't change > coherency rules. There's no way the overhead could matter. I wonder if it's worth providing a set of "locked read" functions. Those could just do a compare/exchange with 0 in the generic implementation. For patches like this one where the overhead really shouldn't matter, I'd encourage folks to use those to make it easy to reason about correctness. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления
От: Bruce Momjian
Дата: