On Fri, Jun 5, 2015 at 1:47 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Fri, Jun 5, 2015 at 11:47 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Fri, Jun 5, 2015 at 9:29 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> Here's a new version with some more fixes and improvements: >>> [...] >> >> With this patch, when I run the script >> "checkpoint-segment-boundary.sh" from >> http://www.postgresql.org/message-id/CAEepm=1_KbHGbmPVmkUGE5qTP+B4efoCJYS0unGo-Mc5NV=u...@mail.gmail.com >> I see the following during shutdown checkpoint: >> >> LOG: could not truncate directory "pg_multixact/offsets": apparent >> wraparound >> >> That message comes from SimpleLruTruncate. > > Suggested patch attached.
Is it a problem that we don't drop/forget page buffers from the members SLRU (unlike SimpleLruTruncate, which is used for the offsets SLRU)? I may be missing something but it seems to me that it isn't, because (1) CheckPointMultiXact is called to flush any dirty pages to disk before TruncateMultiXact is called and (2) no pages older than the one holding the oldest offset should be dirtied after CheckPointMultiXact runs (member space is 'append only', at least until it is recycled), so any pages in the SLRU whose underlying file has been truncated should just naturally fall out of the LRU slots. So they can't create problems by being written to disk after the unlink. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
