| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Alexander Kuzmenkov <akuzmenkov(at)tigerdata(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fix uninitialized xl_running_xacts padding |
| Date: | 2026-03-18 12:18:45 |
| Message-ID: | bcc81add-15d6-44f8-88a8-ba9b5b68e0c9@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18/03/2026 12:42, Alexander Kuzmenkov wrote:
> On Wed, Mar 18, 2026 at 7:59 AM Michael Paquier <michael(at)paquier(dot)xyz
> <mailto:michael(at)paquier(dot)xyz>> wrote:
>
> Hmm. If I take this SQL sequence independently or with an
> installcheck, the one-page VACUUM path is taken during the final
> INSERT, but that's not the case of a `make check`. Could this be made
> more stable? I have not spent a lot of time on it, so I may be
> missing something obvious, of course.
>
>
> I think this might be caused by "make check" running many tests in
> parallel, so the deleting transaction is visible to some snapshots, and
> the cleanup is not done. Not sure what's the best way to improve this.
I think if you use "BEGIN; INSERT ...; ROLLBACK;" to generate the dead
tuples instead of DELETE, it will not be sensitive to concurrent
snapshots like that.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-03-18 12:19:01 | Re: Serverside SNI support in libpq |
| Previous Message | Alexander Pyhalov | 2026-03-18 12:08:49 | Re: Function scan FDW pushdown |