Re: Deriving Recovery Snapshots

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deriving Recovery Snapshots
Date: 2008-10-22 14:35:09
Message-ID: 48FF3A1D.5070503@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing wrote:
> On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
>> Also, I can't help thinking that this would be a lot simpler if we just
>> treated all subtransactions the same as top-level transactions. The only
>> problem with that is that there can be a lot of subtransactions, which
>> means that we'd need a large UnobservedXids array to handle the worst
>> case, but maybe it would still be acceptable?
>
> I remember cases on this list where long transactions did run out of
> subtransaction ids. To accommodate something approacing that we need an
> array for storing (max_connections * 4G ) UnobservedXids instead of just
> max_connections.

You can't have more than 4G (or 2G?) active subtransactions running in a
system, because you will simply run out of transaction ids and hit xid
wrap-around after that. So in the worst-case, you don't need space for
(max_connections * 4G) xids, just 4G. That's still a large number, of
course.

In situations like that, a bitmap, like clog, instead of an array, would
be more space efficient. But that's less efficient in the more common
case that there's few in-progress transactions, but some of them are
very old.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-10-22 14:37:13 Re: Deriving Recovery Snapshots
Previous Message Heikki Linnakangas 2008-10-22 14:29:48 Re: Deriving Recovery Snapshots