On 2013-04-30 11:55:29 +0100, Simon Riggs wrote: > ISTM that we also need this patch to put memory barriers in place > otherwise the code might be rearranged. > > -- > Simon Riggs http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services
> --- a/src/backend/storage/page/bufpage.c > +++ b/src/backend/storage/page/bufpage.c > @@ -960,11 +960,14 @@ PageCalcChecksum16(Page page, BlockNumber blkno) > * Save pd_checksum and set it to zero, so that the checksum calculation > * isn't affected by the checksum stored on the page. We do this to > * allow optimization of the checksum calculation on the whole block > - * in one go. > + * in one go. Memory barriers are required to avoid rearrangement here. > */ > save_checksum = phdr->pd_checksum; > + pg_memory_barrier(); > phdr->pd_checksum = 0; > + pg_memory_barrier(); > checksum = checksum_block(page, BLCKSZ); > + pg_memory_barrier(); > phdr->pd_checksum = save_checksum; > > /* mix in the block number to detect transposed pages */ Why? I am not sure which rearrangement you're fearing? In all cases where there is danger of concurrent write access to the page we should already be working on a copy? Also, if we need a memory barrier I can only see a point in the 2nd one. The first and third shouldn't ever be able to change anything since we are only writing to local memory? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
