Re: server crash in very big transaction [postgresql 8.0beta1]

On Tue, Aug 24, 2004 at 06:10:40PM -0400, Tom Lane wrote:

> WARNING: out of shared memory
> ERROR: out of shared memory
> HINT: You may need to increase max_locks_per_transaction.
> WARNING: StartAbortedSubTransaction while in START state
> ERROR: current transaction is aborted, commands ignored until end of transaction block
> ERROR: current transaction is aborted, commands ignored until end of transaction block
> ... etc ...
>
> which is fine except for the StartAbortedSubTransaction warning; that
> may indicate a problem. (What do you think about it, Alvaro?)

I think the problem here is that we can't "safely" call
StartAbortedSubTransaction when in TRANS_START state. This is because
we could have some subsystems already initialized, and we will be
initializing them again. For example, AtSubStart_Memory() will be
called twice, which will lead to the loss of an (empty) memory context.
It doesn't seem a big problem, only a memory leak.

(We also lose a ResourceOwner, but since it doesn't own anything yet, it
isn't a problem.)

Fortunately I think we are good regarding other subsystems --- for
example if we happened to do something with sinval.c list-of-lists, it
could get out of sync with the transaction stack and it could get ugly.
But we don't.

I don't think we should get rid of the warning. It shows that there's a
problem, but it's not critical. We could set a flag indicating that
memory and resource owner are already initialized (another TRANS state?
a static bool?), but I don't know if it's worth the trouble.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"The West won the world not by the superiority of its ideas or values
or religion but rather by its superiority in applying organized violence.
Westerners often forget this fact, non-Westerners never do."
(Samuel P. Huntington)