Re: Dividing progress/debug information in pg_standby, and stat before copy - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Dividing progress/debug information in pg_standby, and stat before copy
Date
Msg-id 4B5ED7F6.9080103@enterprisedb.com
Whole thread Raw
In response to Re: Dividing progress/debug information in pg_standby, and stat before copy  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Dividing progress/debug information in pg_standby, and stat before copy  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: Dividing progress/debug information in pg_standby, and stat before copy  (Robert Haas <robertmhaas@gmail.com>)
Re: Dividing progress/debug information in pg_standby, and stat before copy  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Simon Riggs wrote:
> Currently, we had presumed
> that standby_mode = off would be the same as Warm Standby replication,
> using pg_standby or other.

That's still true. standby_mode=off is the same as what you have in PG
8.4. You can still use pg_standby etc. with that.

> pg_standby checks file size before returning. If you just use "cp" as
> suggested then it would fail because the copy would start before the
> file is ready to be copied.

True. You could work around that by using a script instead of plain
'cp', or by making sure that no partial files appear in the archive in
the other end.

Or we could check for the partial WAL file case in the server. But
Windows copy command is worse than that, and sets the file size before
finishing copying.

From a user point-of-view, it might be simplest to provide a
"restore_directory" option, besides restore_command, and handle the copy
ourselves.

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


pgsql-hackers by date:

Previous
From: Alastair Turner
Date:
Subject: Re: Review: listagg aggregate
Next
From: Peter Eisentraut
Date:
Subject: Re: Review: listagg aggregate