Infinite loop on master shutdown
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38710psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 01:01 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38710_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38710_1 && git checkout t38710_1Patchset v1 (message #1) is on t38710_1
Hello, as in pgsql-bug ML.
/messages/by-id/20180517.170021.24356216.horiguchi.kyotaro@lab.ntt.co.jp
Master can go into infinite loop on shutdown. But it is caused by
a broken database like storage rolled-back one. (The steps to
replay this is shown in the above mail.)
I think this can be avoided by rejecting a standby if it reports
that write LSN is smaller than flush LSN after catching up.
Is it worth fixing?
# The patch is slightly different from that I posted to -bugs.
It is enough to chek for the invalid state just once but the
patch continues the check.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Hi,
On 2018-05-17 17:19:00 +0900, Kyotaro HORIGUCHI wrote:
Hello, as in pgsql-bug ML.
/messages/by-id/20180517.170021.24356216.horiguchi.kyotaro@lab.ntt.co.jp
Master can go into infinite loop on shutdown. But it is caused by
a broken database like storage rolled-back one. (The steps to
replay this is shown in the above mail.)I think this can be avoided by rejecting a standby if it reports
that write LSN is smaller than flush LSN after catching up.Is it worth fixing?
I'm very doubtful. If you do bad stuff to a standby, bad things can
happen...
Greetings,
Andres Freund
At Thu, 17 May 2018 09:20:01 -0700, Andres Freund <andres@anarazel.de> wrote in <20180517162001.rzd7l6g2h66hvzvd@alap3.anarazel.de>
Hi,
On 2018-05-17 17:19:00 +0900, Kyotaro HORIGUCHI wrote:
Hello, as in pgsql-bug ML.
/messages/by-id/20180517.170021.24356216.horiguchi.kyotaro@lab.ntt.co.jp
Master can go into infinite loop on shutdown. But it is caused by
a broken database like storage rolled-back one. (The steps to
replay this is shown in the above mail.)I think this can be avoided by rejecting a standby if it reports
that write LSN is smaller than flush LSN after catching up.Is it worth fixing?
I'm very doubtful. If you do bad stuff to a standby, bad things can
happen...
Yes, I doubted its worthiness since I didn't find more natural
way to cause that.
Thanks for the opinion.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center