Re: vacuum analyze corrupts database

> Hmm. Are you running the database in a non-C locale?
> (pg_controldata would tell you.)
-----------

Here's the output of pg_controldata:

pg_control version number: 72
Catalog version number: 200211021
Database cluster state: in production
pg_control last modified: Sun May 25 18:38:06 2003
Current log file ID: 0
Next log file segment: 2
Latest checkpoint location: 0/15EF7A8
Prior checkpoint location: 0/15ED2D8
Latest checkpoint's REDO location: 0/15EF7A8
Latest checkpoint's UNDO location: 0/0
Latest checkpoint's StartUpID: 47
Latest checkpoint's NextXID: 3563
Latest checkpoint's NextOID: 118086
Time of latest checkpoint: Sun May 25 18:38:02 2003
Database block size: 8192
Blocks per segment of large relation: 131072
Maximum length of identifiers: 64
Maximum number of function arguments: 32
Date/time type storage: Floating point
Maximum length of locale name: 128
LC_COLLATE: en_US.ISO8859-1
LC_CTYPE: en_US.ISO8859-1
-----------------------------
locale settings on the host:
tomkins% locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
-----------------------------
> I am wondering if strxfrm() on your platform sometimes writes more bytes
> than it is supposed to. I have seen vsnprintf() overrun its output
> buffer on some flavors of Solaris (according to FAQ_Solaris, the 64-bit
> libc in Solaris 7 had such a problem). Could there be a similar bug in
> their strxfrm?

We're on Solaris 8. I'll try to find information on strxfrm bugs,
but do you rule out any problems in Postgres code?
Is there a good explanation to why the same table loaded into another
Postgres
installation on the same host can be analyzed without any problems?
Also in my database I can drop/create database, load table and reproduce the
error.
Not sure what to make out of this.

Mike.

-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Tom Lane
Sent: Sunday, May 25, 2003 9:03 PM
To: michael(at)synchronicity(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] vacuum analyze corrupts database

Michael Brusser <michael(at)synchronicity(dot)com> writes:
> (dbx) where 30
> =>[1] pfree(0x489420, 0xffbee890, 0x489420, 0xffbee880, 0x489628,
> 0xffbee888), at 0x2535e4
> [2] convert_to_scalar(0x489078, 0x19, 0xffbee890, 0x489008, 0x488fc0,
> 0x413), at 0x1fc6b4
> [3] scalarineqsel(0x484608, 0x42a, 0x0, 0x488a88, 0x489078, 0x19), at
> 0x1f94e4

Hmm. Are you running the database in a non-C locale? (pg_controldata
would tell you.) If so, this pfree is trying to pfree one of three
strings that were filled with strxfrm().

I am wondering if strxfrm() on your platform sometimes writes more bytes
than it is supposed to. I have seen vsnprintf() overrun its output
buffer on some flavors of Solaris (according to FAQ_Solaris, the 64-bit
libc in Solaris 7 had such a problem). Could there be a similar bug in
their strxfrm?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
message can get through to the mailing list cleanly