On Wednesday, September 21, 2022, Ashwin Agrawal <ashwins...@gmail.com> wrote:
> Currently, pg_basebackup has > --create-slot option to create slot if not already exists or > --slot to use existing slot > > Which means it needs knowledge on if the slot with the given name already > exists or not before invoking the command. If pg_basebackup --create-slot > <> command fails for some reason after creating the slot. Re-triggering the > same command fails with ERROR slot already exists. Either then need to > delete the slot and retrigger Or need to add a check before retriggering > the command to check if the slot exists and based on the same alter the > command to avoid passing --create-slot option. This poses > inconvenience while automating on top of pg_basebackup. As checking for > slot presence before invoking pg_basebackup unnecessarily involves issuing > separate SQL commands. Would be really helpful for such scenarios if > similar to CREATE TABLE, pg_basebackup can have IF NOT EXISTS kind of > semantic. (Seems the limitation most likely is coming from CREATE > REPLICATION SLOT protocol itself), Thoughts? > What’s the use case for automating pg_basebackup with a named replication slot created by the pg_basebackup command? Why can you not leverage a temporary replication slot (i.e., omit —slot). ISTM the create option is basically obsolete now. David J.
