From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Is Recovery actually paused? |
Date: | 2020-10-20 09:30:03 |
Message-ID: | CANP8+jLsALWd0w=4t3yU7pfaf04SW_xGyOvXtfkA5i3kPMjKuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 Oct 2020 at 09:50, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > Why would we want this? What problem are you trying to solve?
> >
> > The requirement is to know the last replayed WAL on the standby so
> > unless we can guarantee that the recovery is actually paused we can
> > never get the safe last_replay_lsn value.
> >
> > > If we do care, why not fix pg_is_wal_replay_paused() so it responds as you wish?
> >
> > Maybe we can also do that but pg_is_wal_replay_paused is an existing
> > API and the behavior is to know whether the recovery paused is
> > requested or not, So I am not sure is it a good idea to change the
> > behavior of the existing API?
> >
>
> Attached is the POC patch to show what I have in mind.
If you don't like it, I doubt anyone else cares for the exact current
behavior either. Thanks for pointing those issues out.
It would make sense to alter pg_wal_replay_pause() so that it blocks
until paused.
I suggest you add the 3-value state as you suggest, but make
pg_is_wal_replay_paused() respond:
if paused, true
if requested, wait until paused, then return true
else false
That then solves your issues with a smoother interface.
--
Simon Riggs http://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-10-20 09:30:55 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Michael Paquier | 2020-10-20 09:11:03 | Re: Online verification of checksums |