On Fri, Jul 10, 2009 at 6:24 PM, Tom Lane wrote:
> As far as anyone knows, it's impossible to get into the
> disconnected-backends state unless (a) you manually remove the
> postmaster.pid file that provides the interlock against it, or
> (b) you're trying to run multiple copies of Postgres on di
Mathieu De Zutter writes:
> $ sudo ipcs -m
> -- Shared Memory Segments
> keyshmid owner perms bytes nattch status
> 0x0052e2c1 1081344postgres 60030384128 21
> 0x 425985 postgres 60018440 34
> 0x 458754
On Fri, Jul 10, 2009 at 5:03 PM, Tom Lane wrote:
> This could be checked by looking at the output of "ipcs -m"
> (run this as root to be sure you get everything).
>
$ sudo ipcs -m
-- Shared Memory Segments
keyshmid owner perms bytes nattch statu
Mathieu De Zutter writes:
> On Fri, Jul 10, 2009 at 2:02 AM, Alvaro Herrera
> wrote:
>> What do the INSERT lines look like?
> * This is the INSERT query, called from PHP/Apache
> INSERT INTO log_event (user_id, ip, action_id, object1_id, object2_id,
> event_timestamp)
> VALUES ($1, $2, $3, $4, $
On Fri, Jul 10, 2009 at 2:02 AM, Alvaro Herrera
wrote:
> What do the INSERT lines look like? Is it a trigger, an insert called
> directly by the application? How is the sequence involved -- lastval(),
> nextval(), does the code just leave the column out for the default to fire?
>
>
* This is th
> "Tom" == Tom Lane writes:
>> The system was recently dump/restored from a different box. The
>> failing rows are all new inserts since the restore.
Tom> So the table has been insert-only so far? I was just thinking
Tom> that HOT bugs seemed like a probable explanation, but that idea
Mathieu De Zutter wrote:
> I have a table log_event with a primary key on an integer 'id', called
> log_event_pkey.
>
> The tables contains a duplicate for id = 15723018. The duplicate (note that
> besides the id, all data differs) doesn't seem to be known by the index at
> all.
What do the INSE
Andrew Gierth writes:
> Tom> One thing that seems odd is that the xids are kinda small. Did
> Tom> the system just recently have a wraparound event?
> The system was recently dump/restored from a different box. The
> failing rows are all new inserts since the restore.
So the table has been in
> "Tom" == Tom Lane writes:
>> Notice that the two rows seem entirely independent (different
>> xmin). The OP stated that his app generally does single-row
>> inserts (with some exceptions not relevent here); however, we
>> found a nearby row which shares the xmin:
Tom> How is the time
Andrew Gierth wrote:
> > "Mathieu" == "Mathieu De Zutter" writes:
>
> Mathieu> I have a table log_event with a primary key on an integer
> Mathieu> 'id', called log_event_pkey.
>
> Mathieu> The tables contains a duplicate for id = 15723018. The
> Mathieu> duplicate (note that besides the
Andrew Gierth writes:
> This was first reported on IRC and I spent a little time working with
> the OP trying to dig up info to suggest a cause; here is the relevent
> data (all provided by the OP at my request). I have not been able to
> suggest a possible cause based on this.
> shs=# select cti
> "Mathieu" == "Mathieu De Zutter" writes:
Mathieu> I have a table log_event with a primary key on an integer
Mathieu> 'id', called log_event_pkey.
Mathieu> The tables contains a duplicate for id = 15723018. The
Mathieu> duplicate (note that besides the id, all data differs)
Mathieu> do
The following bug has been logged online:
Bug reference: 4913
Logged by: Mathieu De Zutter
Email address: math...@dezutter.org
PostgreSQL version: 8.3.7
Operating system: Debian Lenny
Description:Row missing from primary key index
Details:
I have a table log_event w
13 matches
Mail list logo
