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 по дате отправления: