Tom Lane wrote:
> Yeah, *only because you said VERBOSE*. When we implemented the current
> elog level scheme, we designed INFO as non-suppressible so that it would
> mimic the previous behavior of VACUUM VERBOSE.
>
Agreed.
> If REINDEX had a VERBOSE option, it would make sense to put out the
>
I got a field with a datatype of varchar(40) in one of my table
client_encoding = LATIN9
When I use COPY to transfer records to my table
I got an error message "Error: value too long for type character varying(40)"
When I check the offending record it seems that one of the character
in the fiel
Tom Lane wrote:
> No, because the external pidfile has zero to do with Postgres' internal
> behavior.
>
+1. So we have two options: have external_pid_file mimics the internal
behavior or deprecates it.
I couldn't find the discussion about it; just the patch [1]. IIRC this
'feature' was proposed
On Tue, Jun 06, 2006 at 11:32:53PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Doesn't removing the file reduce the chances of failing to start later
> > in case another postmaster already has that pid?
>
> No, because the external pidfile has zero to do with Postgres' internal
> behavior.
Tom Lane wrote:
> Bruce Momjian writes:
> > I thought it needed changing for consistency. Shouldn't status messages
> > like this be INFO:
> > test=> REINDEX DATABASE test;
> > NOTICE: table "pg_class" was reindexed
>
> > If I do VACUUM VERBOSE, those messages are INFO.
>
> Yeah, *only
Bruce Momjian writes:
> I thought it needed changing for consistency. Shouldn't status messages
> like this be INFO:
> test=> REINDEX DATABASE test;
> NOTICE: table "pg_class" was reindexed
> If I do VACUUM VERBOSE, those messages are INFO.
Yeah, *only because you said VERBOSE*. W
Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. Thanks.
>
> Why is this an improvement? AFAIR an INFO message is *not suppressible*
> by adjusting client_min_messages, therefore this makes the system more
> chatty not less so. It certainly doesn't do anything to address the
> origin
Bruce Momjian writes:
> Patch applied. Thanks.
Why is this an improvement? AFAIR an INFO message is *not suppressible*
by adjusting client_min_messages, therefore this makes the system more
chatty not less so. It certainly doesn't do anything to address the
original complaint.
Adam <[EMAIL PROTECTED]> writes:
> The 'configure --enable-thread-safety' script fails when CFLAGS
> contain "-mcpu=7400", "-mcpu=970" or "-maltivec".
This has been discussed before, and the conclusion was "don't do that".
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00104.php
> I w
Adam wrote:
> Greetings,
>
> There is a problem with PostgreSQL 8.1.4 on Mac OS X (PowerPC).
>
> The 'configure --enable-thread-safety' script fails when CFLAGS
> contain "-mcpu=7400", "-mcpu=970" or "-maltivec". With these flags,
> the GCC compiler enables AltiVec instructions for the PowerP
Patch applied. Thanks.
---
Euler Taveira de Oliveira wrote:
> > I used wanted to point out the the ( -q, --quiet ) parameter for
> > reindexdb command utility does not work.
> Actually it is *not* a bug. The NOTICE is pr
Greetings,
There is a problem with PostgreSQL 8.1.4 on Mac OS X (PowerPC).
The 'configure --enable-thread-safety' script fails when CFLAGS
contain "-mcpu=7400", "-mcpu=970" or "-maltivec". With these flags,
the GCC compiler enables AltiVec instructions for the PowerPC
processor, and define
The following bug has been logged online:
Bug reference: 2472
Logged by: Boris
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: win2000
Description:Incorrect ILIKE, ~* for Cyrilic symbols.
Details:
Microsoft Windows 2000 [Version 5.00.21
13 matches
Mail list logo
