Re: could not truncate directory "pg_serial": apparent wraparound

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: could not truncate directory "pg_serial": apparent wraparound
Date: 2011-06-09 08:56:41
Message-ID: 4DF08AC9.4060707@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While testing this, I noticed another serious bug in the OldSerXidSLRU
handling: we never set the dirty-flag on any page. I believe the reason
we haven't bumped into this in testing before is that when a new page is
initialized, it's marked as dirty, so everything goes smoothly when we
modify recently-zeroed pages. But if a page falls out of the cache, and
is later read back in and modified, the modifications are lost.

The comments in SLRU could be more explicit about this. It was
coincidental that I started to wonder where the pages are marked as
dirty, I somehow thought the SLRU functions do that for you.

Fortunately the fix is very simple, we just need to set the page_dirty
flag whenever we modify an slru page. But clearly this slru stuff needs
more testing. It's pretty hard to write good repeatable test cases for
these things, though.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-06-09 09:09:23 Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous Message Marti Raudsepp 2011-06-09 08:29:24 Re: [PATCH] Allow star syntax in GROUP BY, as a shorthand for all table columns