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: 3683.1311881933@sss.pgh.pa.us (view raw or flat)
Thread:
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
that.

			regards, tom lane

In response to

Responses

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-2014 The PostgreSQL Global Development Group