Re: Assertion failure with LEFT JOINs among >500 relations
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Onder Kalaci <onderk@microsoft.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-10-18T23:37:49Z
Lists: 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
Commits
-
Relax some asserts in merge join costing code
- 33a332bc1cff 13.1 landed
- 77ca44b76477 12.5 landed
- 2681bb230a68 11.10 landed
- 600c2412f850 10.15 landed
- 00fecc24c140 9.6.20 landed
- 3798b4fe73b9 9.5.24 landed
-
Prevent overly large and NaN row estimates in relations
- a90c950fc7fd 14.0 landed
-
Avoid a couple of zero-divide scenarios in the planner.
- 76281aa9647e 9.6.0 cited
-
Guard against incoming rowcount estimate of NaN in cost_mergejoin().
- 72826fb362c4 9.1.0 cited
-
When a relation has been proven empty by constraint exclusion, propagate that
- fd791e7b5a1b 8.4.0 cited