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@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
Sent: Sunday, May 25, 2003 9:03 PM
To: michael@synchronicity.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] vacuum analyze corrupts database


Michael Brusser <michael@synchronicity.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@postgresql.org so that your
message can get through to the mailing list cleanly