From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: unknown error message |
Date: | 2006-07-24 18:54:26 |
Message-ID: | 13081.1153767266@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Markus Schiltknecht <markus(at)bluegap(dot)ch> writes:
> in the mean time I've traced the problem down to a 'CONSTRAINT' declared
> as 'DEFERRABLE INITIALLY DEFERED'. As soon as I remove that constraint
> the transaction commits nicely. BTW: I'm running in ISOLATION LEVEL
> SERIALIZABLE, if that matters.
The deferred constraint is probably the victim here (ie, it's
responsible for there being a trigger to fire). The question is where
did its tuple go?
> Has something changed so that it's worth trying current CVS? I'll try to
> come up with a test case, the problem is not easy to isolate, though.
Right offhand the only way that I could see for the tuple to disappear
before the trigger fires is if a concurrent VACUUM removed it, which
should not happen for a tuple inserted by a still-active transaction.
If you've got autovacuum running in the background, the unpredictability
of vacuum timing might be contributing to difficulty of reproducing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Emi Lu | 2006-07-24 18:57:54 | gmake Errors: pg_backup_archiver.c: undefined reference to `lo_create' |
Previous Message | Markus Schiltknecht | 2006-07-24 17:49:03 | Re: unknown error message |