Menu
▾
▴
postgres-xc-developers
|
From: xiong w. <wan...@gm...> - 2010-12-01 05:48:06
|
Dears, template1=# prepare a(int) as insert into t values($1); LOG: statement: prepare a(int) as insert into t values($1); 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: LOG: server process (PID 26936) was terminated by signal 11: Segmentation fault LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. Failed. Regards, Benny |
|
From: Koichi S. <ko...@in...> - 2010-12-01 07:04:55
|
Do you have backtrace list of the backend? I hope SEGV may have created core file. Regards; --- Koichi Suzuki (2010年12月01日 14:47), xiong wang wrote: > Dears, > template1=# prepare a(int) as insert into t values($1); > LOG: statement: prepare a(int) as insert into t values($1); > 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: LOG: server > process (PID 26936) was terminated by signal 11: Segmentation fault > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > Failed. > Regards, > Benny > > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > > > > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |
|
From: xiong w. <wan...@gm...> - 2010-12-01 07:50:08
|
Hi, Koichi, core stack: #0 0x00000000007984e2 in MemoryContextStrdup () (gdb) bt #0 0x00000000007984e2 in MemoryContextStrdup () #1 0x00000000005c708b in pgxc_planner () #2 0x00000000006263cb in planner () #3 0x00000000006887e7 in pg_plan_query () #4 0x0000000000688895 in pg_plan_queries () #5 0x000000000054f16b in PrepareQuery () #6 0x0000000000690958 in ProcessUtility () #7 0x000000000068f19b in PortalRunUtility () #8 0x000000000068f310 in PortalRunMulti () #9 0x000000000068e99b in PortalRun () #10 0x0000000000688c76 in exec_simple_query () #11 0x000000000068cbe4 in PostgresMain () #12 0x00000000006555da in BackendRun () #13 0x0000000000654b37 in BackendStartup () #14 0x0000000000651f02 in ServerLoop () #15 0x00000000006516a8 in PostmasterMain () #16 0x00000000005d8f47 in main () Regards, Benny 2010/12/1 Koichi Suzuki <ko...@in...> > Do you have backtrace list of the backend? I hope SEGV may have created > core file. > > Regards; > --- > Koichi Suzuki > > > (2010年12月01日 14:47), xiong wang wrote: > >> Dears, >> template1=# prepare a(int) as insert into t values($1); >> LOG: statement: prepare a(int) as insert into t values($1); >> 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: LOG: server >> process (PID 26936) was terminated by signal 11: Segmentation fault >> LOG: terminating any other active server processes >> WARNING: terminating connection because of crash of another server >> process >> DETAIL: The postmaster has commanded this server process to roll back >> the current transaction and exit, because another server process exited >> abnormally and possibly corrupted shared memory. >> HINT: In a moment you should be able to reconnect to the database and >> repeat your command. >> WARNING: terminating connection because of crash of another server >> process >> DETAIL: The postmaster has commanded this server process to roll back >> the current transaction and exit, because another server process exited >> abnormally and possibly corrupted shared memory. >> HINT: In a moment you should be able to reconnect to the database and >> repeat your command. >> Failed. >> Regards, >> Benny >> >> >> >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >> Tap into the largest installed PC base& get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> >> >> >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> > > |
|
From: Koichi S. <koi...@gm...> - 2010-12-01 07:55:43
|
Wang-san; Thanks a lot for the info. Core file will contain the context of pgxc_planner(), which will be needed to find the fix. Andrei; Mason; Could you look into the core file? Regards; ---------- Koichi Suzuki 2010/12/1 xiong wang <wan...@gm...>: > Hi, Koichi, > core stack: > #0 0x00000000007984e2 in MemoryContextStrdup () > (gdb) bt > #0 0x00000000007984e2 in MemoryContextStrdup () > #1 0x00000000005c708b in pgxc_planner () > #2 0x00000000006263cb in planner () > #3 0x00000000006887e7 in pg_plan_query () > #4 0x0000000000688895 in pg_plan_queries () > #5 0x000000000054f16b in PrepareQuery () > #6 0x0000000000690958 in ProcessUtility () > #7 0x000000000068f19b in PortalRunUtility () > #8 0x000000000068f310 in PortalRunMulti () > #9 0x000000000068e99b in PortalRun () > #10 0x0000000000688c76 in exec_simple_query () > #11 0x000000000068cbe4 in PostgresMain () > #12 0x00000000006555da in BackendRun () > #13 0x0000000000654b37 in BackendStartup () > #14 0x0000000000651f02 in ServerLoop () > #15 0x00000000006516a8 in PostmasterMain () > #16 0x00000000005d8f47 in main () > > Regards, > Benny > 2010/12/1 Koichi Suzuki <ko...@in...> >> >> Do you have backtrace list of the backend? I hope SEGV may have created >> core file. >> >> Regards; >> --- >> Koichi Suzuki >> >> (2010年12月01日 14:47), xiong wang wrote: >>> >>> Dears, >>> template1=# prepare a(int) as insert into t values($1); >>> LOG: statement: prepare a(int) as insert into t values($1); >>> 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: LOG: server >>> process (PID 26936) was terminated by signal 11: Segmentation fault >>> LOG: terminating any other active server processes >>> WARNING: terminating connection because of crash of another server >>> process >>> DETAIL: The postmaster has commanded this server process to roll back >>> the current transaction and exit, because another server process exited >>> abnormally and possibly corrupted shared memory. >>> HINT: In a moment you should be able to reconnect to the database and >>> repeat your command. >>> WARNING: terminating connection because of crash of another server >>> process >>> DETAIL: The postmaster has commanded this server process to roll back >>> the current transaction and exit, because another server process exited >>> abnormally and possibly corrupted shared memory. >>> HINT: In a moment you should be able to reconnect to the database and >>> repeat your command. >>> Failed. >>> Regards, >>> Benny >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >>> Tap into the largest installed PC base& get more eyes on your game by >>> optimizing for Intel(R) Graphics Technology. Get started today with the >>> Intel(R) Software Partner Program. Five $500 cash prizes are up for >>> grabs. >>> http://p.sf.net/sfu/intelisp-dev2dev >>> >>> >>> >>> _______________________________________________ >>> Postgres-xc-developers mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > |
|
From: xiong w. <wan...@gm...> - 2010-12-01 08:01:44
|
Hi Michael,
Program terminated with signal 11, Segmentation fault.
[New process 13307]
#0 0x00000000007984e2 in MemoryContextStrdup (context=0x19dac58,
string=0x0) at mcxt.c:659
659 Size len = strlen(string) + 1;
(gdb) bt
#0 0x00000000007984e2 in MemoryContextStrdup (context=0x19dac58,
string=0x0) at mcxt.c:659
#1 0x00000000005c708b in pgxc_planner (query=0x19bc010, cursorOptions=0,
boundParams=0x0) at planner.c:2567
#2 0x00000000006263cb in planner (parse=0x19bc010, cursorOptions=0,
boundParams=0x0) at planner.c:132
#3 0x00000000006887e7 in pg_plan_query (querytree=0x19bc010,
cursorOptions=0, boundParams=0x0) at postgres.c:744
#4 0x0000000000688895 in pg_plan_queries (querytrees=0x19bc940,
cursorOptions=0, boundParams=0x0) at postgres.c:803
#5 0x000000000054f16b in PrepareQuery (stmt=0x199f4f0,
queryString=0x199e890 "prepare a(int) as insert into t values($1);") at
prepare.c:148
#6 0x0000000000690958 in ProcessUtility (parsetree=0x199f4f0,
queryString=0x199e890 "prepare a(int) as insert into t values($1);",
params=0x0, isTopLevel=1 '\001',
dest=0x199f830, completionTag=0x7fff7014f9e0 "") at utility.c:717
#7 0x000000000068f19b in PortalRunUtility (portal=0x19fce80,
utilityStmt=0x199f4f0, isTopLevel=1 '\001',
dest=0x199f830, completionTag=0x7fff7014f9e0 "") at pquery.c:1210
#8 0x000000000068f310 in PortalRunMulti (portal=0x19fce80, isTopLevel=1
'\001', dest=0x199f830, altdest=0x199f830,
completionTag=0x7fff7014f9e0 "") at pquery.c:1315
#9 0x000000000068e99b in PortalRun (portal=0x19fce80,
count=9223372036854775807, isTopLevel=1 '\001',
dest=0x199f830, altdest=0x199f830, completionTag=0x7fff7014f9e0 "") at
pquery.c:837
#10 0x0000000000688c76 in exec_simple_query (query_string=0x199e890 "prepare
a(int) as insert into t values($1);")
at postgres.c:1053
#11 0x000000000068cbe4 in PostgresMain (argc=4, argv=0x18fa170,
username=0x18fa130 "postgres") at postgres.c:3766
#12 0x00000000006555da in BackendRun (port=0x1903480) at postmaster.c:3607
#13 0x0000000000654b37 in BackendStartup (port=0x1903480) at
postmaster.c:3216
#14 0x0000000000651f02 in ServerLoop () at postmaster.c:1445
#15 0x00000000006516a8 in PostmasterMain (argc=7, argv=0x18f8700) at
postmaster.c:1098
#16 0x00000000005d8f47 in main (argc=7, argv=0x18f8700) at main.c:188
Regards,
Benny
2010/12/1 Michael Paquier <mic...@gm...>
> Could you compile with debug mode allowed (--enable-debug when launching
> ./configure)?
> This will help developers tracking easily the error that happened.
>
> Thanks,
> --
> Michael Paquier
> http://michaelpq.users.sourceforge.net
>
>
|
|
From: Mason S. <mas...@en...> - 2010-12-01 14:59:25
|
Benny, Is this with or without the prepared statement patch applied that Andrei posted to the developer mailing list? Thanks, Mason On 12/1/10 12:47 AM, xiong wang wrote: > Dears, > template1=# prepare a(int) as insert into t values($1); > LOG: statement: prepare a(int) as insert into t values($1); > 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: LOG: server > process (PID 26936) was terminated by signal 11: Segmentation fault > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server > process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process > exited abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > WARNING: terminating connection because of crash of another server > process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process > exited abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > Failed. > Regards, > Benny > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > > > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > -- Mason Sharp EnterpriseDB Corporation The Enterprise Postgres Company This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Andrei.Martsinchyk <and...@en...> - 2010-12-01 18:53:25
|
Hi Benny, Thanks for pointing this out. I tested with a program using Postgres C library and extended query protocol. For you and anyone else who want to test I am attaching the test program and simple Makefile. I fixed the segmentation fault (updated patch is attached), but anyway, PREPARE / EXECUTE commands do not work properly. The problem with it of the same kind as reported by you (sending begin;command;). We are using original SQL statement to build up statement for datanodes. In some cases pure command text is not available - it contains garbage, like neighbour statement or ouiter command (PREPARE ... AS). Postgres parser does not split command, it just produces multiple Query trees, or inner Query. We want the command being sent to datanodes is built up based on the Query produced by parser, taking into account planner info. We are working on this. 2010/12/1 xiong wang <wan...@gm...>: > Dears, > > template1=# prepare a(int) as insert into t values($1); > LOG: statement: prepare a(int) as insert into t values($1); > > 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: LOG: server > process (PID 26936) was terminated by signal 11: Segmentation fault > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back the > current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back the > current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > HINT: In a moment you should be able to reconnect to the database and > repeat your command. > Failed. > > Regards, > Benny > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- Andrei Martsinchyk EntepriseDB Corporation The Enterprise Postgres Company Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Mason S. <mas...@en...> - 2010-12-03 14:26:27
|
On 12/1/10 1:53 PM, Andrei.Martsinchyk wrote: > Hi Benny, > > Thanks for pointing this out. I tested with a program using Postgres C > library and extended query protocol. > For you and anyone else who want to test I am attaching the test > program and simple Makefile. > I fixed the segmentation fault (updated patch is attached), but > anyway, PREPARE / EXECUTE commands do not work properly. > It looks like it is still not quite right: mds1=# create table mytab (col1 int, col2 int); CREATE TABLE mds1=# prepare p (int, int) AS INSERT INTO mytab VALUES ($1, $2); PREPARE mds1=# execute p (1,2); INSERT 0 1 mds1=# select * from mytab; col1 | col2 ------+------ (0 rows) It does not find the row that should have been inserted. Also, one other question- the session seems to retain the fact that there are associated prepared statements. Does that mean that the pooler will not put these back in the pool until all are deallocated? On a related note, for the WITH HOLD cursors you implemented, did you also do something to hold on to the connections? Thanks, Mason Mason Sharp EnterpriseDB Corporation The Enterprise Postgres Company This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Andrei.Martsinchyk <and...@en...> - 2010-12-03 16:31:30
|
Mason, 2010/12/3 Mason Sharp <mas...@en...>: > On 12/1/10 1:53 PM, Andrei.Martsinchyk wrote: >> >> Hi Benny, >> >> Thanks for pointing this out. I tested with a program using Postgres C >> library and extended query protocol. >> For you and anyone else who want to test I am attaching the test >> program and simple Makefile. >> I fixed the segmentation fault (updated patch is attached), but >> anyway, PREPARE / EXECUTE commands do not work properly. >> > > It looks like it is still not quite right: > > > mds1=# create table mytab (col1 int, col2 int); > CREATE TABLE > mds1=# prepare p (int, int) AS INSERT INTO mytab VALUES ($1, $2); > PREPARE > mds1=# execute p (1,2); > INSERT 0 1 > mds1=# select * from mytab; > col1 | col2 > ------+------ > (0 rows) > > It does not find the row that should have been inserted. > Yes, I mentioned the PREPARE command does not work properly. In this particular case it is inserting row into Coordinator database and not visible for select. > Also, one other question- the session seems to retain the fact that there > are associated prepared statements. Does that mean that the pooler will not > put these back in the pool until all are deallocated? > Coordinator does not prepare statements on datanodes, so connection can be released at the transaction end. > On a related note, for the WITH HOLD cursors you implemented, did you also > do something to hold on to the connections? > I did not implement WITH HOLD. > Thanks, > > Mason > > > > > Mason Sharp > EnterpriseDB Corporation > The Enterprise Postgres Company > > > This e-mail message (and any attachment) is intended for the use of > the individual or entity to whom it is addressed. This message > contains information from EnterpriseDB Corporation that may be > privileged, confidential, or exempt from disclosure under applicable > law. If you are not the intended recipient or authorized to receive > this for the intended recipient, any use, dissemination, distribution, > retention, archiving, or copying of this communication is strictly > prohibited. If you have received this e-mail in error, please notify > the sender immediately by reply e-mail and delete this message. > > -- Andrei Martsinchyk EntepriseDB Corporation The Enterprise Postgres Company Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Mason S. <mas...@en...> - 2010-12-03 17:19:35
|
Sent from my IPhone On Dec 3, 2010, at 5:31 PM, "Andrei.Martsinchyk" <and...@en...> wrote: > Mason, > > 2010/12/3 Mason Sharp <mas...@en...>: >> On 12/1/10 1:53 PM, Andrei.Martsinchyk wrote: >>> >>> Hi Benny, >>> >>> Thanks for pointing this out. I tested with a program using Postgres C >>> library and extended query protocol. >>> For you and anyone else who want to test I am attaching the test >>> program and simple Makefile. >>> I fixed the segmentation fault (updated patch is attached), but >>> anyway, PREPARE / EXECUTE commands do not work properly. >>> >> >> It looks like it is still not quite right: >> >> >> mds1=# create table mytab (col1 int, col2 int); >> CREATE TABLE >> mds1=# prepare p (int, int) AS INSERT INTO mytab VALUES ($1, $2); >> PREPARE >> mds1=# execute p (1,2); >> INSERT 0 1 >> mds1=# select * from mytab; >> col1 | col2 >> ------+------ >> (0 rows) >> >> It does not find the row that should have been inserted. >> > > Yes, I mentioned the PREPARE command does not work properly. > In this particular case it is inserting row into Coordinator database > and not visible for select. > Oh. So, only SELECT is currently handled? >> Also, one other question- the session seems to retain the fact that there >> are associated prepared statements. Does that mean that the pooler will not >> put these back in the pool until all are deallocated? >> > > Coordinator does not prepare statements on datanodes, so connection > can be released at the transaction end. It converts it into a simple statement? I think we need to support prepare and execute on the data nodes for performance. > >> On a related note, for the WITH HOLD cursors you implemented, did you also >> do something to hold on to the connections? >> > > I did not implement WITH HOLD. Let me retest this, and look at old emails later when back at my laptop. Mason > >> Thanks, >> >> Mason >> >> >> >> >> Mason Sharp >> EnterpriseDB Corporation >> The Enterprise Postgres Company >> >> >> This e-mail message (and any attachment) is intended for the use of >> the individual or entity to whom it is addressed. This message >> contains information from EnterpriseDB Corporation that may be >> privileged, confidential, or exempt from disclosure under applicable >> law. If you are not the intended recipient or authorized to receive >> this for the intended recipient, any use, dissemination, distribution, >> retention, archiving, or copying of this communication is strictly >> prohibited. If you have received this e-mail in error, please notify >> the sender immediately by reply e-mail and delete this message. >> >> > > > > -- > Andrei Martsinchyk > > EntepriseDB Corporation > The Enterprise Postgres Company > > Website: www.enterprisedb.com > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > Follow us on Twitter: http://www.twitter.com/enterprisedb > > This e-mail message (and any attachment) is intended for the use of > the individual or entity to whom it is addressed. This message > contains information from EnterpriseDB Corporation that may be > privileged, confidential, or exempt from disclosure under applicable > law. If you are not the intended recipient or authorized to receive > this for the intended recipient, any use, dissemination, distribution, > retention, archiving, or copying of this communication is strictly > prohibited. If you have received this e-mail in error, please notify > the sender immediately by reply e-mail and delete this message. |
|
From: Andrei.Martsinchyk <and...@en...> - 2010-12-03 18:10:55
|
Mason, 2010/12/3 Mason Sharp <mas...@en...>: > > > > Sent from my IPhone > > On Dec 3, 2010, at 5:31 PM, "Andrei.Martsinchyk" <and...@en...> wrote: > >> Mason, >> >> 2010/12/3 Mason Sharp <mas...@en...>: >>> On 12/1/10 1:53 PM, Andrei.Martsinchyk wrote: >>>> >>>> Hi Benny, >>>> >>>> Thanks for pointing this out. I tested with a program using Postgres C >>>> library and extended query protocol. >>>> For you and anyone else who want to test I am attaching the test >>>> program and simple Makefile. >>>> I fixed the segmentation fault (updated patch is attached), but >>>> anyway, PREPARE / EXECUTE commands do not work properly. >>>> >>> >>> It looks like it is still not quite right: >>> >>> >>> mds1=# create table mytab (col1 int, col2 int); >>> CREATE TABLE >>> mds1=# prepare p (int, int) AS INSERT INTO mytab VALUES ($1, $2); >>> PREPARE >>> mds1=# execute p (1,2); >>> INSERT 0 1 >>> mds1=# select * from mytab; >>> col1 | col2 >>> ------+------ >>> (0 rows) >>> >>> It does not find the row that should have been inserted. >>> >> >> Yes, I mentioned the PREPARE command does not work properly. >> In this particular case it is inserting row into Coordinator database >> and not visible for select. >> > > Oh. So, only SELECT is currently handled? > Some SELECTs work properly, not all. >>> Also, one other question- the session seems to retain the fact that there >>> are associated prepared statements. Does that mean that the pooler will not >>> put these back in the pool until all are deallocated? >>> >> >> Coordinator does not prepare statements on datanodes, so connection >> can be released at the transaction end. > > It converts it into a simple statement? I think we need to support prepare and execute on the data nodes for performance. > It does not seem straightforward. Prepared statement is a cached plan, and it is cached on coordinator. If the plan contains multiple RemoteQuery nodes we should prepare each, and should not release these until all they are closed. We should be holding the data node connections all this time. >> >>> On a related note, for the WITH HOLD cursors you implemented, did you also >>> do something to hold on to the connections? >>> >> >> I did not implement WITH HOLD. > > Let me retest this, and look at old emails later when back at my laptop. > I remember someone told me it works, but I never tested, and never did anything to handle it. > Mason >> >>> Thanks, >>> >>> Mason >>> >>> >>> >>> >>> Mason Sharp >>> EnterpriseDB Corporation >>> The Enterprise Postgres Company >>> >>> >>> This e-mail message (and any attachment) is intended for the use of >>> the individual or entity to whom it is addressed. This message >>> contains information from EnterpriseDB Corporation that may be >>> privileged, confidential, or exempt from disclosure under applicable >>> law. If you are not the intended recipient or authorized to receive >>> this for the intended recipient, any use, dissemination, distribution, >>> retention, archiving, or copying of this communication is strictly >>> prohibited. If you have received this e-mail in error, please notify >>> the sender immediately by reply e-mail and delete this message. >>> >>> >> >> >> >> -- >> Andrei Martsinchyk >> >> EntepriseDB Corporation >> The Enterprise Postgres Company >> >> Website: www.enterprisedb.com >> EnterpriseDB Blog: http://blogs.enterprisedb.com/ >> Follow us on Twitter: http://www.twitter.com/enterprisedb >> >> This e-mail message (and any attachment) is intended for the use of >> the individual or entity to whom it is addressed. This message >> contains information from EnterpriseDB Corporation that may be >> privileged, confidential, or exempt from disclosure under applicable >> law. If you are not the intended recipient or authorized to receive >> this for the intended recipient, any use, dissemination, distribution, >> retention, archiving, or copying of this communication is strictly >> prohibited. If you have received this e-mail in error, please notify >> the sender immediately by reply e-mail and delete this message. > -- Andrei Martsinchyk EntepriseDB Corporation The Enterprise Postgres Company Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Mason S. <mas...@en...> - 2010-12-03 21:32:18
|
On 12/3/10 7:10 PM, Andrei.Martsinchyk wrote:
> Mason,
>
> 2010/12/3 Mason Sharp<mas...@en...>:
>
>>
>>
>> Sent from my IPhone
>>
>> On Dec 3, 2010, at 5:31 PM, "Andrei.Martsinchyk"<and...@en...> wrote:
>>
>>
>>> Mason,
>>>
>>> 2010/12/3 Mason Sharp<mas...@en...>:
>>>
>>>> On 12/1/10 1:53 PM, Andrei.Martsinchyk wrote:
>>>>
>>>>> Hi Benny,
>>>>>
>>>>> Thanks for pointing this out. I tested with a program using Postgres C
>>>>> library and extended query protocol.
>>>>> For you and anyone else who want to test I am attaching the test
>>>>> program and simple Makefile.
>>>>> I fixed the segmentation fault (updated patch is attached), but
>>>>> anyway, PREPARE / EXECUTE commands do not work properly.
>>>>>
>>>>>
>>>> It looks like it is still not quite right:
>>>>
>>>>
>>>> mds1=# create table mytab (col1 int, col2 int);
>>>> CREATE TABLE
>>>> mds1=# prepare p (int, int) AS INSERT INTO mytab VALUES ($1, $2);
>>>> PREPARE
>>>> mds1=# execute p (1,2);
>>>> INSERT 0 1
>>>> mds1=# select * from mytab;
>>>> col1 | col2
>>>> ------+------
>>>> (0 rows)
>>>>
>>>> It does not find the row that should have been inserted.
>>>>
>>>>
>>> Yes, I mentioned the PREPARE command does not work properly.
>>> In this particular case it is inserting row into Coordinator database
>>> and not visible for select.
>>>
>>>
>> Oh. So, only SELECT is currently handled?
>>
>>
> Some SELECTs work properly, not all.
>
Only single-step ones? That is fine. Are any other SELECT statements
problematic?
How about UPDATE and DELETE? I just ran a simple UPDATE, and it failed, too.
>
>>>> Also, one other question- the session seems to retain the fact that there
>>>> are associated prepared statements. Does that mean that the pooler will not
>>>> put these back in the pool until all are deallocated?
>>>>
>>>>
>>> Coordinator does not prepare statements on datanodes, so connection
>>> can be released at the transaction end.
>>>
>> It converts it into a simple statement? I think we need to support prepare and execute on the data nodes for performance.
>>
>>
> It does not seem straightforward. Prepared statement is a cached plan,
> and it is cached on coordinator. If the plan contains multiple
> RemoteQuery nodes we should prepare each, and should not release these
> until all they are closed. We should be holding the data node
> connections all this time.
>
If it is just a matter of holding on to the connections, that is fine,
we can persist those for the duration of the session. Do you need the
RemoteQuery nodes to persist, too, or just the connections? I understand
that we may have to track which connections a statement has already been
prepared on, and which ones it has not yet. At EXECUTE time, if a data
node has not been prepared yet, we send down the prepare message first.
>
>>>
>>>> On a related note, for the WITH HOLD cursors you implemented, did you also
>>>> do something to hold on to the connections?
>>>>
>>>>
>>> I did not implement WITH HOLD.
>>>
>> Let me retest this, and look at old emails later when back at my laptop.
>>
>>
> I remember someone told me it works, but I never tested, and never did
> anything to handle it.
>
>
I tried it out:
mds1=# begin;
BEGIN
mds1=# declare c cursor with hold for select * from mds1;
DECLARE CURSOR
mds1=# fetch c;
col1 | col2
------+------
1 | 10
(1 row)
mds1=# commit;
COMMIT
mds1=# fetch c;
col1 | col2
------+------
3 | 30
(1 row)
This worries me a bit that it got "fixed" unintentionally.
We may have gotten lucky in that we refetched the same connection(s)
from the pooler. Meanwhile, the Coordinator still knows about cursor c,
so it did not object. It may be that the only thing we need to do is,
if we have any open hold cursors, we do not return the connections to
the pool but persist them.
I also expect we would add to this over time, like, if the user created
any temp tables (and has not dropped them), persist the connections
(similar to GridSQL).
Thanks,
Mason
>> Mason
>>
>>>
>>>> Thanks,
>>>>
>>>> Mason
>>>>
>>>>
>>>>
>>>>
>>>> Mason Sharp
>>>> EnterpriseDB Corporation
>>>> The Enterprise Postgres Company
>>>>
>>>>
>>>> This e-mail message (and any attachment) is intended for the use of
>>>> the individual or entity to whom it is addressed. This message
>>>> contains information from EnterpriseDB Corporation that may be
>>>> privileged, confidential, or exempt from disclosure under applicable
>>>> law. If you are not the intended recipient or authorized to receive
>>>> this for the intended recipient, any use, dissemination, distribution,
>>>> retention, archiving, or copying of this communication is strictly
>>>> prohibited. If you have received this e-mail in error, please notify
>>>> the sender immediately by reply e-mail and delete this message.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Andrei Martsinchyk
>>>
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>>
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>
>>> This e-mail message (and any attachment) is intended for the use of
>>> the individual or entity to whom it is addressed. This message
>>> contains information from EnterpriseDB Corporation that may be
>>> privileged, confidential, or exempt from disclosure under applicable
>>> law. If you are not the intended recipient or authorized to receive
>>> this for the intended recipient, any use, dissemination, distribution,
>>> retention, archiving, or copying of this communication is strictly
>>> prohibited. If you have received this e-mail in error, please notify
>>> the sender immediately by reply e-mail and delete this message.
>>>
>>
>
>
>
--
Mason Sharp
EnterpriseDB Corporation
The Enterprise Postgres Company
This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X