On Thu, Mar 23, 2017 at 8:54 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/03/23 23:47, Amit Langote wrote: >> On Thu, Mar 23, 2017 at 11:27 PM, Maksim Milyutin >> <m.milyu...@postgrespro.ru> wrote: >>> Hi! >>> >>> I have noticed that there is scheduled unlinking of nonexistent physical >>> storage under partitioned table when we execute DROP TABLE statement on this >>> partitioned table. Though this action doesn't generate any error under >>> typical behavior of postgres because the error of storage's lack is caught >>> through if-statement [1] I think it is not safe. >>> >>> My patch fixes this issue. >>> >>> 1. src/backend/storage/smgr/md.c:1385 >> >> Good catch, will incorporate that in the main patch. > > And here is the updated patch.
I think you should go back to the earlier strategy of disallowing heap reloptions to be set on the partitioned table. The thing is, we don't really know which way we're going to want to go in the future. Maybe we'll come up with a system where you can set options on the partitioned table, and those options will cascade to the children. Or maybe we'll come up with a system where partitioned tables have a completely different set of options to control behaviors specific to partitioned tables. If we do the latter, then we don't want to also have to support useless heap reloptions for forward compatibility, nor do we want to break backward-compatibility to remove support. If we do the former, then it's better if we allow it in the same release where it starts working. -- 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
