On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas <robertmh...@gmail.com> wrote: > One way we could fix this is use 2 bits rather than 1 for > XLogStandbyInfoMode. One bit could indicate that either > archive_mode=on or max_wal_senders>0, and the second bit could > indicate that recovery_connections=on. If the second bit is unset, we > could emit the existing complaint: > > recovery connections cannot start because the recovery_connections > parameter is disabled on the WAL source server > > If the other bit is unset, then we could instead complain: > > recovery connections cannot start because archive_mode=off and > max_wal_senders=0 on the WAL source server > > If we don't want to use two bits there, it's hard to really describe > all the possibilities in a reasonable number of characters. The only > thing I can think of is to print a message and a hint: > > recovery_connections cannot start due to incorrect settings on the WAL > source server > HINT: make sure recovery_connections=on and either archive_mode=on or > max_wal_senders>0 > > I haven't checked whether the hint would be displayed in the log on > the standby, but presumably we could make that be the case if it's not > already. > > I think the first way is better because it gives the user more > specific information about what they need to fix. Thinking about how > each case might happen, since the default for recovery_connections is > 'on', it seems that recovery_connections=off will likely only be an > issue if the user has explicitly turned it off. The other case, where > archive_mode=off and max_wal_senders=0, will likely only occur if > someone takes a snapshot of the master without first setting up > archiving or SR. Both of these will probably happen relatively > rarely, but since we're burning a whole byte for XLogStandbyInfoMode > (plus 3 more bytes of padding?), it seems like we might as well snag > one more bit for clarity. > > Thoughts?
I like the second choice since it's simpler and enough for me. But I have no objection to the first. When we encounter the error, we would need to not only change those parameter values but also take a fresh base backup and restart the standby using it. The description of this required procedure needs to be in the document or error message, I think. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
