Prev: Package namespace and Safe init cleanup for plperl[PATCH]
Next: ECPGset_var
From: Robert Haas on 26 Jan 2010 09:18
On Tue, Jan 26, 2010 at 6:54 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> From a user point-of-view, it might be simplest to provide a
> "restore_directory" option, besides restore_command, and handle the copy
> ourselves.

Well, that might not handle all possible use cases -- of course, it
could be there as a sort of "fast path" for people for simple cases.
But I think we should get some more experience with what we have
before we add too many bells and whistles (that might turn out not to
be as useful as we thought).

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Fujii Masao on 26 Jan 2010 09:48
On Tue, Jan 26, 2010 at 8:54 PM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> 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.

How about just retrying SR instead of emitting a FATAL error in
RestoreArchivedFile() when a partial WAL file has been restored?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 26 Jan 2010 09:40
Dimitri Fontaine <dfontaine(a)hi-media.com> writes:
> Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
>> *That* makes pg_standby obsolete, not streaming replication per se.
>> Setting standby_mode=on, with a valid restore_command using e.g 'cp' and
>> no connection info for walreceiver is more or less the same as using
>> pg_standby.

> I've yet to understand how the files in the archive get from the master
> to the slave in this case, or are you supposing in your example that the
> cp in the restore_command is targetting a shared disk setup or
> something?

pg_standby didn't address that detail, either.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 26 Jan 2010 13:58
Josh Berkus <josh(a)agliodbs.com> writes:
> On 1/26/10 10:48 AM, Heikki Linnakangas wrote:
>> I didn't intend to replace pg_standby when I started this, it just kind
>> of happened. Maybe we should provide a sample script similar to
>> pg_standby, to be used instead of plain 'cp', that does the cleanup too.

> What I'm pointing out is that you haven't *quite* replaced pg_standby,
> and at this late date aren't going to. Some people will still want to
> use it. Especially for people who for some reason aren't using SR.

Right, but the question is: is there enough use-case left in it to
justify spending community effort on polishing rough edges? It's not
like we haven't got plenty else to do to get 9.0 out the door.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Selena Deckelmann on 27 Jan 2010 20:13
On Tue, Jan 26, 2010 at 11:03 PM, Greg Smith <greg(a)2ndquadrant.com> wrote:
> Tom Lane wrote:
>>
>> Right, but the question is: is there enough use-case left in it to
>> justify spending community effort on polishing rough edges?  It's not
>> like we haven't got plenty else to do to get 9.0 out the door.
>>
>
> The point I was trying to make is that I'm on the hook to do this particular
> job whether or not the community feels it's worthwhile.  The only real
> decision is whether there's enough interest in upgrading this utility to
> review and possibly commit the result, and I'm trying to minimize the public
> resources needed even for those parts.

I'm interested as well, so happy to continue to work with you on it, Greg.

-selena

--
http://chesnok.com/daily - me
http://endpoint.com - work

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: Package namespace and Safe init cleanup for plperl[PATCH]
Next: ECPGset_var