Re: [BUGS] BUG #6041: Unlogged table was created bad in slave node - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [BUGS] BUG #6041: Unlogged table was created bad in slave node
Date
Msg-id 1307421013-sup-7855@alvh.no-ip.org
Whole thread Raw
List pgsql-hackers
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@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
> >> <alvherre@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 <robertmhaas@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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Jignesh Shah
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Next
From: Tom Lane
Date:
Subject: Re: Re: [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD