Re: Minimal logical decoding on standbys
Jonathan S. Katz <jkatz@postgresql.org>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reduce the log level in 035_standby_logical_decoding.pl.
- 3034dc56ef4b 16.0 landed
-
035_standby_logical_decoding: Add missing waits for replication
- 57411c82ce86 16.0 landed
-
For cascading replication, wake physical and logical walsenders separately
- e101dfac3a53 16.0 landed
-
Handle logical slot conflicts on standby
- 26669757b6a7 16.0 landed
-
Support invalidating replication slots due to horizon and wal_level
- be87200efd93 16.0 landed
-
Prevent use of invalidated logical slot in CreateDecodingContext()
- 4397abd0a2af 16.0 landed
-
Replace replication slot's invalidated_at LSN with an enum
- 15f8203a5975 16.0 landed
-
Pass down table relation into more index relation functions
- 61b313e47eb9 16.0 landed
-
Assert only valid flag bits are passed to visibilitymap_set()
- a88a18b1250b 16.0 landed
-
Remove unused _bt_delitems_delete() argument.
- dc43492e46c7 14.0 cited
-
Add xl_btree_delete optimization.
- d2e5e20e5711 13.0 cited
On 4/8/23 12:01 AM, Andres Freund wrote:
> Hi,
>
> On 2023-04-08 09:15:05 +0530, Amit Kapila wrote:
>> The new approach for invalidation looks clean. BTW, I see minor
>> inconsistency in the following two error messages (errmsg):
>
> Thanks for checking.
>
>
>> if (MyReplicationSlot->data.invalidated == RS_INVAL_WAL)
>> ereport(ERROR,
>> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>> errmsg("can no longer get changes from replication slot \"%s\"",
>> NameStr(MyReplicationSlot->data.name)),
>> errdetail("This slot has been invalidated because it exceeded the
>> maximum reserved size.")));
>>
>> if (MyReplicationSlot->data.invalidated != RS_INVAL_NONE)
>> ereport(ERROR,
>> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>> errmsg("cannot read from logical replication slot \"%s\"",
>> NameStr(MyReplicationSlot->data.name)),
>> errdetail("This slot has been invalidated because it was conflicting
>> with recovery.")));
>>
>> Won't it be better to keep the same errmsg in the above two cases?
>
> Probably - do you have a preference? I think the former is a bit better?
+1 for the former, though perhaps "receive" instead of "get?"
Jonathan