From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: unknown error message |
Date: | 2006-07-24 19:11:25 |
Message-ID: | 1153768285.5370.11.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2006-07-24 at 14:54 -0400, Tom Lane wrote:
> 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.
Sorry, I was unclear: luckily the error is easily reproducible. The
problem is just to cut unnecessary parts and to come up with a small
test case. I'll give it a try tomorrow.
As far as VACUUM is concerned: I run this data-loading script just after
CREATE DATABASE. In my tests, not more than some 100 rows (rough guess)
are inserted until the error occurs. It would surprise me if that would
have fired an autovacuum every time I tried. Plus as you say, it all
happens in the same transaction.
(Oh, and I even tried with a sleep(5) before the commit and the error
still occurred. I guess an autovacuum most probably won't take that long
with so few rows.)
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Emi Lu | 2006-07-24 19:13:53 | gmake Errors: pg_backup_archiver.c: undefined reference to `lo_create' |
Previous Message | Emi Lu | 2006-07-24 18:57:54 | gmake Errors: pg_backup_archiver.c: undefined reference to `lo_create' |