Skip site navigation (1) Skip section navigation (2)

Re: Cost of XLogInsert CRC calculations

From: "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"'Greg Stark'" <gsstark(at)mit(dot)edu>
Cc: "'Manfred Koizar'" <mkoi-pg(at)aon(dot)at>,"'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cost of XLogInsert CRC calculations
Date: 2005-06-01 09:27:41
Message-ID: 9EB50F1A91413F4FA63019487FCD251D11337C@WEBBASEDDC.webbasedltd.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] 
> Sent: 31 May 2005 17:27
> To: Greg Stark
> Cc: Mark Cave-Ayland (External); 'Manfred Koizar'; 'Bruce 
> Momjian'; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations


> The odds of an actual failure from case #2 are fortunately 
> not high, since a backup block will necessarily span across 
> at least one WAL page boundary and so we should be able to 
> detect stale data by noting that the next page's header 
> address is wrong.  (If it's not wrong, then at least the 
> first sector of the next page is up-to-date, so if there is 
> any tearing the CRC should tell us.)  Therefore I don't feel 
> any need to try to work out a back-patchable solution for #2. 
>  But I do think we ought to change the WAL format going 
> forward to compute just one CRC across a WAL record and all 
> attached backup blocks.  There was talk of allowing 
> compression of backup blocks, and if we do that we could no 
> longer feel any certainty that a page crossing would occur.

I must admit I didn't realise that an XLog record consisted of a number of
backup blocks which were also separately CRCd. I've been through the source,
and while the XLog code is reasonably well commented, I couldn't find a
README in the transam/ directory that explained the thinking behind the
current implementation - is this something that was discussed on the mailing
lists way back in the mists of time?

I'm still a little nervous about dropping down to CRC32 from CRC64 and so
was just wondering what the net saving would be using one CRC64 across the
whole WAL record? For example, if an insert or an update uses 3 backup
blocks then this one change alone would immediately reduce the CPU usage to
one third of its original value? (something tells me that this is probably
not the case as I imagine you would have picked this up a while back). In my
view, having a longer CRC is like buying a holiday with insurance - you pay
the extra cost knowing that should anything happen then you have something
to fall back on. However, the hard part here is determining a reasonable
balance betweem the cost and the risk.

Kind regards,


WebBased Ltd
South West Technology Centre
Tamar Science Park
PL6 8BT 

T: +44 (0)1752 797131
F: +44 (0)1752 791023

In response to


pgsql-hackers by date

Next:From: Hannu KrosingDate: 2005-06-01 09:54:58
Subject: Re: NOLOGGING option, or ?
Previous:From: Magnus HaganderDate: 2005-06-01 08:57:26
Subject: Re: Can we simplify win32 threading code

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group