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

Re: cheaper snapshots

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)krosing(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 19:38:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hannu Krosing <hannu(at)krosing(dot)net> writes:
> So the basic design could be "a sparse snapshot", consisting of 'xmin,
> xmax, running_txids[numbackends] where each backend manages its own slot
> in running_txids - sets a txid when aquiring one and nulls it at commit,
> possibly advancing xmin if xmin==mytxid.

How is that different from what we're doing now?  Basically, what you're
describing is pulling the xids out of the ProcArray and moving them into
a separate data structure.  That could be a win I guess if non-snapshot-
related reasons to take ProcArrayLock represent enough of the contention
to be worth separating out, but I suspect they don't.  In particular,
the data structure you describe above *cannot* be run lock-free, because
it doesn't provide any consistency guarantees without a lock.  You need
everyone to have the same ideas about commit order, and random backends
independently changing array elements without locks won't guarantee

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Hannu KrosingDate: 2011-07-28 19:40:57
Subject: Re: cheaper snapshots
Previous:From: Hannu KrosingDate: 2011-07-28 19:32:47
Subject: Re: cheaper snapshots

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