> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > Ok. I will give another example that seems more serious.
> > test=> aaa;
> > ERROR: parser: parse error at or near "aaa"
> > -- transaction is aborted and the table file t1 is unlinked.
> > test=> select * from t1;
> > -- but parser doesn't know t1 does not exist any more.
> > -- it tries to open t1 using mdopen(). (see including backtrace)
> > -- mdopen() tries to open t1 and fails. In this case mdopen()
> > -- creates t1!
> > NOTICE: (transaction aborted): queries ignored until END
> > *ABORT STATE*
>
> Hmm. It seems a more straightforward solution would be to alter
> pg_parse_and_plan so that the parser isn't even called if we have
> already failed the current transaction; that is, the "queries ignored"
> test should occur sooner. I'm rather surprised to realize that
> we do run the parser in this situation...
No. we have to run the parser so that we could accept "end".
> > I think the long range solution would be let parser obtain certain
> > locks as Tom said.
>
> That would not solve this particular problem, since the lock manager
> wouldn't know any better than the parser that the table doesn't really
> exist any more.
I see.
> > Until that I propose following solution. It looks
> > simple, safe and would be neccessary anyway (I don't know why that
> > check had not been implemented). See included patches.
>
> This looks like it might be a good change, but I'm not quite as sure
> as you are that it won't have any bad effects. Have you tested it?
At least initdb and the regression test runs fine for me...
---
Tatsuo Ishii