Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
Date: 2023-05-10 18:04:08
Message-ID: 20230510180408.bzxtaneotuy3hyk4@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-05-10 17:44:07 +0200, Peter Eisentraut wrote:
> On 12.03.23 00:41, Andres Freund wrote:
> > Hi,
> >
> > On 2023-03-11 15:34:55 -0800, Mark Dilger wrote:
> > > > On Mar 11, 2023, at 3:22 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > >
> > > > Something like the attached.
> > >
> > > I like that your patch doesn't make the test longer. I assume you've already run the tests and that it works.
> >
> > I did check that, yes :). My process of writing perl is certainly, uh,
> > iterative. No way I would get anything close to working without testing it.
> >
> > CI now finished the tests as well:
> > https://cirrus-ci.com/build/6675457702100992
> >
> > So I'll go ahead and push that.
>
> There is a small issue with this commit (a4f23f9b3c).
>
> In src/bin/pg_amcheck/t/004_verify_heapam.pl, there is code to detect
> whether the page layout matches expectations and if not it calls plan
> skip_all.

Some of these skip_all's don't seem like a good idea. Why is a broken
relfrozenxid a cause for skipping a test? But anyway, that's really unrelated
to the topic at hand.

> This commit adds a test
>
> is(scalar @lp_off, $ROWCOUNT, "acquired row offsets");
>
> *before* that skip_all call. This appears to be invalid. If the skip_all
> happens, you get a complaint like
>
> t/004_verify_heapam.pl (Wstat: 0 Tests: 1 Failed: 0)
> Parse errors: Bad plan. You planned 0 tests but ran 1.
>
> We could move the is() test after all the skip_all's. Any thoughts?

I think the easiest fix is to just die if we can't get the offsets - it's not
like we can really continue afterwards...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-05-10 18:10:49 Re: smgrzeroextend clarification
Previous Message Alvaro Herrera 2023-05-10 17:54:07 de-catalog one error message