Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4
От | Tom Lane |
---|---|
Тема | Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4 |
Дата | |
Msg-id | 9603.1412173321@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4 (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-bugs |
Michael Paquier <michael.paquier@gmail.com> writes: > This approach is far more solid than my previous stuff and makes the > approach I took really brittle... Hey, the idea to add a field was mine, so don't beat yourself up about it :-). Sometimes it takes working out an idea to realize it's bad. > Looking at your code, I am wondering if > it would not be safer to add some assertions in find_childrel_top_parent > and find_childrel_parents, something like a check on RELOPT_BASEREL for > rel->reloptkind before returning a result. Er, those new functions should > always finishing by scanning a base rel, right? Yeah, not a bad idea. > Btw, this code will need minor adjustments for REL9_2_STABLE and > REL9_3_STABLE. Is a backpatch down to 9.1 to be considered? The bugs we're working on here are definitely demonstrable back to 9.2. I'm not sure about 9.1 yet; but considering that a87c72915 had to get back-patched as far as 9.1, there may well be some manifestations of these problems visible in 9.1. (The new regression test that I wrote doesn't seem to show any big problems there, but maybe I'm just short a case or two.) regards, tom lane
В списке pgsql-bugs по дате отправления: