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

Re: cheaper snapshots redux

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots redux
Date: 2011-08-25 15:27:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Aug 25, 2011 at 11:15 AM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> On 08/25/2011 04:59 PM, Tom Lane wrote:
>> That's a good point.  If the ring buffer size creates a constraint on
>> the maximum number of sub-XIDs per transaction, you're going to need a
>> fallback path of some sort.
> I think Robert envisions the same fallback path we already have:
> subxids.overflowed.

I have a slightly more nuanced idea, but basically yes.  The trouble
is that if you're keeping the snapshot around and updating it (rather
than scanning the ProcArray each time) you need some sort of mechanism
for the snapshot to eventually un-overflow.  Otherwise, the first
overflow leaves you in the soup for the entire lifetime of the

What I have in mind is to store the highest subxid that has been
removed from the snapshot, or InvalidTransactonId if we know the
snapshot is complete.  Whenever the highest removed subxid falls
behind xmin, we can reset it to InvalidTransactionId.

It would be sensible for clients to store the exact value of
highest_removed_subxid in their snapshots as well, instead of just a
Boolean flag.  A pg_subtrans lookup is needed only for XIDs which are
greater than xmin and less than or equal to highest_removed_subxid.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-08-25 16:40:09
Subject: Re: Change format of FDW options used in \d* commands
Previous:From: Markus WannerDate: 2011-08-25 15:15:34
Subject: Re: cheaper snapshots redux

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