On Thu, Sep 24, 2020 at 4:25 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Wed, Sep 23, 2020 at 10:12 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Sun, Sep 20, 2020 at 11:41 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > > On Mon, Sep 14, 2020 at 10:45 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > > > Although, I am still not sure how to
> > > > "copy" system columns from one partition's slot to another's, that is,
> > > > without assuming what they are.
> > >
> > > I just thought we assume that partitions support all the existing
> > > system attributes until we have the fix for (a), i.e., the slot
> > > assigned for a partition must have the getsysattr callback routine
> > > from which we can fetch each existing system attribute of a underlying
> > > tuple in the slot, regardless of whether that system attribute is used
> > > for the partition or not.
> >
> > Hmm, to copy one slot's system attributes into another, we will also
> > need a way to "set" the system attributes in the destination slot.
> > But maybe I didn't fully understand what you said.
>
> Sorry, my thought was vague. To store xmin/xmax/cmin/cmax into a
> given slot, we need to extend the TupleTableSlot struct to contain
> these attributes as well? Or we need to introduce a new callback
> routine for that (say, setsysattr)? These would not be
> back-patchable, though.
Yeah, I'd think so too.
BTW, the discussion so far on the other thread is oblivious to the
issue being discussed here, where we need to find a way to transfer
system attributes between a pair of partitions that are possibly
incompatible with each other in terms of what set of system attributes
they support. Although, if we prevent accessing system attributes
when performing the operation on partitioned tables, like what you
seem to propose below, then we wouldn't really have that problem.
> > BTW, do you think we should alter the test in PG 11 branch to test
> > that system attributes are returned correctly?
>
> Yeah, I think so. I didn’t come up with any good test cases for that, though.
>
> > Once we settle the
> > other issue, we can adjust the HEAD's test to do likewise?
>
> Yeah, but for the other issue, I started thinking that we should just
> forbid referencing xmin/xmax/cmin/cmax in 12, 13, and HEAD...
When the command is being performed on a partitioned table you mean?
That is, it'd be okay to reference them when the command is being
performed directly on a leaf partition, although it's another thing
whether the leaf partitions themselves have sensible values to provide
for them.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com