Skip site navigation (1) Skip section navigation (2)

Re: Regarding identifying a foreign scan

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Regarding identifying a foreign scan
Date: 2012-10-06 20:09:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Oct 6, 2012 at 4:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
>> On Sat, Oct 6, 2012 at 3:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
>>>> I am trying to identify foreign scans uniquely.
>>> What do you mean by "identify"?  What are you trying to accomplish,
>>> and in what context?
>> I am trying to identify the situation where a query has multiple
>> foreign scans.In that case,I need to check whether the current scan is
>> the same as a previous scan or not.If not,then I think it means that
>> multiple scans are in progress on the same backend.
> Well, if you search the plan tree and find more than one ForeignScan
> node, it means there's more than one foreign scan.  It doesn't seem to
> me to be very complicated.  Now, if you're wondering whether they
> reference the same server or not, that's a bit harder.  I guess you
> could look at the RTEs, fetch the foreign-table data for each FT
> relation OID, and see if the same server is referenced.
>                         regards, tom lane

Hi Tom,

Thanks for the extensive reply.

The issue I am trying to resolve is that if two scans are taking place
on the same backend(due to the same query),then,the server is

e.g. foreign_table is a foreign table

SELECT * FROM foreign_table UNION SELECT * FROM foreign_table; results
in a crash of the server.

I think it is because I am not saving the state of the scan,so,if
multiple scans a re running on the same backend,then,it is causing the

Any hints on how I can detect this condition please?




In response to


pgsql-hackers by date

Next:From: Kohei KaiGaiDate: 2012-10-06 20:16:12
Subject: Re: ALTER command reworks
Previous:From: Tom LaneDate: 2012-10-06 20:05:20
Subject: Re: Regarding identifying a foreign scan

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group