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
|
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: