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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Дата
Msg-id CA+Tgmoaa+dF1GdQ=b5Oadikj3vcxyW6B81xVTAJE8JXbnTHH=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: mdnblocks() sabotages error checking in _mdfd_getseg()  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On Thu, Dec 10, 2015 at 12:55 PM, Greg Stark <stark@mit.edu> wrote:
> 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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: REASSIGN OWNED doesn't know how to deal with USER MAPPINGs
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: mdnblocks() sabotages error checking in _mdfd_getseg()