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
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 |