Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Date
Msg-id 4BD87F1A.9050403@enterprisedb.com
Whole thread Raw
In response to Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Tom Lane wrote:
>>> If you aren't archiving then there's no guarantee that you'll still have
>>> a continuous WAL series starting from the start of the backup.
> 
>> I wasn't really thinking of this use case, but you could set
>> wal_keep_segments "high enough".
> 
> Ah.  Okay, that seems like a workable approach, at least for people with
> reasonably predictable WAL loads.  We could certainly improve on it
> later to make it more bulletproof, but it's usable now --- if we relax
> the error checks.

Yeah, wal_keep_segments is wishy-woshy in general, not only with backups.

> (wal_keep_segments can be changed without restarting, right?)

It's PG_SIGHUP.

>> Not a configuration I would recommend
>> for high availability, but should be fine for setting up a streaming
>> replication standby for testing etc. If we don't allow
>> pg_start/stop_backup() with archive_mode=off and max_wal_senders>0,
>> there's no way to bootstrap a streaming replication standby without
>> archiving.
> 
> Right.  +1 for weakening the tests, then.  Is there any use in looking
> at wal_keep_segments as part of this test?

I don't think so. There's no safe setting that would guarantee anything.
We could check for wal_keep_segments>0, but any small number is the same
practice. We don't insist on wal_keep_segments>0 to allow WAL streaming
without archival in general, let's not treat taking the base backup
differently.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Add column if not exists (CINE)
Next
From: Tom Lane
Date:
Subject: Re: explicit (void *) casts