Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> animal: lionfishwarnings: 16
>> scan.l:180: warning, the character range [<80>-] is ambiguous in a
>> case-insensitive scanner
>> scan.l:180: warning, the character range [<80>-] is ambiguous in a
>> case-insensitive
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> some more(I have removed duplicates and ones that should be fixed by
> your latest commits though):
I did what I could with this batch. Some comments:
> animal: salamander warnings: 27
> cash.c: In function `cash_in':
> cash.c:244: warn
"Sibte Abbas" <[EMAIL PROTECTED]> writes:
> Considering the above fact, perhaps the actual problem is that when a
> column gets removed from a table as a result of drop type/domain> cascade, the tuple descriptor (more specifically
> rel->rd_att field) for that relation is not updated properly?
N
On 7/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
In the regression database:
regression=# select schema_to_xmlschema('public',false,false,'foo');
ERROR: cache lookup failed for type 0
I have no idea what this function should produce, but surely not that?
regards, tom la
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> animal: lionfishwarnings: 16
> scan.l:180: warning, the character range [<80>-] is ambiguous in a
> case-insensitive scanner
> scan.l:180: warning, the character range [<80>-] is ambiguous in a
> case-insensitive scanner
> scan.l:302: w
On Thu, 12 Jul 2007, Stefan Kaltenbrunner wrote:
> > What would probably be useful if you want to pursue this is to filter
> > out the obvious spam like statement-not-reached, and see what's left.
>
I had gone through and looked at the warnings on mongoose before, but I am
running it against the
Kris Jurka <[EMAIL PROTECTED]> writes:
> So pam_message ** isn't const.
Ah, thanks. I see luna_moth is giving the same warning, so it's still
not const in Solaris 11 either.
Is it worth working around this? It's strictly cosmetic AFAICS.
The main issue in my mind would be how to determine whet
Tom Lane wrote:
At the same time, if anyone wants to trim the existing code down to a
small test case, I'm sure the gcc boys would appreciate a bug report.
I reduced it to a self-contained test case, and filed bug in GCC
bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32750
Surprisingl
On Thu, 12 Jul 2007, Tom Lane wrote:
static int pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg,
struct pam_response ** resp, void *appdata_ptr);
which exactly matches what my Fedora 6 pam header file says it should
be. What is it on those Solaris machin
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> animal: dragonfly warnings: 67
> auth.c:61: warning: initialization from incompatible pointer type
> animal: emperor_mothwarnings: 10
> auth.c:61: warning: initialization from incompatible pointer type
Apparently, Solaris 9 and
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Somebody needs to figure out whether we are supposed to be using
>> pgsymlink on Cygwin.
> According to port.h:
> * Cygwin has its own symlinks which work on Win95/98/ME where
> * junction points don't, so use it instead. We have
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> FWIW, this patch makes the warnings go away, and makes the code a little
> bit more readable as well. It would be nice to understand why exactly
> it's complaining, though.
Let's apply the patch. We are clearly tickling a bug or near-bug in
gcc,
Tom Lane wrote:
animal: eel warnings: 4
dirmod.c:206: warning: no previous prototype for 'pgsymlink'
Somebody needs to figure out whether we are supposed to be using
pgsymlink on Cygwin.
According to port.h:
* Cygwin has its own symlinks which work on Win95/98/ME
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. It looks like I get that warning on my laptop as well. I tracked it
down to these two places:
Line 209:
while (ptr - GETARR(trg) < ARRNELEM(trg))
{
text *item = (text *) palloc(VARHDRSZ + 3);
S
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
The warning seems to be in related array indexing. If you replace ptr -
GETARR(trg) with a constant, the warning goes away. But having "i = ptr -
GETARR(trg)" in there doesn't give a warning.
Can you compile with -save-temp
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ok I did that for a few members (removing all the statement not reached
> ones as well as some purely informal notices and all the flex related
> warnings) and came up with something similiar to:
I've cleaned up most of this first batch. Open iss
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. It looks like I get that warning on my laptop as well. I tracked it
down to these two places:
Line 209:
while (ptr - GETARR(trg) < ARRNELEM(trg))
{
text *item = (text *) palloc(VARHDRSZ + 3);
S
Gregory Stark <[EMAIL PROTECTED]> writes:
> If it does constant propagation without handling overflow it could end up
> with:
> (olddatum >> 2 << 2) & 0x3FFFC
> note that in fact truncating the high two bits as the assembler did would in
> fact be the correct thing to do here which would exp
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> The warning seems to be in related array indexing. If you replace ptr -
> GETARR(trg) with a constant, the warning goes away. But having "i = ptr -
> GETARR(trg)" in there doesn't give a warning.
Can you compile with -save-temps and send the cor
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. It looks like I get that warning on my laptop as well. I tracked it
> down to these two places:
> Line 209:
>> while (ptr - GETARR(trg) < ARRNELEM(trg))
>> {
>> text *item = (text *) palloc(VARHDRSZ + 3);
>>
>> SET_VARSIZ
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Stefan showed me via Jabber this warning:
/tmp/ccM7MfqX.s: Assembler messages:
/tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to
fffc
/tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to
000
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Stefan showed me via Jabber this warning:
>>
>> /tmp/ccM7MfqX.s: Assembler messages:
>> /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
>> /tmp/ccM7MfqX.s:738: Warning: 0003fffc shorte
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Stefan showed me via Jabber this warning:
>> /tmp/ccM7MfqX.s: Assembler messages:
>> /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to
>> fffc
>> /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to
>> f
Alvaro Herrera wrote:
Stefan showed me via Jabber this warning:
/tmp/ccM7MfqX.s: Assembler messages:
/tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
/tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc
He says that this comes from trgm_op.c f
Alvaro Herrera wrote:
> Stefan showed me via Jabber this warning:
>
> /tmp/ccM7MfqX.s: Assembler messages:
> /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
> /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc
>
> He says that this comes from
Stefan showed me via Jabber this warning:
/tmp/ccM7MfqX.s: Assembler messages:
/tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
/tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc
He says that this comes from trgm_op.c file. I don't get the w
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> ok I did that for a few members (removing all the statement not reached
>> ones as well as some purely informal notices and all the flex related
>> warnings) and came up with something similiar to:
>> [snip]
>
> Yeah, this looks
In the regression database:
regression=# select schema_to_xmlschema('public',false,false,'foo');
ERROR: cache lookup failed for type 0
I have no idea what this function should produce, but surely not that?
regards, tom lane
---(end of broadcast)-
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Yeah, this looks like a good list. I can't readily check the ones from
>>> "eel" as they appear to be in Windows-specific code; anyone else want to
>>> fix those?
>
>> The pg_ctl one is a windows one, I'll deal w
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, this looks like a good list. I can't readily check the ones from
>> "eel" as they appear to be in Windows-specific code; anyone else want to
>> fix those?
> The pg_ctl one is a windows one, I'll deal with that one.
> The dirm
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> But the other problem I see here is that the solution hits more than
> just the problematic state. If we have bad pages on disk, for
> instance, we zero pages; we don't drop the table. Similarly, it
> seems that all that's necessary here is an externa
I think I have stumbled across a bug here;
While skipping queuing of an RI trigger for a non-FK UPDATE, the
"non-optimizable exception" check (see below) in trigger.c @
AfterTriggerSaveEvent() fails to handle SAVEPOINTs correctly and can
jovially leave inconsistent data behind at transaction com
On Wed, Jul 11, 2007 at 06:09:55PM -0400, Tom Lane wrote:
> This is really pretty silly to be getting worked up about. The command
> in question wouldn't have been allowed at all except to a superuser,
> and there are plenty of ways to catastrophically destroy your database
> when you are superuse
On Wed, Jul 11, 2007 at 10:47:25PM +0100, Simon Riggs wrote:
> expertise to isolate this as the error. I would prefer to explicitly
> avoid this kind of error, so that we can return to the idea that
> removing pg_twophase is never a requirement.
This was pretty much my point. It's one thing to sa
Gregory Stark <[EMAIL PROTECTED]> writes:
> I got this assertion failure today:
> postgres=# create table foo (i integer);
> CREATE TABLE
> postgres=# alter table foo add j integer;
> ALTER TABLE
> postgres=# alter table foo drop j;
> ALTER TABLE
> postgres=# create table foo2 () inherits (foo);
>
Tom Lane wrote:
Again, I'm trying to look at the big picture of both syntactic and
semantic errors. If we solve only the syntactic end of it I think we'd
actually be worse off, because then users would be even more lost when
they hit a semantic error (unwanted substitution).
The only real solu
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> ok I did that for a few members (removing all the statement not reached
>> ones as well as some purely informal notices and all the flex related
>> warnings) and came up with something similiar to:
>> [snip]
>
> Yeah, this looks
Simon Riggs wrote:
On Wed, 2007-07-11 at 18:09 -0400, Tom Lane wrote:
There seems like a number of ways that unresolved prepared transactions
can cause problems. We really need to have startup mention how many
prepared transactions there are, so we have some chance of understanding
and resolvin
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ok I did that for a few members (removing all the statement not reached
> ones as well as some purely informal notices and all the flex related
> warnings) and came up with something similiar to:
> [snip]
Yeah, this looks like a good list. I can'
Peter Eisentraut wrote:
> Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner:
>> a lot of those are simply noise (like the LOOP VECTORIZED stuff from the
>> icc boxes or the "statement not reached" spam from the sun compilers)
>> but others might indicate real issues.
>> To find warnin
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> What is the official stance on handling compiler warnings?
>
> The compilers I use give me 1 or 2 warnings on HEAD, coming from flex's
> sloppiness about not generating unused code. I wouldn't care to work
> with a compiler tha
Gregory Stark <[EMAIL PROTECTED]> writes:
> So instead of substituting them as the tokens are lexed, instead suck in the
> tokens, run the parser -- which we currently do anyways just to check the
> syntax -- then walk the tree looking for ColumnRefs where the name matches a
> variable name. Then k
Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner:
> a lot of those are simply noise (like the LOOP VECTORIZED stuff from the
> icc boxes or the "statement not reached" spam from the sun compilers)
> but others might indicate real issues.
> To find warnings that might be a real proble
Simon Riggs wrote:
On Wed, 2007-07-11 at 16:49 -0700, Joe Conway wrote:
On cvs head, I can get "tuple concurrently updated" if two separate
transactions are both trying to drop the same index:
ERROR: tuple concurrently updated
The reason I ask is that someone contacted me who is seeing
On Thursday 12 July 2007 04:19, Simon Riggs wrote:
> On Wed, 2007-07-11 at 18:09 -0400, Tom Lane wrote:
> > > There seems like a number of ways that unresolved prepared transactions
> > > can cause problems. We really need to have startup mention how many
> > > prepared transactions there are, so w
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote:
>>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
Seems like we could be slightly more friendly without too much bother:
at least only substitute after the
Simon Riggs wrote:
On Thu, 2007-07-12 at 16:17 +0200, Florian G. Pflug wrote:
To test my PITR-slave readonly-query patch, I continously do
insert into test ...
pg_switch_xlog()
sleep 1
on the master, and let the slave process the generated xlogs
The log output on the slave looks the following
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Actually, rather than get into that sort of AI-complete project,
> Is it really AI-complete? ISTM the *only* place where a parameter is allowed
> is where the parser inserts a ColumnRef node?
The first problem
On Thu, 2007-07-12 at 16:17 +0200, Florian G. Pflug wrote:
> To test my PITR-slave readonly-query patch, I continously do
> insert into test ...
> pg_switch_xlog()
> sleep 1
> on the master, and let the slave process the generated xlogs
>
> The log output on the slave looks the following (unneces
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> Seems like we could be slightly more friendly without too much bother:
>>> at least only substitute after the VALUES clause in INSERT.
>>
>> Surely you je
Hi
To test my PITR-slave readonly-query patch, I continously do
insert into test ...
pg_switch_xlog()
sleep 1
on the master, and let the slave process the generated xlogs
The log output on the slave looks the following (unnecessary lines remove)
LOG: restored log file "0001016E
I got this assertion failure today:
TRAP: FailedAssertion("!(new_max_attr >= oldrel->max_attr)", File:
"prepunion.c", Line: 1292)
>From running something like this:
postgres=# create table foo (i integer);
CREATE TABLE
postgres=# alter table foo add j integer;
ALTER TABLE
postgres=# alter tabl
On Thu, Jul 12, 2007 at 09:54:28AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Thanks for the pointer. Attached is what I came up with. If someone
> > autoconfy can sign off on that it seems correct, I'll apply that.
>
> Looks reasonable to me.
Thanks, applied and bac
Tatsuo,
fts configuration doesn't related to the encoding ! It's fully up to you
how to combine parser and dictionaries.
The problem arise only if you want
to define somehow so-called default configuration, which, as I inclined
now, is a bad feature. We choose locale name to identify default con
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> What is the official stance on handling compiler warnings?
The compilers I use give me 1 or 2 warnings on HEAD, coming from flex's
sloppiness about not generating unused code. I wouldn't care to work
with a compiler that generated more than a few
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Thanks for the pointer. Attached is what I came up with. If someone
> autoconfy can sign off on that it seems correct, I'll apply that.
Looks reasonable to me.
regards, tom lane
---(end of broadcast)---
What is the official stance on handling compiler warnings?
I got a bit curious today on how many warnings our builds are generating
on the buildfarm.
I have hacked up a small script that (in a very primitive way) parses
the "make" stage logfiles of all unix boxes reporting on HEAD and prints
the nu
On Thu, 12 Jul 2007, alexander lunyov wrote:
Oleg Bartunov wrote:
alexander,
lc_ctype and lc_collate can be changed only at initdb !
You need to read localization chapter
http://www.postgresql.org/docs/current/static/charset.html
Yes, i knew about this, but i thought maybe somehow it can be
On Wed, Jul 11, 2007 at 01:41:56PM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>> I'm simply using
> >>> AC_CHECK_FUNC([krb5_free_unparsed_name])
> >>> which works fine on unix, but breaks on win32. Bec
Ühel kenal päeval, N, 2007-07-12 kell 14:00, kirjutas Hannu Krosing:
> Ühel kenal päeval, K, 2007-07-11 kell 19:08, kirjutas Greg Smith:
> > On Wed, 11 Jul 2007, Narasimha Rao P.A wrote:
> >
> > > Does postgreSQL support distributive query processing
> >
> > Not internally. It's possible in some
Ühel kenal päeval, K, 2007-07-11 kell 19:08, kirjutas Greg Smith:
> On Wed, 11 Jul 2007, Narasimha Rao P.A wrote:
>
> > Does postgreSQL support distributive query processing
>
> Not internally. It's possible in some situations to split queries up
> across multiple nodes using add-on software.
On Wed, 2007-07-11 at 16:49 -0700, Joe Conway wrote:
> On cvs head, I can get "tuple concurrently updated" if two separate
> transactions are both trying to drop the same index:
>ERROR: tuple concurrently updated
> The reason I ask is that someone contacted me who is seeing this on a
> pro
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Seems like we could be slightly more friendly without too much bother:
>
> Actually, rather than get into that sort of AI-complete project,
Is it really AI-complete? ISTM the *only* place where a parameter is al
On Wed, 2007-07-11 at 18:09 -0400, Tom Lane wrote:
> > There seems like a number of ways that unresolved prepared transactions
> > can cause problems. We really need to have startup mention how many
> > prepared transactions there are, so we have some chance of understanding
> > and resolving pote
On Wed, 2007-07-11 at 18:13 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Seems like we could be slightly more friendly without too much bother:
> > at least only substitute after the VALUES clause in INSERT.
>
> Surely you jest.
No. There are a places where parameters cl
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> My local manpage for strftime says that we can get around this warning
>> by overloading it with something like
>
>> size_t
>> my_strftime(char *s, size_t max, const char *fmt,
>> const struct tm *tm)
>> {
>> return strf
66 matches
Mail list logo
