Excerpts from Robert Haas's message of mar jun 07 00:07:06 -0400 2011: > Did you intentionally fail to copy the list?
No, I noticed after I sent it ... > On Tue, Jun 7, 2011 at 12:03 AM, Alvaro Herrera > <alvhe...@commandprompt.com> wrote: > > Excerpts from Robert Haas's message of lun jun 06 22:29:02 -0400 2011: > >> On Fri, Jun 3, 2011 at 1:01 PM, Alvaro Herrera > >> <alvhe...@commandprompt.com> wrote: > >> > Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011: > >> >> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas <robertmh...@gmail.com> > >> >> wrote: > >> > > >> >> > (4) It strikes me that it might be possible to address this problem a > >> >> > bit more cleanly by allowing mdnblocks() and smgrnblocks() and > >> >> > RelationGetNumberOfBlocksInFork() to take a boolean argument > >> >> > indicating whether or not an error should be thrown if the underlying > >> >> > physical file happens not to exist. When no error is to be signaled, > >> >> > we simply return 0 when the main fork doesn't exist, rather than > >> >> > throwing an error. > >> >> > >> >> If we don't want to gum this with the above-mentioned cruft, the other > >> >> obvious alternative here is to do nothing, and live with the > >> >> non-beauty of the resulting error message. > >> > > >> > Option 4 seems reasonable to me ... can you get rid of the dupe > >> > smgrnblocks call simultaneously? > >> > >> What dup smgrnblocks call? > > > > Err, weren't you saying in option (3) that mdnblocks was being called > > twice during query planning? If I'm talking nonsense feel free to > > ignore me. > > Oh. It is, but there's no way to avoid that... > > >> Patch along these lines attached. > > > > The declaration vs. definition of these functions seem contradictory -- > > is the third arg "missing_ok" or "fail_if_missing"? > > Woops. I started with it as fail_if_missing and then decided it > should be missing_ok. I can fix that... > -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
