From: | John Morris <john(dot)morris(at)crunchydata(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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-07 00:57:32 |
Message-ID: | BYAPR13MB26777BA0E688ECE294BDE4A6A0AAA@BYAPR13MB2677.namprd13.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I incorporated your suggestions and added a few more. The changes are mainly related to catching potential errors if some basic assumptions aren’t met.
There are basically 3 assumptions. Stating them as conditions we want to avoid.
* We should not get an unlogged LSN before reading the control file.
* We should not get an unlogged LSN when shutting down.
* The unlogged LSN written out during a checkpoint shouldn’t be used.
Your suggestion addressed the first problem, and it took only minor changes to address the other two.
The essential idea is, we set a value of zero in each of the 3 situations. Then we throw an Assert() If somebody tries to allocate an unlogged LSN with the value zero.
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. Rather than merely explaining why it shouldn’t happen, the new version verifies the assumptions and throws an Assert() if something goes wrong.
Attachment | Content-Type | Size |
---|---|---|
atomic_lsn_v5.patch | application/octet-stream | 3.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-11-07 01:33:07 | Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?) |
Previous Message | Jesper Pedersen | 2023-11-06 23:07:03 | Re: 2023-11-09 release announcement draft |