Jack Orenstein <jao@geophile.com> writes: > I am writing a Postgres extension, and thought that I had memory > corruption, (thanks for the --enable-cassert lead). I might, but It now > looks like I need to understand the use of shared memory and locking in > Postgres. So I have two questions.
> 1) I am now guessing that my original problem is caused by relying on > static memory in my extension (i.e., in the source declaring > PG_MODULE_MAGIC). This static memory is almost but not quite constant -- it > is initialized from _PG_init, and then never modified. I suspect that this > cannot work in general (since Postgres is multi-process), but I thought it > would be adequate for early development. However, I am seeing this static > memory get corrupted even when there is only a single process executing the > extension code (verified by examining getpid()).
Define what you mean by "corrupted". It seems highly unlikely that any code but your own is touching this memory.
Some fields have expected values, others do not.
I think I have just figured out this problem, and it was indeed my own gun shooting my own foot.
Really the big-picture question here is what are you hoping to accomplish and why do you think this memory might need to be shared?
The type I am implementing depends on looking up data in an array whose size is approximately 64k. This array needs to be computed once and for all early on, and is then consulted as the type is used. For now, I have hardwired the parameters that determine the array's contents, and the array is constructed during _PG_init. I will eventually remove this scaffolding, and compute the array contents when required, which should be a rare event.
