Re: beta1 & beta2 & Windows & heavy load

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)

In response to

Responses

Browse pgsql-hackers by date

  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