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-07 16:56:05 |
Message-ID: | 2232788.1602089765@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> This all sounds like a reasonable approach to me. I've gone back and
> looked through things a bit and agree that processExtensionTables really
> should be setting interesting to true for extension config tables when
> we decide we want to include them. Your 0003 patch looks correct to me,
> and it does seem like we need to go all the way back with that.
Pushed now, thanks for looking it over.
I ended up dropping 0001 (the ncheck refactoring). That's not really
relevant to the bug fix, and it occurred to me that dumping core if
the checkexprs data isn't there isn't such a bad thing. 0001 would
have led us to silently act as though the table has no CHECK constraints,
contrary to reality, if we reached one of those loops without having
loaded the requisite data. Crashing is better --- think of it as a
free Assert ;-).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-10-07 17:06:34 | Re: BUG #16659: postgresql leaks memory or do not limit its usage |
Previous Message | PG Bug reporting form | 2020-10-07 16:08:35 | BUG #16660: 64-bit build fails when run on a subst drive |