Re: Don'st start streaming after creating a slot in pg_receivexlog - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Don'st start streaming after creating a slot in pg_receivexlog
Date
Msg-id CANP8+jLWzd5_O9+CXMrr2kOg4sVaik+1sXRBrq6GTQ+4XAP33g@mail.gmail.com
Whole thread Raw
In response to Re: Don'st start streaming after creating a slot in pg_receivexlog  (Andres Freund <andres@anarazel.de>)
Responses Re: Don'st start streaming after creating a slot in pg_receivexlog
List pgsql-hackers
On 29 July 2015 at 09:01, Andres Freund <andres@anarazel.de> wrote:
On 2015-07-29 08:54:40 +0100, Simon Riggs wrote:
> --drop-slot seems pointless, since you can just do that with psql
>
> If we make --create-slot do nothing but add the slot, then that seems
> pointless also

> Would we need to add those options to all commands, when it can be done
> with psql?

They work over the replication protocol, which is handy, because it can
be done with the same user/permissions as the normal pg_receivexlog.

It's useful to separate permissions for creating/dropping a slot from using it. A one-time act configures (or re-configures) how you wish the cluster to look, another more regular task is to connect to the slot and use it. But if you want to have a single user with privileges for both, you can create that. I don't see it as something that we need to support in the replication protocol, since that would require us to extend it every time we think of something else.

Creating a temporary slot goes against the whole concept of slots, so using the same id in the same script isn't actually needed, except maybe to simplify testing.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_basebackup and replication slots
Next
From: "Shulgin, Oleksandr"
Date:
Subject: Re: Don'st start streaming after creating a slot in pg_receivexlog