From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Brian Beuning <bbeuning(at)mindspring(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TOAST performance (was Re: [GENERAL] Delete Performance) |
Date: | 2001-12-21 03:54:18 |
Message-ID: | 200112210354.fBL3sI921714@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> If "pre-page WAL write" means the value of the page before the current
> changes, then there is generally another reason for writing it out.
>
> Imagine this sequence of events:
> 1. transaction A starts
> 2. transaction B starts
> 3. tran A makes a change
> 4. tran B makes a change
> 5. tran A commits
> 6. all changes get written to disk (this can happen even without fsync,
> for example tran C might do a full table scan which fills the buffer cache
> before B commits)
> 7. the system crashes
>
> When the system comes back up, we need to do a rollback on
> transaction B since it did not commit and we need the "pre-page"
> to know how to undo the change for B that got saved in step 6 above.
>
> At least this is what happens in most DBMSs...
Because we have a non-overwriting storage manager, I don't think this
issue applies to us.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Gurudutt | 2001-12-21 04:49:35 | Re: |
Previous Message | Thomas Lockhart | 2001-12-21 01:34:00 | Re: How Many Years have Passed? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-21 03:54:37 | Re: The dbase conrtib doesn't compile |
Previous Message | Bruce Momjian | 2001-12-21 03:53:00 | Re: Status on RC1? |