Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-07-03 Thread Robert Haas
On Thu, Jun 30, 2011 at 6:19 PM, Jeff Davis wrote: > On Thu, 2011-06-30 at 07:50 -0400, Robert Haas wrote: >> I compare the performance of commit >> 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (post-patch) with commit >> 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (pre-patch). > > I believe that is a co

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-30 Thread Jeff Davis
On Thu, 2011-06-30 at 07:50 -0400, Robert Haas wrote: > I compare the performance of commit > 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (post-patch) with commit > 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (pre-patch). I believe that is a copy/paste error. Regards, Jeff Davis -- Sent via

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-30 Thread Robert Haas
On Tue, Jun 28, 2011 at 12:29 PM, Robert Haas wrote: > On Tue, Jun 28, 2011 at 11:44 AM, Cédric Villemain > wrote: >> out of curiosity, does it affect the previous benchmarks of the feature ? > > I don't think there's much performance impact, because the only case > where we actually have to do a

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-28 Thread Robert Haas
On Tue, Jun 28, 2011 at 11:44 AM, Cédric Villemain wrote: > out of curiosity, does it affect the previous benchmarks of the feature ? I don't think there's much performance impact, because the only case where we actually have to do any real work is when vacuum comes through and marks a buffer we'

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-28 Thread Cédric Villemain
2011/6/27 Robert Haas : > On Thu, Jun 23, 2011 at 9:22 AM, Robert Haas wrote: >> On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas wrote: >>> Well, it seems I didn't put nearly enough thought into heap_update(). >>> The fix for the immediate problem looks simple enough - all the code >>> has been ref

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-27 Thread Robert Haas
On Thu, Jun 23, 2011 at 9:22 AM, Robert Haas wrote: > On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas wrote: >> Well, it seems I didn't put nearly enough thought into heap_update(). >> The fix for the immediate problem looks simple enough - all the code >> has been refactored to use the new API, so

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-23 Thread Robert Haas
On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas wrote: > Well, it seems I didn't put nearly enough thought into heap_update(). > The fix for the immediate problem looks simple enough - all the code > has been refactored to use the new API, so the calls can be easily be > moved into the critical sect

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-22 Thread Robert Haas
On Wed, Jun 22, 2011 at 9:12 AM, Robert Haas wrote: > On Wed, Jun 22, 2011 at 6:55 AM, Heikki Linnakangas > wrote: >> On 22.06.2011 06:05, Robert Haas wrote: >>> >>> Second, when inserting, updating, or deleting >>> a tuple, we can no longer get away with clearing the visibility map >>> bit after

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-22 Thread Robert Haas
On Wed, Jun 22, 2011 at 6:55 AM, Heikki Linnakangas wrote: > On 22.06.2011 06:05, Robert Haas wrote: >> >> Second, when inserting, updating, or deleting >> a tuple, we can no longer get away with clearing the visibility map >> bit after releasing the lock on the corresponding heap page, because >>

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-22 Thread Heikki Linnakangas
On 22.06.2011 06:05, Robert Haas wrote: Second, when inserting, updating, or deleting a tuple, we can no longer get away with clearing the visibility map bit after releasing the lock on the corresponding heap page, because an intervening crash might leave the visibility map bit set and the page-l