Re: recovery_connections cannot start (was Re: master in standby mode croaks) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Date
Msg-id 18644.1272062554@sss.pgh.pa.us
Whole thread Raw
In response to Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> In my understanding this means that archive_mode does completely and the
> max_wal_senders does not affect WAL contents?

I think we'd concluded that we have to keep archive_mode as a separate
boolean.  (Or we could use Heikki's idea of a max number of unarchived
segments to hold onto, but I maintain that there are only two useful
values and so we might as well leave it as the existing boolean.)

> Does that mean that wal_mode can be SIGHUP now? It would be good. I
> think this is how to do that: 
> At the start of every WAL-avoiding operation we could take a copy of
> wal_mode for the server and store in MyProc->wal_mode. At transaction
> start we would set that to "not set". We could then make
> pg_start_backup() wait for all transactions with wal_mode set to
> complete before we continue.

I think that there are probably more synchronization issues than that,
and in any case now is not the time to be trying to implement that
feature.  Maybe we can make it work in 9.1.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Next
From: Simon Riggs
Date:
Subject: Re: testing HS/SR - 1 vs 2 performance