Re: BUG #4913: Row missing from primary key index

Mathieu De Zutter <mathieu(at)dezutter(dot)org> writes:
> On Fri, Jul 10, 2009 at 2:02 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com>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, $5, NOW())

> So the timestamp is generated by NOW(), and the pkey is generated by using
> the default value (nextval).

The timestamps are invariably generated by NOW()? That seems impossible
given that Andrew's report shows different timestamps for the same
insert XID. But actually, you have to believe about six impossible
things in order to credit that Andrew's report represents the behavior
of a normally-functioning Postgres system.

What I am thinking is that we are looking at the results of multiple
disconnected backends hacking on the same database files --- ie, there's
more than one active shared memory block. That would explain the
apparent re-use of XIDs (they're being handed out separately in each
shmem block) as well as disappearance of index entries (a write from
either shmem block would wipe out recent changes in that page from the
other one). This could be checked by looking at the output of "ipcs -m"
(run this as root to be sure you get everything).

regards, tom lane