Re: BUG #16655: pg_dump segfault when excluding postgis table
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: cam.daniel@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2020-10-06T21:26:04Z
Lists: pgsql-bugs
I wrote: > 0001 is sufficient to get past the proposed test case in 0002. However, > I think processExtensionTables is also buggy here. It does need to set > the "interesting" flag to true if it decides we need to dump the table's > data, because we have to have the per-attribute data to support that, > and "interesting" might not ever get set true on the table otherwise. > But *it is not OK to set "interesting" to false just because we don't > decide to dump the data*. If it's been set true for some other reason, > that other reason didn't just vanish. So I think we also need 0003. Upon excavating in the git history, I discovered that that error was introduced in 3eb3d3e78 [1], which explains why the OP thought it was new in v13 --- no other branch has shipped the buggy code yet. It's not entirely clear to me why we don't get a crash on the case in pre-v12 branches, but I'm inclined to apply these patches all the way back anyway, as they definitely seem like robustness improvements whether or not a given branch accidentally fails to fail. regards, tom lane [1] https://www.postgresql.org/message-id/flat/18048b44-3414-b983-8c7c-9165b177900d%402ndQuadrant.com
Commits
-
Rethink recent fix for pg_dump's handling of extension config tables.
- 710c0a66d6e9 9.6.20 landed
- 0bfe356c5594 9.5.24 landed
- f2c6e94f0790 11.10 landed
- 0c79dcb36c52 10.15 landed
- d8c2a2199867 12.5 landed
- 2ea624b4b51c 13.1 landed
- 9e5f1f21ad6a 14.0 landed