Horton

Re: Track in pg_replication_slots the reason why slots conflict?

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, shveta malik <shveta.malik@gmail.com>, Isaac Morland <isaac.morland@gmail.com>, Andres Freund <andres@anarazel.de>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-03T01:39:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Track conflict_reason in pg_replication_slots.

On Tue, Jan 02, 2024 at 02:07:58PM +0000, Bertrand Drouvot wrote:
> +           <literal>wal_level_insufficient</literal> means that the
> +           <xref linkend="guc-wal-level"/> is insufficient on the primary
> +           server.
> 
> I'd prefer "primary_wal_level" instead of "wal_level_insufficient". I think it's
> better to directly mention it is linked to the primary (without the need to refer
> to the documentation) and that the fact that it is "insufficient" is more or less
> implicit.
> 
> Basically I think that with "primary_wal_level" one would need to refer to the doc
> less frequently than with "wal_level_insufficient".

I can see your point, but wal_level_insufficient speaks a bit more to
me because of its relationship with the GUC setting.   Something like
wal_level_insufficient_on_primary may speak better, but that's also
quite long.  I'm OK with what the patch does.

+       as invalidated. Possible values are:
+        <itemizedlist spacing="compact">
Higher-level nit: indentation seems to be one space off here.
--
Michael