On Mon, Dec 26, 2016 at 5:46 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2016/12/23 8:08, Robert Haas wrote: >> On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote >> <langote_amit...@lab.ntt.co.jp> wrote: >>> While working on that, I discovered yet-another-bug having to do with the >>> tuple descriptor that's used as we route a tuple down a partition tree. If >>> attnums of given key attribute(s) are different on different levels, it >>> would be incorrect to use the original slot's (one passed by ExecInsert()) >>> tuple descriptor to inspect the original slot's heap tuple, as we go down >>> the tree. It might cause spurious "partition not found" at some level due >>> to looking at incorrect field in the input tuple because of using the >>> wrong tuple descriptor (root table's attnums not always same as other >>> partitioned tables in the tree). Patch 0001 fixes that including a test. >> >> I committed this, but I'm a bit uncomfortable with it: should the >> TupleTableSlot be part of the ModifyTableState rather than the EState? > > Done that way in 0001 of the attached patches. So, instead of making the > standalone partition_tuple_slot a field of EState (with the actual > TupleTableSlot in its tupleTable), it is now allocated within > ModifyTableState and CopyState, and released when ModifyTable node or > CopyFrom finishes, respectively.
I dropped some comments from this and committed it. They were formatted in a way that wouldn't survive pgindent. -- 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