Re: pg primary key bug?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pginfo <pginfo(at)t1(dot)unisoftbg(dot)com>
Cc: Richard_D_Levine(at)raytheon(dot)com, Michael Glaesemann <grzm(at)myrealbox(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: pg primary key bug?
Date: 2005-02-22 18:04:08
Message-ID: 10956.1109095448@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

pginfo <pginfo(at)t1(dot)unisoftbg(dot)com> writes:
> I will to ask if it will be possible to start some querys (I do not know
> the query) exactly before running vacuum full and to save the results in
> some log file. If it is possible, we will be able to post the results to
> the list in case of ne problem and to have some start point for
> reproducing the problem.

Well, you should definitely turn on log_statement across the whole
installation so that you have a complete record of all SQL commands
being issued. Make sure the log includes timestamps and PIDs.

I would suggest adding a simple probe for duplicate records to the
vacuum script. Maybe something like

set enable_indexscan to off;
select constname,fid,count(*) from a_constants_str
group by constname,fid having count(*) > 1;

(The indexscan off bit is just paranoia --- I think that an indexscan
might mask the presence of multiple copies of what's supposedly a unique
key.) Do this just before and just after the vacuum full command. That
will at least nail down whether vacuum full is creating the dups, and
once we see it happen the trace of the day's SQL commands may give some
ideas where to look.

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Theodore Petrosky 2005-02-22 19:06:04 schemas and paths with the alter statement
Previous Message pginfo 2005-02-22 17:20:00 Re: pg primary key bug?