From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: AW: Plans for solving the VACUUM problem |
Date: | 2001-05-22 18:20:37 |
Message-ID: | 3705826352029646A3E91C53F7189E32016642@sectorbase2.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 1. Compact log files after checkpoint (save records of uncommitted
> > transactions and remove/archive others).
>
> On the grounds that undo is not guaranteed anyway (concurrent
> heap access), why not simply forget it,
We can set flag in ItemData and register callback function in
buffer header regardless concurrent heap/index access. So buffer
will be cleaned before throwing it out from buffer pool
(little optimization: if at the time when pin drops to 0 buffer
is undirty then we shouldn't really clean it up to avoid unnecessary
write - we can save info in FSM that space is available and clean it
up on first pin/read).
So, only ability of *immediate reusing* is not guaranteed. But this is
general problem of space reusing till we assume that buffer pin is
enough to access data.
> since above sounds rather expensive ?
I'm not sure. For non-overwriting smgr required UNDO info is pretty
small because of we're not required to keep tuple data, unlike
Oracle & Co. We can even store UNDO info in non-WAL format to avoid
log record header overhead. UNDO files would be kind of Oracle rollback
segments but muuuuch smaller. But yeh - additional log reads.
> The downside would only be, that long running txn's cannot
> [easily] rollback to savepoint.
We should implement savepoints for all or none transactions, no?
> > 2. Abort long running transactions.
>
> This is imho "the" big downside of UNDO, and should not
> simply be put on the TODO without thorow research. I think it
> would be better to forget UNDO for long running transactions
> before aborting them.
Abort could be configurable.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2001-05-22 18:33:55 | Re: Not released yet, but could someone take a quick peak ... |
Previous Message | Bruce Momjian | 2001-05-22 18:03:26 | JDBC commit to 7.1.2 |