Bruce Momjian wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > > We wouldn't clean up tuples that are visible to a transaction, but if 
> > > you have one long-running transaction like pg_dump in a database with 
> > > otherwise short transaction, you'll have a lot of tuples that are not 
> > > vacuumable because of the long-running process, but are not in fact 
> > > visible to any transaction.
> > 
> > It sounds to me like you are proposing to remove the middles of update
> > chains, which would break READ-COMMITTED updates initiated by the older
> > transactions.  Now admittedly pg_dump isn't going to issue any such
> > updates, but VACUUM doesn't know that.
> 
> Since a multi-statement transaction can't change its transaction
> isolation level after its first statement, would adding a boolean to
> PGPROC help VACUUM be more aggressive about removing rows?  I am
> thinking something like PGPROC.cannot_be_serializable.

In researching, I found we already do this by updating PGPROC.xid for
every command in non-serialzable transactions:

 * GetTransactionSnapshot
 *      Get the appropriate snapshot for a new query in a transaction.
 *
 * The SerializableSnapshot is the first one taken in a transaction.
 * In serializable mode we just use that one throughout the transaction.
 * In read-committed mode, we take a new snapshot each time we are called.


-- 
  Bruce Momjian  <[EMAIL PROTECTED]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to