2011/6/27 Robert Haas <robertmh...@gmail.com>: > On Thu, Jun 23, 2011 at 9:22 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas <robertmh...@gmail.com> 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 section (see attached). But looking at this a >>> little more, I see that heap_update() is many bricks short of a load, >>> because there are several places where the buffer can be unlocked and >>> relocked, and we don't recheck whether the page is all-visible after >>> reacquiring the lock. So I've got some more work to do here. >> >> See what you think of the attached. I *think* this covers all bases. >> It's a little more complicated than I would like, but I don't think >> fatally so. > > For lack of comment, committed. It's hopefully at least better than > what was there before, which was clearly several bricks short of a > load.
out of curiosity, does it affect the previous benchmarks of the feature ? > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
