Re: Assertion failure with LEFT JOINs among >500 relations
От | David Rowley |
---|---|
Тема | Re: Assertion failure with LEFT JOINs among >500 relations |
Дата | |
Msg-id | CAApHDvps=BBWjDV89g8BnCe0XujuT1Mz2_UtMiFUZPXrEyUmsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure with LEFT JOINs among >500 relations (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Assertion failure with LEFT JOINs among >500 relations
|
Список | pgsql-hackers |
On Mon, 19 Oct 2020 at 12:25, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.com> writes: > > On Mon, 19 Oct 2020 at 12:10, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> TBH, I see no need to do anything in the back branches. This is not > >> an issue for production usage. > > > I understand the Assert failure is pretty harmless, so non-assert > > builds shouldn't suffer too greatly. I just assumed that any large > > stakeholders invested in upgrading to a newer version of PostgreSQL > > may like to run various tests with their application against an assert > > enabled version of PostgreSQL perhaps to gain some confidence in the > > upgrade. A failing assert is unlikely to inspire additional > > confidence. > > If any existing outside regression tests hit such corner cases, then > (a) we'd have heard about it, and (b) likely they'd fail in the older > branch as well. So I don't buy the argument that this will dissuade > somebody from upgrading. hmm, well it was reported to us. Perhaps swapping the word "upgrading" for "migrating". It would be good to hear Onder's case to see if he has a good argument for having a vested interest in pg13 not failing this way with assets enabled. > I do, on the other hand, buy the idea that if anyone is indeed working > in this realm, they might be annoyed by a behavior change in a stable > branch. So it cuts both ways. On balance I don't think we should > touch this in the back branches. I guess we could resolve that concern by just changing the failing assert to become: Assert(outer_skip_rows <= outer_rows || isinf(outer_rows)); It's pretty grotty but should address that concern. David
В списке pgsql-hackers по дате отправления: