Обсуждение: Buffer Management: Can dirty pages be written before transaction commits?
Buffer Management: Can dirty pages be written before transaction commits?
От
Prima Chairunnanda
Дата:
I am in the middle of studying PostgreSQL MVCC approach when I stumbled upon the two hint bits which marked xmin/xmax to be "in progress", "committed", or "aborted". I just want to make sure that I got my understanding right with regards to Postgres' XLOG and Buffer management.
1. When a transaction T updates a tuple X, it creates a new version of the tuple, and then leave the hint bits unset (xmin/xmax in progress). Let's say the tuple is located in page P.
2. Buffer manager may evict page P from cache even before transaction T commits/aborts. However, it must do so only after HEAP_UPDATE is written to XLOG.
3. When transaction T eventually commits/aborts, we only have to set appropriate CLOG bits for T, but we never have to touch the hint bits of the tuples modified by transaction T.
4. Only when another transaction inspects tuple X, it realizes that the hint bits are unset and needs to inspect CLOG to see the outcome of xmin/xmax. If there is any change in outcome, the hint bits of tuple X will be set.
5. So it is actually possible for tuples created by aborted transaction to appear on disk. However this should pose no problem as they will never be visible to any transaction, and Vacuum process will eventually get rid of them.
I am really unsure about point 2, because I couldn't find any definite statement whether a dirty page could be written before transaction commits. All it makes clear is that the XLOG record describing the change must be present on disk before the dirty page, but that does not seem to prohibit dirty pages to be written before commit time. The consequence is as described in point 5, the transaction which created the tuple might turn out to be aborted, and those tuples will be invalid and efforts will be wasted.
Thanks in advance for your help and clarification.
Prima
Prima Chairunnanda <prima.ch@gmail.com> writes:
> I am really unsure about point 2, because I couldn't find any definite
> statement whether a dirty page could be written before transaction commits.
Certainly. Were that not so, how would we handle mass update
transactions (where "mass" means "dirties more pages than can fit in
shared_buffers")?
Dirty pages can be written out at any time, subject only to the WAL rule
that the relevant WAL records have to be flushed to disk first. The
buffer manager checks that by comparing the page's LSN field to the
globally-visible latest WAL flush location.
regards, tom lane
Hi, There is a similar thread about 'dirty' buffers being flushed to Oracle at this http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273 link The answer is provided by the 'other' Tom of Oracle. PostgreSQL's WAL logs are similar to redologs of Oracle. Regards, Jayadevan -- View this message in context: http://postgresql.1045698.n5.nabble.com/Buffer-Management-Can-dirty-pages-be-written-before-transaction-commits-tp5711537p5711718.html Sent from the PostgreSQL - novice mailing list archive at Nabble.com.
Re: Re: Buffer Management: Can dirty pages be written before transaction commits?
От
Prima Chairunnanda
Дата:
Got it. Thanks for all the replies.
Prima
On Fri, Jun 8, 2012 at 12:16 AM, Jayadevan <Jayadevan.Maymala@ibsplc.com> wrote:
Hi,
There is a similar thread about 'dirty' buffers being flushed to Oracle at
this
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273
link
The answer is provided by the 'other' Tom of Oracle. PostgreSQL's WAL logs
are similar to redologs of Oracle.
Regards,
Jayadevan
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Buffer-Management-Can-dirty-pages-be-written-before-transaction-commits-tp5711537p5711718.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice