From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, "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-06 00:51:43 |
Message-ID: | 199909060051.JAA10470@ext16.sra.co.jp |
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...
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
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-09-06 01:09:47 | Re: [HACKERS] DROP TABLE inside transaction block |
Previous Message | Michael Simms | 1999-09-05 23:11:36 | Re: [HACKERS] DROP TABLE inside transaction block |