Re: CLUSTER and MVCC
От | Bruce Momjian |
---|---|
Тема | Re: CLUSTER and MVCC |
Дата | |
Msg-id | 200703222157.l2MLvcB21801@momjian.us обсуждение исходный текст |
Ответ на | Re: CLUSTER and MVCC (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: CLUSTER and MVCC
|
Список | pgsql-hackers |
Bruce Momjian wrote: > Tom Lane wrote: > > Heikki Linnakangas <heikki@enterprisedb.com> 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 SerializableSnapshotis 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: