On 25.10.2011 15:56, Steve Singer wrote:
On 11-10-25 02:44 AM, Heikki Linnakangas wrote:
With pg_basebackup, we have a fighting chance of getting this right,
because we have more control over how the backup is made. For example,
we can co-operate with the buffer manager to avoid torn-pages,
eliminating the need for full_page_writes=on, and we can include a
control file with the correct end-of-backup location automatically,
without requiring user intervention. pg_basebackup is less flexible
than the pg_start/stop_backup method, and unfortunately you're more
likely to need the flexibility in a more complicated setup with a hot
standby server and all, but making the generic pg_start/stop_backup
method work seems infeasible at the moment.
Would pg_basebackup be able to work with the buffer manager on the slave
to avoid full_page_writes=on needing to be set on the master? (the point
of this is to be able to take the base backup without having the backup
program contact the master).
In theory, yes. I'm not sure how difficult it would be in practice.
Currently, the walsender process just scans and copies everything in the
data directory, at the filesystem level. It would have to go through the
buffer manager instead, to avoid reading a page at the same time that
the buffer manager is writing it out.
If so could pg_start_backup() not just put the buffer manager into the same
state?
No. . The trick that pg_basebackup (= walsender) can do is to co-operate
with the buffer manager when reading each page. An external program
cannot do that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
