Re: Eliminating SPI from RI triggers - take 2 - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Eliminating SPI from RI triggers - take 2
Date
Msg-id CA+HiwqGW7nXEVRTwRjF==++mERJ4q1rDoHDx6Snw7_npxqQgVQ@mail.gmail.com
Whole thread Raw
In response to Re: Eliminating SPI from RI triggers - take 2  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Eliminating SPI from RI triggers - take 2  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Fri, Oct 7, 2022 at 6:26 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Sun, Oct 2, 2022 at 10:24 AM Andres Freund <andres@anarazel.de> wrote:
> > On 2022-10-01 18:21:15 -0700, Andres Freund wrote:
> > > On 2022-09-29 18:18:10 +0900, Amit Langote wrote:
> > > > So, here's a final revision for today.  Sorry for the noise.
> > >
> > > This appears to fail on 32bit systems. Seems the new test is indeed
> > > worthwhile...
> > >
> > > https://cirrus-ci.com/task/6581521615159296?logs=test_world_32#L406
> > >
> > > [19:12:24.452] Summary of Failures:
> > > [19:12:24.452]
> > > [19:12:24.452]   2/243 postgresql:main / main/regress                                            FAIL
45.08s(exit status 1)
 
> > > [19:12:24.452]   4/243 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade                         ERROR
71.96s
> > > [19:12:24.452]  32/243 postgresql:recovery / recovery/027_stream_regress                         ERROR
45.84s
> > >
> > > Unfortunately ccf36ea2580f66abbc37f27d8c296861ffaad9bf seems to not have
> > > suceeded in capture the test files of the 32bit build (and perhaps broke it
> > > for 64bit builds as well?), so I can't see the regression.diffs contents.
> >
> > Oh, that appears to have been an issue on the CI side (*), while uploading the
> > logs. The previous run did catch the error:
> >
> > diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/alter_table.out
/tmp/cirrus-ci-build/build-32/testrun/main/regress/results/alter_table.out
> > --- /tmp/cirrus-ci-build/src/test/regress/expected/alter_table.out      2022-09-30 15:05:49.930613669 +0000
> > +++ /tmp/cirrus-ci-build/build-32/testrun/main/regress/results/alter_table.out  2022-09-30 15:11:21.050383258
+0000
> > @@ -672,6 +672,8 @@
> >  ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references pktable;
> >  -- Check it actually works
> >  INSERT INTO FKTABLE VALUES(42);                -- should succeed
> > +ERROR:  insert or update on table "fktable" violates foreign key constraint "fktable_ftest1_fkey"
> > +DETAIL:  Key (ftest1)=(42) is not present in table "pktable".
> >  INSERT INTO FKTABLE VALUES(43);                -- should fail
> >  ERROR:  insert or update on table "fktable" violates foreign key constraint "fktable_ftest1_fkey"
> >  DETAIL:  Key (ftest1)=(43) is not present in table "pktable".
>
> Thanks for the heads up.  Hmm, this I am not sure how to reproduce on
> my own, so I am currently left with second-guessing what may be going
> wrong on 32 bit machines with whichever of the 4 patches.
>
> For now, I'll just post 0001, which I am claiming has no semantic
> changes (proof pending), to rule out that that one's responsible.

Nope, not 0001.  Here's 0001+0002.

-- 
Thanks, Amit Langote
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: bt22nakamorit
Date:
Subject: Re: ps command does not show walsender's connected db
Next
From: Alvaro Herrera
Date:
Subject: Re: Eliminating SPI from RI triggers - take 2