Failures in sto_using_cursor test

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Failures in sto_using_cursor test
Date: 2022-05-31 03:33:41
Message-ID: CA+hUKG+HWod7uE1jk-k-a+YYF=t7Eo1SzJnzrr_OvPTviVkWLg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Here are some failures in the test sto_using_cursor, on 12, 13 and
HEAD branches:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2020-03-15%2023:18:30
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2021-03-03%2005:59:30
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2021-04-20%2020:49:17
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2021-08-10%2004:47:08
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&dt=2021-09-16%2002:15:25
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus&dt=2022-05-16%2010:21:03

Unfortunately the build farm doesn't capture regression.diffs. I
recall that a problem like that was fixed at some point in the BF
code, but peripatus is running the latest tag (REL_14) so I'm not sure
why.

That reminds me: there was a discussion about whether the whole STO
feature should be deprecated/removed[1], starting from Andres's
complaints about correctness and testability problems in STO while
hacking on snapshot scalability. I'd be happy to come up with the
patch for that, if we decide to do that, perhaps when the tree opens
for 16?

Or perhaps someone wants to try to address the remaining known issues
with it? Robert fixed some stuff, and I had some more patches[2] that
tried to fix a few more things relating to testability and a
wraparound problem, not committed. I'd happily rebase them with a
view to getting them in, but only if there is interest in reviewing
them and really trying to save this design. There were more problems
though: there isn't a systematic way to make sure that
TestForOldSnapshot() is in all the right places, and IIRC there are
some known mistakes? And maybe more.

[1] https://www.postgresql.org/message-id/flat/20200401064008.qob7bfnnbu4w5cw4%40alap3.anarazel.de
[2] https://www.postgresql.org/message-id/CA%2BhUKGJyw%3DuJ4eL1x%3D%2BvKm16fLaxNPvKUYtnChnRkSKi024u_A%40mail.gmail.com

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-05-31 04:58:25 Re: convert libpq uri-regress tests to tap test
Previous Message Michael Paquier 2022-05-31 01:46:27 Re: Prevent writes on large objects in read-only transactions