Обсуждение: buildfarm failures on crake and sittella
Andrew, The FileTextArrayFDW-build failure on crake, and the RedisFDW-build failure on sittella, are expected results of my commit 5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push quals down, they just need to be updated to pass an additional NIL argument to make_foreignscan(). If they do, they need to pass a list of the pushed-down quals in that new argument, as described in the above-mentioned commit. Can you either update those FDWs or disable those builds for now so the BF is happy? Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10/16/2015 11:13 AM, Robert Haas wrote: > Andrew, > > The FileTextArrayFDW-build failure on crake, and the RedisFDW-build > failure on sittella, are expected results of my commit > 5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push > quals down, they just need to be updated to pass an additional NIL > argument to make_foreignscan(). If they do, they need to pass a list > of the pushed-down quals in that new argument, as described in the > above-mentioned commit. > > Can you either update those FDWs or disable those builds for now so > the BF is happy? I expect to get to it tomorrow. cheers andrew
On 10/16/2015 02:19 PM, Andrew Dunstan wrote: > > > On 10/16/2015 11:13 AM, Robert Haas wrote: >> Andrew, >> >> The FileTextArrayFDW-build failure on crake, and the RedisFDW-build >> failure on sittella, are expected results of my commit >> 5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push >> quals down, they just need to be updated to pass an additional NIL >> argument to make_foreignscan(). If they do, they need to pass a list >> of the pushed-down quals in that new argument, as described in the >> above-mentioned commit. >> >> Can you either update those FDWs or disable those builds for now so >> the BF is happy? > > > I expect to get to it tomorrow. > > I have done this and everything seems to be working. In the RedisFDW case, it does process certain quals (those in the form "key" = <constant>), but it has been doing the same thing in redisGetForeignPlan as filefdw does in fileGetForeignPlan, so I added the same fix i.e. passing back NIL as the extra parameter. I hope that's correct. If not, maybe we've been doing things a bit wrong for a while :-) cheers andrew
On Sat, Oct 17, 2015 at 12:26 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > I have done this and everything seems to be working. In the RedisFDW case, > it does process certain quals (those in the form "key" = <constant>), but it > has been doing the same thing in redisGetForeignPlan as filefdw does in > fileGetForeignPlan, so I added the same fix i.e. passing back NIL as the > extra parameter. I hope that's correct. If not, maybe we've been doing > things a bit wrong for a while :-) Thanks for getting to this so quickly. If you're processing the quals remotely, but not remove them from the list of quals to be checked locally by the executor, you're fine. If you are checking them remotely *instead of* locally, then you need to make some changes that should look similar to what the patch changed in postgres_fdw. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company