Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct |
Дата | |
Msg-id | 4BD87D1F.8030403@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas wrote: > Tom Lane wrote: >> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >>> Well, it would be nice to allow using pg_start_backup() on the primary >>> when streaming replication is enabled, even if archiving isn't. >>> Otherwise the only way to get the base backup for the standby is to shut >>> down primary first, or use filesystem snapshot etc. >> I think I must be missing something: exactly how would you fire up a new >> standby from such a base backup, if you weren't running archiving? > > I was replying to Robert's thought on using pg_start/stop_backup() for > taking a hot backup. Not for bootstrapping a standby. Scratch that, I just reread what I wrote, and starting a streaming replication standby from such a backup was exactly what I was describing.. >> 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". 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. This still makes sense. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: