Re: vacuum analyze corrupts database

From: Michael Brusser <michael(at)synchronicity(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuum analyze corrupts database
Date: 2003-05-24 01:33:35
Message-ID: DEEIJKLFNJGBEMBLBAHCGEHMDDAA.michael@synchronicity.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Not as easily as all that --- your example works fine for me, under
> 7.2.4, 7.3.3, or CVS tip. I speculate that there may be some necessary
> factor in build options or runtime environment. How exactly did you
> configure Postgres, what compiler did you use, are you using a non-C
> locale or non-default multibyte encoding, etc?
>
> It would help to know where the crash is occurring; could you get a
> debugger backtrace please?
>
> regards, tom lane

This is a good news. What you said here made me do something
I should've done already - I loaded this table into another
instance of the database and I could not reproduce the problem!
I try to analyze situation, I think this is what it looks like.
Two databases were built few days apart with no changes to the code,
make files, build options, etc.
vacuum analyze on the same table very consistently creates problem
on one db, and works fine on another.
I use the same instance of postmaster against each db, I guess
whatever makes difference must be somewhere under $PGDATA directory.
The database that has the problem underwent some testing. Some data
was created and deleted while QA guys tested our application.
Test was manual, this makes it difficult to exactly reproduce the case.
I've attached the config options we use and database log.
If you're willing to look farther I could tar/zip the db as well.
but let me know if there's something else I could try first.

What I did this time was
select count (*) from nla where note_url LIKE 'sync:///FUNCTREE%' ;
vacuum analyze nla;
\encoding
select count (*) from nla where note_url LIKE 'sync:///FUNCTREE%' ;

I alo tried to drop and recreate database - same result.

Thank you.
Mike.

------------------------------------------------------
tomkins% pg_config --configure
'--srcdir=/home/synch/build/relipg21/src/vendor/postgresql/732'
'--prefix=/home/synch/build/relipg21/obj/SunOS_58_CC_60/postgresql-732/insta
ll'
'--enable-locale'
'--enable-multibyte=UNICODE'
'--with-tcl'
'--without-tk'
'--with-tclconfig=/home/synch/build/relipg21/sbin/SunOS_58_CC_60'
'--with-tkconfig=/home/synch/build/relipg21/sbin/SunOS_58_CC_60'
'--with-includes=/home/synch/build/relipg21/obj/SunOS_58_CC_60/postgresql-73
2/../tcl/include

/home/synch/build/relipg21/obj/SunOS_58_CC_60/postgresql-732/../tk/include'
'--with-libraries=/home/synch/build/relipg21/sbin/SunOS_58_CC_60'
'--without-readline'
'--without-zlib'
'--bindir=/home/synch/build/relipg21/sbin/SunOS_58_CC_60'
'--libdir=/home/synch/build/relipg21/sbin/SunOS_58_CC_60'
'CC=gcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
------------------------------------------------------
tomkins% uname -a
SunOS tomkins 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-80
tomkins% locale
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
------------------------------------------------------

Attachment Content-Type Size
pg.log application/octet-stream 18.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-05-24 01:33:52 Re: Plan B for log rotation support: borrow Apache code
Previous Message Bruce Momjian 2003-05-24 01:30:02 Re: Plan B for log rotation support: borrow Apache code