Fujii Masao wrote: > 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.
I quite liked Robert's proposal to add an explicit GUC to control what extra information is logged (http://archives.postgresql.org/pgsql-hackers/2010-04/msg00509.php). It is quite difficult to explain the current behavior, a simple explicit wal_mode GUC would be a lot simpler. It wouldn't add any extra steps to setting the system up, you currently need to set archive_mode='on' anyway to enable archiving. You would just set wal_mode='archive' or wal_mode='standby' instead, depending on what you want to do with the WAL. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers