On Wed, Oct 18, 2017 at 11:27 AM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
> Maybe there are combinations of different persistence values that can be
> allowed to differ (an unlogged partition is probably OK with a permanent
> parent), but I don't think the current check is good enough.
This is also a sort of long-standing historical problem, I think.
This comment in expand_inherited_rtentry has been with us for a while:
/* * It is possible that the parent table has children that are temp * tables of other backends.
Wecannot safely access such tables * (because of buffering issues), and the best thing to do seems to be
*to silently ignore them. */
I do not find that to be a particularly sensible approach, and it's
probably even less sensible in the partitioning world than it was with
table inheritance. I think what we ought to do is prohibit it, but it
wasn't the job of the table partitioning commit to whack this around.
This is not the first example of a case where we've failed to put in
place sufficiently-strong checks to prohibit references to temp tables
in places where they don't make sense. See e.g.
16925c1e1fa236e4d7d6c8b571890e7c777f75d7,
948d6ec90fd35d6e1a59d0b1af8d6efd8442f0ad,
0688d84041f7963a2a00468c53aec7bb6051ef5c,
a13b01853084b6c6f9c34944bc19b3dd7dc4ceb2,
5fa3418304b06967fa54052b183bf96e1193d85e,
7d6e6e2e9732adfb6a93711ca6a6e42ba039fbdb,
82eed4dba254b8fda71d429b29d222ffb4e93fca. We really did not do a good
job plugging all of the cases where temp tables ought to be forbidden
when that feature went in, and IMHO this is more of the tail end of
that work than anything specific to partitioning. Your opinion may
differ, of course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
