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

Re: Moving more work outside WALInsertLock

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Moving more work outside WALInsertLock
Date: 2011-12-15 23:42:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Dec 15, 2011 at 6:50 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

>> unless you are proposing to remove
>> the prev_link from the scope of the CRC, which is not exactly a
>> penalty-free change.
> We could CRC the rest of the record header before getting the lock, though,
> and only include the prev-link while holding the lock. I micro-benchmarked
> that a little bit, but didn't see much benefit from doing just that. Once
> you do more drastic changes so that the lock doesn't need to be held while
> copying the data and calculating the CRC of the record header, so that those
> things can be done in parallel, it matters even less.

You missed your cue to discuss leaving the prev link out of the CRC altogether.

On its own that sounds dangerous, but its not. When we need to confirm
the prev link we already know what we expect it to be, so CRC-ing it
is overkill. That isn't true of any other part of the WAL record, so
the prev link is the only thing we can relax, but thats OK because we
can CRC check everything else outside of the locked section.

That isn't my idea, but I'm happy to put it on the table since I'm not shy.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-12-16 00:04:20
Subject: Re: RangeVarGetRelid()
Previous:From: Simon RiggsDate: 2011-12-15 23:37:18
Subject: Re: Moving more work outside WALInsertLock

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