Re: Need Force flag for pg_drop_replication_slot()

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Need Force flag for pg_drop_replication_slot()
Date: 2015-05-29 17:45:56
Message-ID: 20150529174556.GA26667@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2015-05-29 10:15:56 -0700, Josh Berkus wrote:
> > pg_drop_replication_slot() can be a time-critical function when the
> > master is running out of disk space because the replica is falling
> > behind.
>
> I don't buy this argument. The same is true for DROP TABLE, TRUNCATE,
> DROP DATABASE etc.

I disagree about that being the same.

> I mean, I agree it'd be convenient, but I can't see it as "critical".

Just a random thought- do we check the LOGIN attribute for replication
connections? If so, you could tweak that, but that may be an issue if
you have multiple replicas using the same role.

I'm not sure that it's *critical*, but I could see an argument for
adding this post-feature-freeze, which I'm guessing is what Josh was
getting at.

> > While I'm just doing this during testing, it could be a critical fail in
> > production. I think the simplest way to resolve this would be to add a
> > boolean flag to pg_drop_replication_slot(), which would terminate the
> > replication connection and delete the slot as a single operation.
>
> There's no "single operation" for terminating a backend *and* doing
> something...

That's a good point, we'd need to figure out how to make this actually
work reliably in the face of a very fast reconnecting process, if we're
going to do it.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2015-05-29 17:48:02 [PATCH, TRIVIAL] don't specify S_IRUSR|S_IWUSR without O_CREAT
Previous Message Andres Freund 2015-05-29 17:42:32 Re: fsync-pgdata-on-recovery tries to write to more files than previously