From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Stuck spins in current |
Date: | 2001-03-18 03:07:11 |
Message-ID: | 849.984884831@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
> And you know - I've run same tests on ~ Mar 9 snapshot
> without any problems.
Oh, I see it:
Process A is doing GetSnapShotData. It holds SInvalLock and calls
ReadNewTransactionId, which wants XidGenLockId.
Process B is doing GetNewTransactionId. It holds XidGenLockId and
has run out of XIDs, so it needs to write a NEXTXID log record.
Therefore, it calls XLogInsert which wants the insert_lck.
Process C is inside XLogInsert on its first xlog entry of a transaction.
It holds the insert_lck and wants to put its XID into MyProc->logRec,
for which it needs SInvalLock.
Ooops.
At this point I must humbly say "yes, you told me so", because if I
hadn't insisted that we needed NEXTXID records then we wouldn't have
this deadlock.
It looks to me like the simplest answer is to take NEXTXID records
out again. (Fortunately, there doesn't seem to be any comparable
cycle involving OidGenLock, or we'd need to think of a better answer.)
I shall retire to lick my wounds, and make the changes tomorrow ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2001-03-18 03:47:41 | Re: beta6 pg_restore core dumps |
Previous Message | Tom Lane | 2001-03-18 02:24:11 | Re: beta6 pg_restore core dumps |