Re: Need Force flag for pg_drop_replication_slot()

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

* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> On 05/29/2015 11:30 AM, Stephen Frost wrote:
> > I know how big my WAL partition is. Let me tell PG how big it is and to
> > not do anything that'll end up going over that amount, and we'll never
> > see a crash due to out of disk space for WAL again.
>
> Hmmmm. Do we have a clear idea anywhere in server memory how many WAL
> segments there are?

Why does it need to be in shared memory..?

Clearly, when we're looking at cleaning up the WAL files, we know if the
archive command is failing and what file we're trying to archive, or if
we're not able to recycle a given file because we have logical
replication slots that want it, etc.

We certainly know where we're currently at in the WAL stream and we know
how big each WAL file is..

We just need a knob to be able to say "alright, this WAL file might
still be desired by something, but we're running out of room for *new*
WAL and, therefore, that's just too bad for those process that want it"
and recycle it anyway. There are probably error conditions we have to
consider for replication slots when that happens, etc, but I don't think
we lack the info to make the decision, except for what value to set the
knob to, which is clearly system-dependent.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-05-29 20:36:38 Re: RFC: Remove contrib entirely
Previous Message Robert Haas 2015-05-29 20:29:36 Re: [CORE] postpone next week's release