On Thu, Aug 25, 2011 at 11:15 AM, Markus Wanner <markus@bluegap.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
cluster.
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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company