Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] CIC and deadlocks

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] CIC and deadlocks
Date: 2007-04-11 06:29:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On 4/1/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Good point.  I'm envisioning a procarray.c function along the
> lines of
>         bool TransactionHasSnapshot(xid)
> which returns true if the xid is currently listed in PGPROC
> and has a nonzero xmin.  CIC's cleanup wait loop would check
> this and ignore the xid if it returns false.  Your point means
> that this function would have to take exclusive not shared lock
> while scanning the procarray, which is kind of annoying, but
> it seems not fatal since CIC isn't done all that frequently.
When I looked at the code, it occurred to me that possibly we are
OK with just taking shared lock on the procarray. That means that
some other transaction can concurrently set its serializable snapshot
while we are scanning the procarray. But that should not harm us:
if we see the snapshot set, we wait for the transaction. A transaction
which is setting its serializable snapshot NOW, can not see the
tuples that we did not index, isn't it ?

A patch based on the discussion is attached.




Attachment: CIC_deadlock.patch
Description: application/octet-stream (12.7 KB)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-11 06:38:09
Subject: Re: Question about SHM_QUEUE
Previous:From: tomasDate: 2007-04-11 06:03:46
Subject: Re: prepared statements logging

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-11 06:52:41
Subject: Re: [HACKERS] CIC and deadlocks
Previous:From: Hannu KrosingDate: 2007-04-11 05:33:32
Subject: Re: [HACKERS] Full page writes improvement, code update

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group