Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Magic block for modules

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Magic block for modules
Date: 2006-05-31 09:47:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Magnus Hagander wrote:
> > > On Sun, May 07, 2006 at 08:21:43PM -0400, Tom Lane wrote:
> > >> I'm pretty sure we had agreed that magic blocks should be 
> > required; 
> > >> otherwise this check will accomplish little.
> > 
> > > Sure, I just didn't want to break every module in one 
> > weekend. I was 
> > > thinking of adding it with LOG level now, send a message on 
> > -announce 
> > > saying that at the beginning of the 8.2 freeze it will be an ERROR.
> > > Give people time to react.
> > 
> > Now that the magic-block patch is in, we need to revisit this 
> > bit of the discussion.  I'm for making lack of a magic block 
> > an ERROR immediately.
> > I don't see the point of waiting; in fact, if we wait till 
> > freeze we'll just make the breakage more concentrated.  At 
> > the very least it ought to be a WARNING immediately, because 
> > a LOG message is just not visible enough.
> > 
> > Comments?
> If it's eventually going to be an ERROR, it's better to make it ERROR
> from the start.
> People working off cvs snapshot will (hopefully) expect temporary
> breakage during the development period. In general, you'd expect less
> breakage the closer to release you are.

I say make it an ERROR and we can relax it later.  If you make it a
warning, we might not hear about it.

  Bruce Momjian

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Marko KreenDate: 2006-05-31 10:08:41
Subject: Re: [PATCH] Magic block for modules
Previous:From: Andreas PflugDate: 2006-05-31 09:38:05
Subject: copy with compression progress n

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group