| 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: | Re: catalog corruption bug |
| Date: | 2006-01-08 19:00:39 |
| Message-ID: | 25909.1136746839@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeremy Drake <pgsql(at)jdrake(dot)com> writes:
> On Sat, 7 Jan 2006, Tom Lane wrote:
>> A bit of a leap in the dark, but: maybe the triggering event for this
>> situation is not a "VACUUM pg_amop" but a global cache reset due to
>> sinval message buffer overrun.
> I tried that function you sent, while running my other code. It died, but
> not the same way. None of my processes had the unique constraint error,
> but two had failed during commit. Both of them died in that same place as
> the last one, on pg_amop.
Yeah, that's not very surprising. Running the forced-cache-resets
function will definitely expose that catcache bug pretty quickly.
You'd need to apply the patches I put in yesterday to have a system
that has any chance of withstanding that treatment for any length of time.
> I think I am going to just run without the function running this time and
> see if it does the duplicate type error and if it will generate two cores.
Please also look at putting together a test case so others can poke at
this.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2006-01-08 19:41:20 | Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) |
| Previous Message | Tom Lane | 2006-01-08 18:44:07 | Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) |