Re: [HACKERS] md.c is feeling much better now, thank you

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] md.c is feeling much better now, thank you
Date: 1999-09-05 15:33:27
Message-ID: 5805.936545607@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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...

> 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.

> 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?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-09-05 22:17:55 DROP TABLE inside transaction block
Previous Message Damond Walker 1999-09-05 15:10:12 RH6.0/Sparc and PG 6.5.1