Re: [HACKERS] md.c is feeling much better now, thank you
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] md.c is feeling much better now, thank you |
Дата | |
Msg-id | 5805.936545607@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] md.c is feeling much better now, thank you (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] md.c is feeling much better now, thank you
Re: [HACKERS] md.c is feeling much better now, thank you |
Список | pgsql-hackers |
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... > 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
В списке pgsql-hackers по дате отправления: