On Mon, Jun 12, 2023 at 07:24:18PM -0400, Stephen Frost wrote:
> * Nathan Bossart (nathandbossart@gmail.com) wrote:
>> Is it? I see uses in GiST indexing (62401db), so it's not immediately
>> obvious to me how it is debugging-only. If it is, then I think this patch
>> ought to clearly document it so that nobody else tries to use it for
>> non-debugging-only stuff.
>
> I don't see it as a debugging value. I'm not sure where that came
> from..? We do use it in places and if anything, I expect it to be used
> more, not less, in the future as a persistant generally increasing
> value (could go backwards on a crash-restart but in such case all
> unlogged tables are truncated).
This is my understanding as well.
>> My concern would be whether GetFakeLSNForUnloggedRel or CreateCheckPoint
>> might see an old value of unloggedLSN. From the following note in
>> README.barrier, it sounds like this would be a problem even if we ensured
>> full barrier semantics:
Never mind. I think I'm forgetting that the atomics support in Postgres
deals with cache coherency.
> The concern around unlogged LSN, imv anyway, is less about shared memory
> access and making sure that all callers understand that it can move
> backwards on a crash/restart. I don't think that's an issue for current
> users but we just need to make sure to try and comment sufficiently
> regarding that such that new users understand that about this particular
> value.
Right.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
