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
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 |