Re: Regarding identifying a foreign scan - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Regarding identifying a foreign scan
Date
Msg-id CAOeZVidU8L39ksjASe3-DY6h4YsAisrP2VkVUyABjNSePTVkqg@mail.gmail.com
Whole thread Raw
In response to Re: Regarding identifying a foreign scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Regarding identifying a foreign scan
List pgsql-hackers
On Sun, Oct 7, 2012 at 3:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Atri Sharma <atri.jiit@gmail.com> writes:
>> 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
>> crashing.
>
> That sounds like an FDW bug ... which FDW are we talking about?
>
>> 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
>> crash.
>
> The FDW should certainly not assume that only one scan can happen at a
> time.  I would not think this would be a problem as long as you're using
> reasonable coding techniques, like keeping scan-local state in
> scan-local storage and not globally.
>
>> Any hints on how I can detect this condition please?
>
> If you are imagining that you'd do something differently depending on
> whether the current query contains multiple ForeignScan nodes for your
> FDW, that's still doomed to lose, because of nested queries.  You really
> need to manage storage in a way that doesn't make assumptions of this
> sort.
>
>                         regards, tom lane

Hi Tom,

Thanks for the reply.

Does that mean that using (some) global storage is the cause of the problem?

Atri


-- 
Regards,

Atri
l'apprenant



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [COMMITTERS] pgsql: Bump up catalog vesion due to 64-bit large object API functions
Next
From: Amit kapila
Date:
Subject: Re: 64-bit API for large object