Re: mdnblocks() sabotages error checking in _mdfd_getseg() - Mailing list pgsql-hackers

From Greg Stark
Subject Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Date
Msg-id CAM-w4HOSX2gCFiZ-L0cTp+9JAjeVLm3SJm6roXKrVLvsbAkHAQ@mail.gmail.com
Whole thread Raw
In response to Re: mdnblocks() sabotages error checking in _mdfd_getseg()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: mdnblocks() sabotages error checking in _mdfd_getseg()  (Andres Freund <andres@anarazel.de>)
Re: mdnblocks() sabotages error checking in _mdfd_getseg()  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> It's not straightforward, but I don't think that's the reason.  What
> we could do is look at the call sites that use
> RelationGetNumberOfBlocks() and change some of them to get the
> information some other way instead.  I believe get_relation_info() and
> initscan() are the primary culprits, accounting for some enormous
> percentage of the system calls we do on a read-only pgbench workload.
> Those functions certainly know enough to consult a metapage if we had
> such a thing.

Would this not run into a chicken and egg problem with recovery?
Unless you're going to fsync the meta page whenever the file is
extended you'll have to xlog any updates to it and treat the values in
memory as authoritative. But when replaying xlog you'll see obsolete
inconsistent versions on disk and won't have the correct values in
memory either.

It seems to me that if you want to fix the linked lists of files
that's orthogonal to whether the file lengths on disk are
authoritative. You can always keep the lengths or at least the number
of files cached and updated in shared memory in a more efficient
storage format.

-- 
greg



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Error with index on unlogged table
Next
From: Andres Freund
Date:
Subject: Re: mdnblocks() sabotages error checking in _mdfd_getseg()