From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Jacob Champion <jchampion(at)timescale(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com> |
Subject: | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Date: | 2023-07-05 09:44:34 |
Message-ID: | 66ac664d-65a0-1eab-f2a0-4bab0761b88b@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/02/2023 04:51, David Rowley wrote:
> I've attached another set of patches. I do need to spend longer
> looking at this. I'm mainly attaching these as CI seems to be
> highlighting a problem that I'm unable to recreate locally and I
> wanted to see if the attached fixes it.
I like this patch's approach.
> index 296dc82d2ee..edb8b6026e5 100644
> --- a/src/backend/commands/discard.c
> +++ b/src/backend/commands/discard.c
> @@ -71,7 +71,7 @@ DiscardAll(bool isTopLevel)
> Async_UnlistenAll();
> - LockReleaseAll(USER_LOCKMETHOD, true);
> + LockReleaseSession(USER_LOCKMETHOD);
> ResetPlanCache();
This assumes that there are no transaction-level advisory locks. I think
that's OK. It took me a while to convince myself of that, though. I
think we need a high level comment somewhere that explains what
assumptions we make on which locks can be held in session mode and which
in transaction mode.
> @@ -3224,14 +3206,6 @@ PostPrepare_Locks(TransactionId xid)
> Assert(lock->nGranted <= lock->nRequested);
> Assert((proclock->holdMask & ~lock->grantMask) == 0);
>
> - /* Ignore it if nothing to release (must be a session lock) */
> - if (proclock->releaseMask == 0)
> - continue;
> -
> - /* Else we should be releasing all locks */
> - if (proclock->releaseMask != proclock->holdMask)
> - elog(PANIC, "we seem to have dropped a bit somewhere");
> -
> /*
> * We cannot simply modify proclock->tag.myProc to reassign
> * ownership of the lock, because that's part of the hash key and
This looks wrong. If you prepare a transaction that is holding any
session locks, we will now transfer them to the prepared transaction.
And its locallock entry will be out of sync. To fix, I think we could
keep around the hash table that CheckForSessionAndXactLocks() builds,
and use that here.
--
Heikki Linnakangas
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-07-05 09:51:15 | Re: Prevent psql \watch from running queries that return no rows |
Previous Message | Himanshu Upadhyaya | 2023-07-05 09:37:44 | CHECK Constraint Deferrable |