From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeremy Drake <pgsql(at)jdrake(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Test tool for sinval reset situations |
Date: | 2006-01-07 22:03:23 |
Message-ID: | 12913.1136671403@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here is a quick-and-dirty function for forcing sinval reset (ie, catalog
cache flush). I've already found one bug in CVS tip with it :-(, and
I have a feeling there may be a lot more.
Basic usage is: compile the program into a .so file, then in a spare
database do something like
create function sinval_reset() returns void as '/path/to/.so' language c;
create function many_reset(int) returns void as '
begin
for i in 1 .. $1 loop
perform sinval_reset();
end loop;
return;
end' language plpgsql;
Now you can leave a process doing
select many_reset(some-large-number);
while you exercise any test you care to in other databases of the same
installation. Ideally you will see no effects other than slowdowns
(possibly severe slowdowns, depending on what you're doing).
In reality, I've already seen a core dump in btree index build while
running the regression tests.
Please try this and see if it makes your duplicate-key problem easier
to provoke.
(BTW, while I've only tried it with CVS tip, I think the function is
source-code-compatible with everything as far back as PG 7.3. You'd
probably need to recompile it against each version you want to use it
with though.)
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
sinval_reset.c | application/octet-stream | 949 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-01-07 22:25:05 | Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) |
Previous Message | Tom Lane | 2006-01-07 20:08:37 | Re: catalog corruption bug |