From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: beta1 & beta2 & Windows & heavy load |
Date: | 2004-09-13 21:48:34 |
Message-ID: | 20040913214834.GA5802@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Sep 12, 2004 at 08:28:42PM -0400, Tom Lane wrote:
> 1. During CommitSubTransaction, release the lock on the subtransaction's
> XID (but not any of its other locks). This means that the number of
> locks held due to just transaction XIDs is no more than the subxact
> nesting depth, rather than growing with the number of subcommitted XIDs.
>
> 2. XactLockTableWait would have to do something like this:
>
> for (;;)
> {
> wait for lock associated with xid;
> if (!TransactionIdIsInProgress(xid))
> break;
> xid = SubTransGetParent(xid);
> }
FWIW, this works for me.
> The other question is whether it's worth some extra overhead in
> XactLockTableWait to save on shared memory. I'm inclined to think it
> is, mainly because you don't get into XactLockTableWait in the first
> place unless you're going to have to block.
Furthermore, the savings are possibly unbounded, so this is a good idea
anyway. From the example case it's not hard to imagine situations where
we will want lots of subtransactions; just using exceptions in functions
will implicitly open new ones! (This kind of bothers me because of the
possibly very fast use of Xids, accelerating Xid counter wraparound ...)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La principal característica humana es la tontería"
(Augusto Monterroso)
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-09-13 22:07:37 | Re: SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0 |
Previous Message | Tom Lane | 2004-09-13 21:31:15 | Re: [HACKERS] pg_locks view and user locks |