| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: crash-safe visibility map, take three |
| Date: | 2010-11-30 16:37:13 |
| Message-ID: | 27659.1291135033@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 30.11.2010 18:10, Tom Lane wrote:
>> I'm not convinced it works at all. Consider write intent record,
>> checkpoint, set bit, crash before completing vacuum. There will be
>> no second intent record at which you could clean up if things are
>> inconsistent.
> That's why you need to check the RedoRecPtr when you set the bit. If it
> has changed, ie. a checkpoint has happened, the set bit step will write
> a new intent record.
Oh, you explained the proposal poorly then. I thought you meant recheck
and write another intent record just once, immediately before sending
the final xlog record.
It still seems rickety and not clearly correct, especially when you
start thinking about all the other constraints we have on xlog behavior
(eg, does this work while taking a base backup).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-11-30 16:38:13 | Re: Instrument checkpoint sync calls |
| Previous Message | Tom Lane | 2010-11-30 16:33:18 | Re: crash-safe visibility map, take three |