Re: Odd system-column handling in postgres_fdw join pushdown patch - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Odd system-column handling in postgres_fdw join pushdown patch
Date
Msg-id 20160410060925.GA1752440@tornado.leadboat.com
Whole thread Raw
In response to Re: Odd system-column handling in postgres_fdw join pushdown patch  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Wed, Apr 06, 2016 at 01:14:34AM -0400, Noah Misch wrote:
> On Tue, Apr 05, 2016 at 03:41:00PM +0900, Etsuro Fujita wrote:
> > On 2016/03/29 15:37, Etsuro Fujita wrote:
> > >I added two helper functions: GetFdwScanTupleExtraData and
> > >FillFdwScanTupleSysAttrs.  The FDW author could use the former to get
> > >info about system attributes other than ctids and oids in fdw_scan_tlist
> > >during BeginForeignScan, and the latter to set values for these system
> > >attributes during IterateForeignScan (InvalidTransactionId for
> > >xmins/xmaxs, InvalidCommandId for cmins/cmaxs, and valid values for
> > >tableoids).  Attached is a proposed patch for that.  I also slightly
> > >simplified the changes to make_tuple_from_result_row and
> > >conversion_error_callback made by the postgres_fdw join pushdown patch.
> > >  What do you think about that?
> > 
> > I revised comments a little bit.  Attached is an updated version of the
> > patch.  I think this issue should be fixed in advance of the PostgreSQL
> > 9.6beta1 release.
> 
> Of the foreign table columns affected here, I bet only tableoid sees
> non-negligible use.  Even tableoid is not very prominent, so I would not have
> thought of this as a beta1 blocker.  What about this bug makes pre-beta1
> resolution especially valuable?

This will probably get resolved earlier if it enters the process now as a non
beta blocker, compared to entering the process later as a beta blocker.  I'm
taking the liberty of doing that:

[This is a generic notification.]

The above-described topic is currently a PostgreSQL 9.6 open item.  Robert,
since you committed the patch believed to have created it, you own this open
item.  If that responsibility lies elsewhere, please let us know whose
responsibility it is to fix this.  Since new open items may be discovered at
any time and I want to plan to have them all fixed well in advance of the ship
date, I will appreciate your efforts toward speedy resolution.  Please
present, within 72 hours, a plan to fix the defect within seven days of this
message.  Thanks.



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [COMMITTERS] pgsql: Bloom index contrib module
Next
From: Pavel Stehule
Date:
Subject: Re: Relax requirement for INTO with SELECT in pl/pgsql