| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | cam(dot)daniel(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16655: pg_dump segfault when excluding postgis table |
| Date: | 2020-10-06 21:26:04 |
| Message-ID: | 2007400.1602019564@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-10-06 22:22:18 | BUG #16657: Index not reflecting update when date to timestamp comparison operation used in index scan |
| Previous Message | Tom Lane | 2020-10-06 19:06:58 | Re: BUG #16655: pg_dump segfault when excluding postgis table |