buildfarm failures on crake and sittella

Started by Robert Haasabout 10 years ago4 messages
#1Robert Haas
robertmhaas@gmail.com

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Andrew Dunstan
andrew@dunslane.net
In reply to: Robert Haas (#1)
Re: buildfarm failures on crake and sittella

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Andrew Dunstan (#2)
Re: buildfarm failures on crake and sittella

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#4Robert Haas
robertmhaas@gmail.com
In reply to: Andrew Dunstan (#3)
Re: buildfarm failures on crake and sittella

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers