Re: Need Force flag for pg_drop_replication_slot() - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Need Force flag for pg_drop_replication_slot()
Date
Msg-id 20150529203139.GQ26667@tamriel.snowman.net
Whole thread Raw
In response to Re: Need Force flag for pg_drop_replication_slot()  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
* Josh Berkus (josh@agliodbs.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

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [CORE] postpone next week's release
Next
From: Tom Lane
Date:
Subject: Re: [CORE] postpone next week's release