From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | John Morris <john(dot)morris(at)crunchydata(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Atomic ops for unlogged LSN |
Date: | 2023-11-08 01:18:11 |
Message-ID: | 20231108011811.elqq3e67burgik7x@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-11-07 00:57:32 +0000, John Morris wrote:
> I found the comment about cache coherency a bit confusing. We are dealing
> with a single address, so there should be no memory ordering or coherency
> issues. (Did I misunderstand?) I see it more as a race condition.
IMO cache coherency covers the value a single variable has in different
threads / processes.
In fact, the only reason there effectively is a guarantee that you're not
seeing an outdated unloggedLSN value during shutdown checkpoints, even without
the spinlock or full barrier atomic op, is that the LWLockAcquire(), a few
lines above this, would prevent both the compiler and CPU from moving the read
of unloggedLSN to much earlier. Obviously that lwlock has a different
address...
If the patch just had done the minimal conversion, it'd already have been
committed... Even if there'd be a performance reason to get rid of the memory
barrier around reading unloggedLSN in CreateCheckPoint(), I'd do the
conversion in a separate commit.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-11-08 01:19:28 | Re: Show WAL write and fsync stats in pg_stat_io |
Previous Message | Kyotaro Horiguchi | 2023-11-08 01:08:42 | Re: Add new option 'all' to pg_stat_reset_shared() |