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-07 05:22:36
Message-ID: CAOeZVidU8L39ksjASe3-DY6h4YsAisrP2VkVUyABjNSePTVkqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 7, 2012 at 3:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Atri Sharma <atri(dot)jiit(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit kapila 2012-10-07 05:32:07 Re: 64-bit API for large object
Previous Message Tatsuo Ishii 2012-10-07 00:41:08 Re: [COMMITTERS] pgsql: Bump up catalog vesion due to 64-bit large object API functions