From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | FM <dist-list(at)LEXUM(dot)UMontreal(dot)CA>, Mailing List Postgres-Admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: PGSQL 7.4.8 : idle in transaction problem |
Date: | 2005-07-20 13:35:21 |
Message-ID: | 15465.1121866521@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On Tue, Jul 19, 2005 at 10:44:35PM -0400, Tom Lane wrote:
>> If it's a matter of whether VACUUM removes rows or not, that's expected:
>> open-transaction bookkeeping is done across the whole cluster. (This is
>> not something simple to change, since we may have to consider
>> transaction IDs in shared catalogs.)
> I wonder if this restriction could be lifted if we tracked last-vacuum-
> Xid per relation?
No, that's unrelated. What is of concern is the open-transaction
horizon. We could tighten things up by keeping a more complicated set
of information in the PGPROC array --- rather than advertising a single
transaction XMIN, each transaction would have to calculate and advertise
both a "global" XMIN and a "local" XMIN (the latter counting only open
transactions within your own database). This would then allow a more
refined calculation in GetOldestXmin().
I'm inclined to think that the benefit wouldn't be worth the distributed
cost of doing this in every GetSnapshotData() call ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2005-07-20 13:40:50 | Re: Determine PG version used for initdb |
Previous Message | Hannes Dorbath | 2005-07-20 13:21:42 | Determine PG version used for initdb |