> Von: Tom Lane [mailto:...]
> Gesendet: Freitag, 20. April 2007 18:14
> An: Dorochevsky,Michel
> Cc: pgsql-bugs@postgresql.org
> Betreff: Re: AW: [BUGS] BUG #3245: PANIC: failed to re-find shared lock
object
>
> "Dorochevsky,Michel"
writes:
> > Two runs of the same test program fail at differen
Question: do you have any leftover files in $PGDATA/pg_twophase ?
I'm wondering why the log contains no warning messages about stale
two-phase state files. It looks to me like the system should have
found the two-phase file still there upon restart, but the transaction
should have been marked alr
> Question: do you have any leftover files in $PGDATA/pg_twophase ?
>
> I'm wondering why the log contains no warning messages about stale
> two-phase state files. It looks to me like the system should have
> found the two-phase file still there upon restart, but the transaction
> should have been
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
No, it's definitly the right primitive. But we're creating it with a max
count of 1.
That's definitely wrong. There are at least three reasons for a PG
process's semaphore to be signaled (heavywe
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> The failing transaction is visible in the database after restart, I have
> checked three of the last inserts, e.g.
Good, at least we're not losing data ;-). But I expected that because
this PANIC must be occurring after the RecordTransactionCommi
