Re: Add lookup table for replication slot invalidation causes

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add lookup table for replication slot invalidation causes
Date: 2024-02-21 07:20:00
Message-ID: CALj2ACWE3zZmYUre9_8vvsGXUzOhZODgw=M54Cc53S_LH3Q4-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 21, 2024 at 11:56 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Note the recent commit 74a730631065 where Alvaro has changed for the
> lwlock tranche names. That's quite elegant.

Yes, that's absolutely neat. FWIW, designated initializer syntax can
be used in a few more places though. I'm not sure how much worth it
will be but I'll see if I can quickly put up a patch for it.

> > With these two asserts, the behavior (asserts on null and non-existent
> > inputs) is the same as what GetSlotInvalidationCause has right now.
>
> Well, I won't fight you over that.

Haha :)

> A new cause would require an update of SlotInvalidationCause, so if
> you keep RS_INVAL_MAX_CAUSES close to it that's impossible to miss.
> IMO, it makes just more sense to keep that in slot.c because of the
> static assert as well.

Hm, okay. Moved that to slot.c but left a note in the comment atop
enum to update it.

> + * If you add a new invalidation cause here, remember to add its name in
> + * SlotInvalidationCauses in the same order as that of the cause.
>
> The order does not matter with the way v2 does things with
> SlotInvalidationCauses[], no?

Ugh. Corrected that now.

Please see the attached v3 patch.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v3-0001-Add-lookup-table-for-replication-slot-invalidatio.patch application/octet-stream 4.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-02-21 07:26:36 Re: What about Perl autodie?
Previous Message Ashutosh Bapat 2024-02-21 06:48:45 Test to dump and restore objects left behind by regression