Martijn van Oosterhout wrote:
This will close the file *only* if yyin is NULL, which probably isn't
what is meant.
Ops... you're right. :-)
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > However, it seems the right fix is to move BufferGetPageSize and
> > BufferGetPage from bufpage.h to bufmgr.h.
>
> That sounds sane if it fixes the problem.
Actually it's not, because bufmgr.h does not include bufpage.h, and it
know
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> However, it seems the right fix is to move BufferGetPageSize and
> BufferGetPage from bufpage.h to bufmgr.h.
That sounds sane if it fixes the problem.
> (Digging further, it seems like bufpage.h should also include transam.h
> in order to get Transacti
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which
> is a change you had objected to previously :-(
> http://archives.postgresql.org/pgsql-patches/2008-04/msg00149.php
Hmm. I did notice that the patch seemed to need to add bufmgr.h
Alvaro Herrera wrote:
> Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which
> is a change you had objected to previously :-(
However, it seems the right fix is to move BufferGetPageSize and
BufferGetPage from bufpage.h to bufmgr.h.
(Digging further, it seems like bufpage.h sho
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > So here's a patch (includes the #ifndef FRONTEND hack in htup.h.)
> >
> > I like this except for the #ifndef FRONTEND hack --- you're going to
> > need to fix that before applying. I'm good with doing tha
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So here's a patch (includes the #ifndef FRONTEND hack in htup.h.)
>
> I like this except for the #ifndef FRONTEND hack --- you're going to
> need to fix that before applying. I'm good with doing that by pushing
> the system attribut
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So here's a patch (includes the #ifndef FRONTEND hack in htup.h.)
I like this except for the #ifndef FRONTEND hack --- you're going to
need to fix that before applying. I'm good with doing that by pushing
the system attribute numbers into a separate he
Hans-Juergen Schoenig wrote:
regards, tom lane
overhead is not an issue here - if i lose 10 or 15% i am totally fine as
long as i can reduce vacuum overhead to an absolute minimum.
overhead will vary with row sizes anyway - this is not the point.
I am not buying this argume
Hans-Juergen Schoenig <[EMAIL PROTECTED]> writes:
> overhead is not an issue here - if i lose 10 or 15% i am totally fine as
> long as i can reduce vacuum overhead to an absolute minimum.
I cannot see the sanity of taking a ~10% hit on all I/O activity
(especially foreground queries) to avoid hav
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
... Keep in mind you're proposing to make everything run 3% slower instead of
using that 3% i/o bandwidth headroom to run vacuum outside the critical path.
I think that's actually understating the problem. Assuming this is a
64
Gregory Stark <[EMAIL PROTECTED]> writes:
> ... Keep in mind you're proposing to make everything run 3% slower instead of
> using that 3% i/o bandwidth headroom to run vacuum outside the critical path.
I think that's actually understating the problem. Assuming this is a
64-bit machine (which it h
On Sat, May 10, 2008 at 10:41:56PM -0400, Andrew Sullivan wrote:
> On Sat, May 10, 2008 at 11:55:29AM -0400, Tom Lane wrote:
> > IMHO a utility command should do one easily-explained thing. The
> > fewer options the better.
>
> Sticking to that principle makes for a better-maintained system. I
>
Nikhils <[EMAIL PROTECTED]> writes:
> ... One minor thing that myself and Alex discussed was
> the usage of "child tables" in tablecmds.c, especially in error messages.
> Again English is not my native language, but shouldn't that be worded as
> "children tables"? Admittedly even this does not soun
On Sat, May 10, 2008 at 11:02 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Where are we on this?
I haven't had time to do any work since the original patch. That patch
was fairly basic - it just ran install / uninstall scripts and created
catalog entries, and introduced some slightly exotic sy
"Hans-Juergen Schoenig" <[EMAIL PROTECTED]> writes:
> my DB is facing around 600mio transaction a month. 85% of those contain at
> least some small modification so I cannot save on XIDs.
What's a "mio"? Assuming it's short for "million" I don't see the problem. The
transaction horizon is 2 *billi
hello everybody,
i know that we have discussed this issue already. my view of the problem
has changed in the past couple of weeks, however. maybe other people had
similar experiences.
i have been working on a special purpose application which basically
looks like that:
- 150.000 tables (f
Joshua D. Drake wrote:
Tom Lane wrote:
Well it should be optional but it would be nice if we had the option
to have it renamed per the default... meaning the same output if I
were to do this:
If you want that, you can rename the index (either before or afterwards).
I don't see any reason to
On Sun, May 11, 2008 at 02:19:05AM -0300, Euler Taveira de Oliveira wrote:
> Alvaro Herrera wrote:
>
> >Huh, isn't the test backwards?
> >
> In which way? I use a simple one but whatever test that uses 'exec sql
> include foo' and foo.h doesn't exist, it will crash.
I think he means specifically
Hi,
On Sat, May 10, 2008 at 6:11 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Fri, May 9, 2008 at 5:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> >> [ patch to change inherited-check-constraint behavior ]
> >
> > Applied after rather heavy editor
20 matches
Mail list logo
