On Mon, Apr 19, 2010 at 5:31 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> First of all, I wonder why the latter two need to affect the decision of
>>> whether additional information is written to WAL for HS. How about just
>>> removing XLogIsNeeded() condition from XLogStandbyInfoActive()?
>>
>> Bad idea, I think. If XLogIsNeeded() is returning false and
>> XLogStandbyInfoActive() is returning true, the resulting WAL will
>> still be unusable for HS, at least AIUI.
>
> Probably No. Such a WAL will be usable for HS unless an unlogged
> operation (e.g., CLUSTER, CREATE TABLE AS SELECT, etc) happens.
> I think that the occurrence of an unlogged operation rather than
> XLogIsNeeded() itself must be checked in the standby, it's already
> been being checked. So just removing XLogIsNeeded() condition makes
> sense to me.
I think that's a bad idea. Currently we have three possible types of
WAL-logging:
- just enough for crash recovery (archive_mode=off and max_wal_senders=0)
- enough for log-shipping replication (archive_mode=on or
max_wal_senders>0, but recovery_connections=off)
- enough for log-shipping replication + hot standby (archive_mode=on
or max_wal_senders>0, plus recovery_connections=on)
I'm not eager to add a fourth category where hot standby works unless
you do any of the things that break log-streaming in general. That
seems hopelessly fragile and also fairly pointless.
...Robert
