Re: [BUGS] BUG #6041: Unlogged table was created bad in slave node

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
> <alvherre(at)commandprompt(dot)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
> >> <alvherre(at)commandprompt(dot)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 <robertmhaas(at)gmail(dot)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 <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support