Greetings,

* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
> OK.  I think this is perhaps a documentation bug, maybe a missing 
> warning when the master reads its configuration, and maybe (as you say) 
> a bad default value.

If we consider it to be an issue worthy of a change then we should
probably just change the default value, and maybe not even allow it to
be set lower than '1'.

> Specifically, section 26.2.5 of the docs says:
> 
> "If you use streaming replication without file-based continuous archiving, 
> the server might recycle old WAL segments before the standby has received 
> them. If this occurs, the standby will need to be reinitialized from a new 
> base backup. You can avoid this by setting wal_keep_segments to a value 
> large enough to ensure that WAL segments are not recycled too early, or by 
> configuring a replication slot for the standby. If you set up a WAL archive 
> that's accessible from the standby, these solutions are not required, since 
> the standby can always use the archive to catch up provided it retains enough 
> segments."
> 
> OR, maybe the WAL reader that process the files that restore_command fetches 
> could be smart enough to realise that it can skip over the gap at the end?

That strikes me as a whole lot more complication in something we'd
rather not introduce additional complications into without very good
reason.  Then again, there was just a nearby discussion about how it'd
be nice if the backend could realize when a WAL file is complete, and I
do think that'll be more of an issue when users start configuring larger
WAL files, so perhaps we should figure out a way to handle this..

> Anyway.  Do others agree that my issue was the result of wal_keep_segments=0 ?

Yeah, I've not spent much time actually looking at code around this, so
it'd be nice to get:

a) a reproducible case demonstrating it's happening
b) testing to see how long it's been this way
c) if setting wal_keep_segments=1 fixes it
d) perhaps some thought around if we could address this some other way

Thanks!

Stephen

Attachment: signature.asc
Description: PGP signature

Reply via email to