On Mon, Apr 19, 2010 at 5:31 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Mon, Apr 19, 2010 at 11:04 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
