On 2026-Apr-03, Alvaro Herrera wrote:
> - I polished the patch to reserve replication slots for REPACK. Given
> the new implementation of 0006 that was submitted implies that we can
> now run multiple repacks concurrently, I changed the default of 1 to 5.
Srinath let me know that this new part was causing CI failures on
Windows. This version v51 should be okay (or, at least, it passes for
me on CI). Additional changes worth mentioning:
- I think it's nicer for the index_create() API to get a bit to indicate
suppression of progress reporting; so existing callers don't need to
do anything. I guess this is mostly a matter of taste.
- I incorporated Srinath's fix for the PreventInTransactionBlock block.
- When CheckSlotRequirements() is to complain about
"max_replication_slots or max_repack_replication_slots", it seems
actually nicer to say exactly which one of these is the cause of the
problem. This is easy to change; patch 0010 does it; it requires
passing down a "repack" flag all the way from
CheckLogicalDecodingRequirements() and it needs to add an argument to
CreateInitDecodingContext(), which is perhaps not so great. On the
whole I'm inclined to do it anyway, but I'm about equally happy to
leave it alone. This is what would change:
original:
ereport(ERROR,
- (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("replication slots can only be used if \"%s\" > 0 or \"%s\" > 0",
- "max_replication_slots", "max_repack_replication_slots")));
patched:
ereport(ERROR,
+ errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("replication slots can only be used if \"%s\" > 0",
+ repack ? "max_repack_replication_slots" : "max_replication_slots"));
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"This is a foot just waiting to be shot" (Andrew Dunstan)
