Re: PGSQL 7.4.8 : idle in transaction problem

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

In response to

Responses

Browse pgsql-admin by date

  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