hot_standby_feedback

From: Torsten Förtsch <tfoertsch123(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: hot_standby_feedback
Date: 2016-11-28 21:14:55
Message-ID: CAKkG4_mEJdafgFTV2ZN_XAZE7ZP1N-WviG55h1vPOSiiVh3hjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

I am in the process of reviewing our configs for a number of 9.3 databases
and found a replica with hot_standby_feedback=on. I remember when we set it
long ago we were fighting cancelled queries. I also remember that it never
really worked for us. In the end we set up 2 replicas, one suitable for
short queries where we prefer low replication lag, and another one where we
allow for long running queries but sacrifice timeliness
(max_standby_*_delay=-1).

I have a hunch why hot_standby_feedback=on didn't work. But I never
verified it. So, here it is. The key is this sentence:

"Feedback messages will not be sent more frequently than once per
wal_receiver_status_interval."

That interval is 10 sec. So, assuming a transaction on the replica uses a
row right after the message has been sent. Then there is a 10 sec window in
which the master cannot know that the row is needed on the replica and can
vacuum it. If then the transaction on the replica takes longer than
max_standby_*_delay, the only option is to cancel it.

Is that explanation correct?

What is the correct way to use hot_standby_feedback to prevent
cancellations reliably? (and accepting the bloat)

Thanks,
Torsten

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2016-11-28 21:37:14 Re: FOR UPDATE
Previous Message said assemlal 2016-11-28 21:03:53 FOR UPDATE