Message on end of cascading physical replica timeline is unhelpful

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Message on end of cascading physical replica timeline is unhelpful
Date: 2018-05-21 07:32:01
Message-ID: CAMsr+YGF3KCDRmQhMzpwPUm5gXHhkakEph9Oz4qJ0P0xC24rFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all

By default, cascading replicas don't follow an upstream's timeline change.
I'm not arguing that decision, but as I think it violates POLA somewhat
it'd be nice to have an informative message.

Currently the user gets repeating messages like

LOG: restarted WAL streaming at 25/CA000000 on timeline 2
LOG: replication terminated by primary server
DETAIL: End of WAL reached on timeline 2 at 25/CAA66EE8.

which is IMO not super helpful. We'll either continue on the next timeline,
or reconnect and see if the server has more to send us on this timeline,
depending on the value of recovery_target_timeline. The standby knows what
it's doing, and it's not something coming from the upstream like this
message seems to say.

But it's not telling the user why it keeps on asking for the same timeline
over and over, though it knows perfectly well why.

xlog.c doesn't expose recoveryTargetTLI and recoveryTargetIsLatest so
walreceiver.c can't say much about them.

I'm inclined to just add a read-only accessor function for recoveryTargetTLI
and recoveryTargetIsLatest that lets the walreceiver look them up.

I'm thinking of something like

recoveryTargetIsLatest || startpointTLI < recoveryTargetTLI ?
errhint("Will look for new timelines on server and restart
streaming")
: errhint("recovery_target_timeline limits streaming to timeline
%u", startpointTLI)

It's ugly, but it's hard to come up with something succinct and
translator-friendly here, especially without duplicating the whole rest of
the error message. I can break it out to a simple function if desired.

In the mean time this message and the archives should help people whose
cascading replicas decide not to keep up with the times.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-05-21 07:34:18 Re: Postgres 11 release notes
Previous Message Mateusz Guzik 2018-05-21 07:27:15 Re: [HACKERS] kqueue