Test tool for sinval reset situations

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

Browse pgsql-hackers by date

  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