Re: Questionable coding in proc.c & lock.c

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> Oops,I've forgotten another freezing issue reported by Alfred Perlstein.
> We know the cause(db access in abort transaction state) of it.
> Seems xact.c has been pretty changed after I examined it 2 months
> ago. Have you already fixed it ?

That example seems to work better than before, but the generic problem
is still there: we should avoid running the planner analysis phase and
the rewriter when we are in abort state.

We also need to do something about holding locks on relations clear
through from parsing till execution. It occurs to me that there is
a problem closely related to the abort problem here: what if there
are transaction boundaries in the query string? Suppose the query
string is

begin; select * from foo; end; select * from bar;

Currently, even if the parser did grab a lock on bar, it'd get dropped
during execution of the "end".

I think maybe what needs to be done to fix all this is to restructure
postgres.c's interface to the parser/rewriter. What we want is to
run just the yacc grammar initially to produce a list of raw parse
trees (which is enough to detect begin/commit/rollback, no?) Then
postgres.c walks down that list, and for each element, if it is
commit/rollback OR we are not in abort state, do parse analysis,
rewrite, planning, and execution. (Thomas, any comments here?)

regards, tom lane