Re: index corruption?
От | Ed L. |
---|---|
Тема | Re: index corruption? |
Дата | |
Msg-id | 200303311806.35326.pgsql@bluepolka.net обсуждение исходный текст |
Ответ на | Re: index corruption? ("Ed L." <pgsql@bluepolka.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: