-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 06 July 2005 04:11
To: Tom Lane
Cc: Dave Page; Christopher Kings-Lynne; Robert Treat; Dawid
Kuroczko; Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [HACKERS] [PATCHES] Dbsize backend
On Tue, Jul 05, 2005 at 07:20:48PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Ok Tom, you win. It is indeed possible to make it work, and the
resulting makefile is even cleaner than before.
Following patch thus autoconfigures pgcrypto. It drops the
possibility to use libc's
Tom Lane said:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, now we have a problem. :-(
No kidding. I said to begin with that this plan to use target-specific
configuration knowledge to build a program executable by the host would
not work. I'm for reverting Peter's initial patch;
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, now we have a problem. :-(
No kidding. I said to begin with that this plan to use target-specific
configuration knowledge to build a program executable by the host would
not work. I'm for reverting Peter's initial patch;
Bruce Momjian pgman@candle.pha.pa.us writes:
Add to this something Magnus mentioned that I did not see until just
now. The backend links in timezone/SUBSYS.o, which doesn't use pgport,
so you have pgport versions and native versions of some functions in the
same backend binary. I am not sure
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Add to this something Magnus mentioned that I did not see until just
now. The backend links in timezone/SUBSYS.o, which doesn't use pgport,
so you have pgport versions and native versions of some functions in the
same backend
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
The patch was never supposed to change timezone/SUBSYS.o! Only the zic
executable. If it's having any side effects on what goes into SUBSYS.o,
it's simply wrong.
Well, my NO_PGPORT is affecting timezone/SUBSYS.o because there is
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
The patch was never supposed to change timezone/SUBSYS.o! Only the zic
executable. If it's having any side effects on what goes into SUBSYS.o,
it's simply wrong.
Well, my NO_PGPORT is affecting
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
In the meantime though it's utterly clear that this entire series of
patches is a failed experiment. Please revert the lot.
I can pull out NO_PGPORT, but what commit causes the original problem?
Was it only one? (I wasn't
It should be mentioned in documentation that after pgsql's crash GiST indexes
may restore some incorrect way: with invalid tuples. Of course, not every
time. Index will work absolutly correct but possibly with some performance
degradation (not big). 'Vacuum full' resolves this problem and
Robert Perry [EMAIL PROTECTED] writes:
I have also been bitten by the problem you are describing. But,
that one is a problem even when called from psql if I am not
mistaken. Does psql not use pqlib? Perhaps it is something about
PQexecParams that is the problem. I will test in a
Marko Kreen marko@l-t.ee writes:
! PG_CPPFLAGS := $(CF_CFLAGS) -I$(srcdir) $(PG_CPPFLAGS)
...
! PG_CPPFLAGS = $(CF_CFLAGS) -I$(srcdir)
Ah, right. Actually we don't need -I$(srcdir) either, since pgxs.mk
adds that automatically.
regards, tom lane
Teodor Sigaev wrote:
It should be mentioned in documentation that after pgsql's crash GiST
indexes may restore some incorrect way: with invalid tuples. Of
course, not every time. Index will work absolutly correct but possibly
with some performance degradation (not big). 'Vacuum full' resolves
On Wed, 6 Jul 2005, Joshua D. Drake wrote:
Teodor Sigaev wrote:
It should be mentioned in documentation that after pgsql's crash GiST
indexes may restore some incorrect way: with invalid tuples. Of course,
not every time. Index will work absolutly correct but possibly with some
performance
Tom Lane wrote:
I can pull out NO_PGPORT, but what commit causes the original
problem? Was it only one? (I wasn't watching.)
This one:
2005-07-03 14:54 petere
Attached is the patch, in case someone wants to revert it. (I'd do it
myself but I suppose this would interfere with rolling
Tom Lane wrote:
We might have to move zic into a separate directory so that it can be
compiled on its own with its own copies of the relevant .o files.
Up next: rewriting zic in Perl :-)
No seriously, when the dust has settled I think we should just put in a
note into the makefile (or perhaps
On Wed, 2005-06-29 at 23:23 -0400, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Uh, what exactly did you cut out? I suggested dropping the dumping of
full page images, but not removing CRCs altogether ...
Attached is the patch I used.
OK, thanks for the clarification. So it
Peter Eisentraut wrote:
Tom Lane wrote:
I can pull out NO_PGPORT, but what commit causes the original
problem? Was it only one? (I wasn't watching.)
This one:
2005-07-03 14:54 petere
Attached is the patch, in case someone wants to revert it. (I'd do it
myself but I suppose
OK, I have backed out Peter's change, and the NO_PGPORT workarounds.
---
Peter Eisentraut wrote:
Tom Lane wrote:
We might have to move zic into a separate directory so that it can be
compiled on its own with its own
Simon Riggs wrote:
On Wed, 2005-06-29 at 23:23 -0400, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Uh, what exactly did you cut out? I suggested dropping the dumping of
full page images, but not removing CRCs altogether ...
Attached is the patch I used.
OK, thanks for
Bruce Momjian wrote:
Andrew Dunstan wrote:
There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.
OK, I missed that one. I see it at:
http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php
I applied the attached patch from
Bruce Momjian wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.
OK, I missed that one. I see it at:
http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php
I
On Wed, 2005-07-06 at 18:22 -0400, Bruce Momjian wrote:
Well, I added #1 yesterday as 'full_page_writes', and it has the same
warnings as fsync (namely, on crash, be prepared to recovery or check
your system thoroughly.
Yes, which is why I comment now that the GUC alone is not enough.
There
Tom, I think you're the only person that could or would be trusted to
make such a change. Even past the 8.1 freeze, I say we need to do
something now on this issue.
I think if we document full_page_writes as similar to fsync in risk, we
are OK for 8.1, but if something can be done easily, it
Simon Riggs wrote:
I agree we *must* have the GUC, but we also *must* have a way for crash
recovery to tell us for certain that it has definitely worked, not just
maybe worked.
Doesn't the same argument apply to the existing fsync = off case? i.e.
we already have a case where we don't provide
You could work around this by explicitly specifying the parameter
type as text or varchar or whatever the domain's base type is.
I wonder though if we oughtn't change the backend so that the inferred
type of a parameter symbol is never a domain, but the domain's base
type. That would force the
Per Andrew (he is having email problems):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=viperdt=2005-07-07%2001:10:01
Joshua D. Drkae
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
How about a PQescapeIdentifier function in libpq? :)
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2005-07-06 at 18:22 -0400, Bruce Momjian wrote:
Well, I added #1 yesterday as 'full_page_writes', and it has the same
warnings as fsync (namely, on crash, be prepared to recovery or check
your system thoroughly.
Yes, which is why I comment now
On Wed, Jul 06, 2005 at 21:48:44 +0100,
Simon Riggs [EMAIL PROTECTED] wrote:
We could implement the torn-pages option, but that seems a lot of work.
Another way of implementing a tell-tale would be to append the LSN again
as a data page trailer as the last 4 bytes of the page. Thus the LSN
Bruno Wolff III [EMAIL PROTECTED] writes:
Are you sure about that? That would probably be the normal case, but are
you promised that the hardware will write all of the sectors of a block
in order?
I don't think you can possibly assume that. If the block crosses a
cylinder boundary then it's
Tom Lane wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
Are you sure about that? That would probably be the normal case, but are
you promised that the hardware will write all of the sectors of a block
in order?
I don't think you can possibly assume that. If the block crosses a
Joshua D. Drake wrote:
Per Andrew (he is having email problems):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=viperdt=2005-07-07%2001:10:01
Thanks, fixed (I hope).
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610)
On Fri, 24 Jun 2005 09:21:56 -0700
Josh Berkus josh@agliodbs.com wrote:
Jim,
Josh, is this something that could be done in the performance lab?
That's the idea. Sadly, OSDL's hardware has been having critical failures
of
late (I'm still trying to get test results on the
34 matches
Mail list logo
