On Fri, Oct 9, 2015 at 3:35 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
wrote:

Hi,

Just to have hands on, I started looking into this issue and trying to
grasp it as this is totally new code for me. And later I want to review
this code changes.

I have noticed that, this thread started saying we are getting a crash
with the given steps with foreign_join_v16.patch, I am correct?

Then there are various patches which trying to fix this,
fdw-eval-plan-qual-*.patch

I have tried applying foreign_join_v16.patch, which was good. And tried
reproducing the crash. But instead of crash I am getting following error.

ERROR:  could not serialize access due to concurrent update
CONTEXT:  Remote SQL command: SELECT a FROM public.foo FOR UPDATE
Remote SQL command: SELECT a FROM public.tab FOR UPDATE


Then I have applied fdw-eval-plan-qual-3.0.patch on top of it. It was not
getting applied cleanly (may be due to some other changes meanwhile).
I fixed the conflicts and the warnings to make it compile.

When I run same sql sequence, I am getting crash in terminal 2 at EXPLAIN
it self.

server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

Following sql statement I am using:

create table tab (a int, b int);
create foreign table foo (a int) server myserver options(table_name 'tab');
create foreign table bar (a int) server myserver options(table_name 'tab');

insert into tab values (1, 1);
insert into foo values (1);
insert into bar values (1);

analyze tab;
analyze foo;
analyze bar;


Run the example:

[Terminal 1]
begin;
update tab set b = b + 1 where a = 1;

[Terminal 2]
explain verbose select tab.* from tab, foo, bar where tab.a =
foo.a and foo.a = bar.a for update;


Am I missing something here?
Do I need to apply any other patch from other mail-threads?

Do you have sample test-case explaining the issue and fix?

With these simple questions, I might have taking the thread slightly off
from the design considerations, please excuse me for that.

Thanks

-- 
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Reply via email to