On Monday March 31 2003 4:15, Ed L. wrote:
> On Monday March 31 2003 3:54, Tom Lane wrote:
> > "Ed L." <pgsql@bluepolka.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 ...
Well, I fixed it but cannot now remember exactly what change did it amidst a
bunch of rewrites of some existing stuff, and I cannot get back to that
state from here. :( It was definitely arising from some funky C trigger
code of my own making.
Ed
