Re: mdnblocks() sabotages error checking in _mdfd_getseg()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Date: 2015-12-10 18:18:41
Message-ID: CA+Tgmoaa+dF1GdQ=b5Oadikj3vcxyW6B81xVTAJE8JXbnTHH=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 10, 2015 at 12:55 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas <robertmhaas(at)gmail(dot)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?

No.

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

All true, but irrelevant. The places I just mentioned wouldn't get
called during recovery. They're only invoked from queries.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-12-10 18:22:29 Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Previous Message Jaime Casanova 2015-12-10 18:10:03 Re: REASSIGN OWNED doesn't know how to deal with USER MAPPINGs