From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Laurette Cisneros <laurette(at)nextbus(dot)com> |
Subject: | Re: index corruption? |
Date: | 2003-03-31 23:15:43 |
Message-ID: | 200303311615.43695.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday March 31 2003 3:54, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> >> I am seeing this same problem on two separate machines, one brand new,
> >> one older. Not sure yet what is causing it, but seems pretty unlikely
> >> that it is hardware-related.
> >
> > I am dabbling for the first time with a (crashing) C trigger, so that
> > may be the culprit here.
>
> Could well be, although past experience has been that crashes in C code
> seldom lead directly to disk corruption. (First, the bogus code has to
> overwrite a shared disk buffer. If you follow what I consider the
> better path of not making your shared buffers a large fraction of the
> address space, the odds of a wild store happening to hit a disk buffer
> aren't high. Second, once it's corrupted a shared buffer, it has to
> contrive to cause that buffer to get written out before the core dump
> occurs --- in most cases, the fact that the postmaster abandons the
> contents of shared memory after a backend crash protects us from this
> kind of failure.)
>
> When you find the problem, please take note of whether there's something
> involved that increases the chances of corruption getting to disk. We
> might want to try to do something about it ...
It is definitely due to some rogue trigger code. Not sure what exactly, but
if I remove a certain code segment the problem disappears.
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2003-03-31 23:36:01 | Re: index corruption? |
Previous Message | Tom Lane | 2003-03-31 23:04:47 | Re: optimizer cost calculation problem |