Hi,
trying to compile PostgreSQL 7.1.3 (my system: Linux Debian-ish,
fairly new Gnu libc (where I think the problem resides):
gcc 2.95.4 and GNU libc 2.2.4 bails out at:
| input.c: In function `initializeInput':
| input.c:157: warning: passing arg 1 of `on_exit' from incompatible pointer type
* Larry Rosenman <[EMAIL PROTECTED]> [010907 21:06]:
> I finally got all the way through a compile set:
>
> CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
> --with-CXX --with-perl --enable-multibyte --enable-cassert \
> --with-includes=/usr/local/include --with-
I finally got all the way through a compile set:
CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-includes=/usr/local/include --with-libs=/usr/local/lib \
--enable-debug \
--wi
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> This is the last part of a "vacuum verbose analyze;":
Um, would you be using glibc 2.2.2 by any chance? If so, update.
See the thread at
http://fts.postgresql.org/db/mw/msg.html?mid=1021209
regards, tom lane
This is the last part of a "vacuum verbose analyze;":
NOTICE: --Relation pg_toast_17058--
NOTICE: Pages 2: Changed 0, reaped 0, Empty 0, New 0; Tup 9: Vac 0, Keep/VTL 0/0,
Crash 0, UnUsed 0, MinLen 113, MaxLen 2034; Re-using: Free/Avai
l. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u
John Summerfield <[EMAIL PROTECTED]> writes:
> I have postmaster configured to use syslog. Despite this, these messages appear on
>the terminal from which I start it:
> 2001-09-03 23:44:37 [26371] DEBUG: recycled transaction log file 0044
Ah, I see what's causing that. elog.c does
I said:
> Changing the rewriter to error out when it couldn't really Do The Right
> Thing seemed like a good idea at the time, but now it seems clear that
> this didn't do anything to enhance the usefulness of the system. Unless
> someone objects, I'll change it back for 7.2.
Not having seen any
2 questions:
1) Have you recently run an analyze?
2) Are you sure that an index scan would be more efficient than a seq
scan? (are less than 25% of the records selected) I don't know the
break-off boint in the query optimizer, but it may be more efficient on
that table to read the whole thing.
Try coercing your constants to int8 explicitly:
... WHERE int8col = 42::int8;
See the archives for more info about this.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
Mauro Flores ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Index using INT8 data type is ignored
Long Description
I have some tables on my data base with index and primary keys over int8(bigint) data
type columns. Postgress
Still Fails here
LER
* Bruce Momjian <[EMAIL PROTECTED]> [010907 11:27]:
>
> I am seeing no failure here with enable-multibyte and enable-locale.
> Can you update cvs, do a make clean, and try again.
>
> > * Marc G. Fournier <[EMAIL PROTECTED]> [010907 10:06]:
> > > CVSROOT: /home/project
I am seeing no failure here with enable-multibyte and enable-locale.
Can you update cvs, do a make clean, and try again.
> * Marc G. Fournier <[EMAIL PROTECTED]> [010907 10:06]:
> > CVSROOT:/home/projects/pgsql/cvsroot
> > Module name:pgsql
> > Changes by: [EMAIL PROTECTED] 01/09/07
* Marc G. Fournier <[EMAIL PROTECTED]> [010907 10:06]:
> CVSROOT: /home/projects/pgsql/cvsroot
> Module name: pgsql
> Changes by: [EMAIL PROTECTED] 01/09/07 11:01:45
>
> Modified files:
> src/backend/utils/mb: encnames.c
>
> Log message:
> Remove variable length macros used
On Fri, Sep 07, 2001 at 12:30:44AM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > My pattern of use for ``CREATE RULE... NOTIFY...'' was [...]
> Yeah, that is the normal and recommended usage pattern for NOTIFY, so
> getting a NOTIFY when nothing actually happened is fairly harmless.
> (U
Steve Pothier <[EMAIL PROTECTED]> writes:
> psql 7.1 but the server is (apparently) 7.0.3. I say "apparently"
> because I'm not sure how to find the version of the server!
select version();
regards, tom lane
---(end of broadcast)-
=?iso-8859-2?B?o3VrYXN6IFNrb3dyb/Fza2k=?= <[EMAIL PROTECTED]> writes:
> Well, we would like our application to be compatible with PG 7.0 so I need
> to track this behaviour. Do you have a clue when PG could write anything to
> a view file and where I can find it in source tree?
Perhaps your app d
From: Tom Lane <[EMAIL PROTECTED]>
> > I created a view named some_view. Postgresql behaves quite strange
> > because it creates some_view file which has almost 600 MB.
>
> Uh ... what PG version is this? In recent releases views don't even
> *have* any associated file.
Hi Tom!
It is PG
17 matches
Mail list logo
