Hi, On 2020-03-08 20:12:21 -0400, James Coleman wrote: > I recently noticed while setting up a test environment that attempting to > connect to a standby running without hot_standby=on results in a fairly > generic error (I believe "the database system is starting up"). I don't > have my test setup running right now, so can't confirm with a repro case at > the moment, but with a little bit of spelunking I noticed that error text > only shows up in src/backend/postmaster/postmaster.c when > port->canAcceptConnections has the value CAC_STARTUP. > > Ideally the error message would include something along the lines of "The > server is running as a standby but cannot accept connections with > hot_standby=off".
Yea, something roughly like that would be good. > I wanted to get some initial feedback on the idea before writing a patch: > does that seem like a reasonable change? Is it actually plausible to > distinguish between this state and "still recovering" (i.e., when starting > up a hot standby but initial recovery hasn't completed so it legitimately > can't accept connections yet)? If so, should we include the possibility if > hot_standby isn't on, just in case? Yes, it is feasible to distinguish those cases. And we should, if we're going to change things around. > The enum value CAC_STARTUP is defined in src/include/libpq/libpq-be.h, > which makes me wonder if changing this value would result in a wire > protocol change/something the client wants to know about? If so, I assume > it's not reasonable to change the value, but would it still be reasonable > to change the error text? The value shouldn't be visible to clients in any way. While not obvious from the name, there's this comment at the top of the header: * Note that this is backend-internal and is NOT exported to clients. * Structs that need to be client-visible are in pqcomm.h. Greetings, Andres Freund