Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Mon, Feb 27, 2017 at 3:12 AM, Robert Haas wrote: > Thanks! Committed. Thanks. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Mon, Feb 20, 2017 at 11:52 AM, Michael Paquier wrote: > On Thu, Feb 16, 2017 at 10:55 AM, Michael Paquier > wrote: >> It is possible to get a test easily in this area by abusing of the >> fact that multiple -d switches defined in psql make it use only the >> last value. By looking at psql() in PostgresNode.pm you would see what >> I mean as -d is defined by default. Or we could just enforce >> PGHOST/PGPORT as there is a method to get the unix domain directory. >> Not sure which one of those two methods is most elegant though. I >> would tend for just using PGHOST and PGPORT. > > What do you think about the patch attached then? As env{PGHOST} is set > once and for all in INIT for each test run, I have gone with the > approach of building connection strings and feed that to psql -d. I > have reused 001_stream_rep.pl so as connections are done on already > existing nodes, making the test really cheap. Here is how the tests > look: > # testing connection parameter target_session_attrs > ok 5 - connect to node master if mode "read-write" and master,standby_1 listed > ok 6 - connect to node master if mode "read-write" and standby_1,master listed > ok 7 - connect to node master if mode "any" and master,standby_1 listed > ok 8 - connect to node standby_1 if mode "any" and standby_1,master listed > > I have registered an entry in the CF here: > https://commitfest.postgresql.org/13/1014/ Thanks! Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Thu, Feb 16, 2017 at 10:55 AM, Michael Paquier wrote: > It is possible to get a test easily in this area by abusing of the > fact that multiple -d switches defined in psql make it use only the > last value. By looking at psql() in PostgresNode.pm you would see what > I mean as -d is defined by default. Or we could just enforce > PGHOST/PGPORT as there is a method to get the unix domain directory. > Not sure which one of those two methods is most elegant though. I > would tend for just using PGHOST and PGPORT. What do you think about the patch attached then? As env{PGHOST} is set once and for all in INIT for each test run, I have gone with the approach of building connection strings and feed that to psql -d. I have reused 001_stream_rep.pl so as connections are done on already existing nodes, making the test really cheap. Here is how the tests look: # testing connection parameter target_session_attrs ok 5 - connect to node master if mode "read-write" and master,standby_1 listed ok 6 - connect to node master if mode "read-write" and standby_1,master listed ok 7 - connect to node master if mode "any" and master,standby_1 listed ok 8 - connect to node standby_1 if mode "any" and standby_1,master listed I have registered an entry in the CF here: https://commitfest.postgresql.org/13/1014/ -- Michael target_session_attrs-tap.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Thu, Feb 16, 2017 at 1:08 AM, Robert Haas wrote: > Great, thanks! This looks good to me, so committed. Thanks. > Is there any > chance you can use your amazing TAP-test-creation powers to do some > automated testing of this feature? For example, maybe we could at > least set up a master and a standby and somehow test that asking for a > read-only server picks the standby if it's first but asking for a > read-write server tries the standby and then switches to the master? > It would also be nice to test that probing a server that doesn't exist > fails, but I'm not sure how to create an IP/port combination that's > guaranteed to not work. It is possible to get a test easily in this area by abusing of the fact that multiple -d switches defined in psql make it use only the last value. By looking at psql() in PostgresNode.pm you would see what I mean as -d is defined by default. Or we could just enforce PGHOST/PGPORT as there is a method to get the unix domain directory. Not sure which one of those two methods is most elegant though. I would tend for just using PGHOST and PGPORT. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Wed, Feb 15, 2017 at 1:31 AM, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote: >> I think the patch as presented probably isn't quite what we want, >> because it waits synchronously for the second result to be ready. >> Note that the wait for the first result is asynchronous: we check >> PQisBusy and return without progressing the state machine until the >> latter returns false; only then do we call PQgetResult(). > > OK, I have been poking at this problem. I think that we need to > introduce a new state in ConnStatusType telling "please consume all > results until PQgetResult returns NULL" which is CONNECTION_CONSUME in > the patch attached. And as long as all the results are not consumed, > the loop just keeps going. If more messages are being waited for with > PGisBusy returning true, then the loop requests for more data to read > by switching back to PGRES_POLLING_READING. > > By the way, I am noticing as well that libpq.sgml is missing a > reference to CONNECTION_CHECK_WRITABLE. This should be present as > applications calling PQconnectPoll() could face such a status. I have > fixed this issue as well in the patch attached. Great, thanks! This looks good to me, so committed. Is there any chance you can use your amazing TAP-test-creation powers to do some automated testing of this feature? For example, maybe we could at least set up a master and a standby and somehow test that asking for a read-only server picks the standby if it's first but asking for a read-write server tries the standby and then switches to the master? It would also be nice to test that probing a server that doesn't exist fails, but I'm not sure how to create an IP/port combination that's guaranteed to not work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote: > I think the patch as presented probably isn't quite what we want, > because it waits synchronously for the second result to be ready. > Note that the wait for the first result is asynchronous: we check > PQisBusy and return without progressing the state machine until the > latter returns false; only then do we call PQgetResult(). OK, I have been poking at this problem. I think that we need to introduce a new state in ConnStatusType telling "please consume all results until PQgetResult returns NULL" which is CONNECTION_CONSUME in the patch attached. And as long as all the results are not consumed, the loop just keeps going. If more messages are being waited for with PGisBusy returning true, then the loop requests for more data to read by switching back to PGRES_POLLING_READING. By the way, I am noticing as well that libpq.sgml is missing a reference to CONNECTION_CHECK_WRITABLE. This should be present as applications calling PQconnectPoll() could face such a status. I have fixed this issue as well in the patch attached. -- Michael pqsendquery-fix-v3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Tue, Feb 14, 2017 at 12:11 AM, Michael Paquier wrote: > On Thu, Feb 2, 2017 at 3:01 PM, Higuchi, Daisuke > wrote: >> From: Michael Paquier [mailto:michael.paqu...@gmail.com] >>>This has not been added yet to the next CF. As Ashutosh mentioned >>>things tend to be easily forgotten. So I have added it here: >>>https://commitfest.postgresql.org/13/982/ >> Thank you for adding this problem to CF. > > I have added this thread to the list of open items for PG10: > https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items Good catch, Michael. I think the patch as presented probably isn't quite what we want, because it waits synchronously for the second result to be ready. Note that the wait for the first result is asynchronous: we check PQisBusy and return without progressing the state machine until the latter returns false; only then do we call PQgetResult(). But the typo fix is of course correct, and independent. Committed that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Thu, Feb 2, 2017 at 3:01 PM, Higuchi, Daisuke wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >>This has not been added yet to the next CF. As Ashutosh mentioned >>things tend to be easily forgotten. So I have added it here: >>https://commitfest.postgresql.org/13/982/ > Thank you for adding this problem to CF. I have added this thread to the list of open items for PG10: https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
From: Michael Paquier [mailto:michael.paqu...@gmail.com] >This has not been added yet to the next CF. As Ashutosh mentioned >things tend to be easily forgotten. So I have added it here: >https://commitfest.postgresql.org/13/982/ Thank you for adding this problem to CF. > I have noticed this typo on the way => s/requisted/requested/: >--- a/src/interfaces/libpq/fe-connect.c >+++ b/src/interfaces/libpq/fe-connect.c >@@ -2908,7 +2908,7 @@ keep_going: /* We will >come back to here until there is >} >/* >-* If a read-write connection is requisted check for same. >+* If a read-write connection is requested check for same. > */ >if (conn->target_session_attrs != NULL && >strcmp(conn->target_session_attrs, "read-write") == 0) I add this fix to the updated patch. This is based on the patch Ashutosh updated. Regards, Daisuke, Higuchi PQsendQuery_for_target_session_attrs_v4.patch Description: PQsendQuery_for_target_session_attrs_v4.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] >Sorry, attached wrong patch. Here's the right one. > The code expects that there will be two PQgetResult() calls required. > One to fetch the result of SHOW command and the other to extract NULL. > If we require more calls or unexpected results, we should throw and > error. The patch just checks the first result and consumes the > remaining without verifying them. Also, it looks like we can not clear > result of PQgetResult() before using the values or copying them > somewhere else [1]. Here's updated patch which tries to do that. > Please let me know if this looks good to you. Oh, I had a basic misunderstanding. Thank you for correct me. There is no problem in the patch you attached. I agree with you. Regards, Daisuke, Higuchi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Thu, Feb 2, 2017 at 1:34 PM, Ashutosh Bapat wrote: > On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat > wrote: >> [1] https://www.postgresql.org/docs/devel/static/libpq-exec.html: >> PQgetvalue(). > The code expects that there will be two PQgetResult() calls required. > One to fetch the result of SHOW command and the other to extract NULL. > If we require more calls or unexpected results, we should throw and > error. The patch just checks the first result and consumes the > remaining without verifying them. Also, it looks like we can not clear > result of PQgetResult() before using the values or copying them > somewhere else [1]. Here's updated patch which tries to do that. > Please let me know if this looks good to you. This has not been added yet to the next CF. As Ashutosh mentioned things tend to be easily forgotten. So I have added it here: https://commitfest.postgresql.org/13/982/ I have noticed this typo on the way => s/requisted/requested/: --- a/src/interfaces/libpq/fe-connect.c +++ b/src/interfaces/libpq/fe-connect.c @@ -2908,7 +2908,7 @@ keep_going: /* We will come back to here until there is } /* -* If a read-write connection is requisted check for same. +* If a read-write connection is requested check for same. */ if (conn->target_session_attrs != NULL && strcmp(conn->target_session_attrs, "read-write") == 0) Looking at the patch, I agree with Ashutosh. Any fix should be located in the code path of CONNECTION_CHECK_WRITABLE which is the one consuming the results. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
Sorry, attached wrong patch. Here's the right one. On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat wrote: > On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke > wrote: >> From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] >>> Per the documentation [1], "PQgetResult must be called repeatedly >>> until it returns a null pointer, indicating that the command is >>> done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE >>> case, violates that. The patch fixes it. The patch however jumps to >>> keep_going without changing conn->status, which means that it will end >>> up again in the same case. While that's fine, may be we should use a >>> local loop on PQgetResult() to keep the code readable. >> Thank you for reviewing the patch. >> I created it with reference to pqSetenvPoll() in >> interfaces/libpq/fe-protocol2.c, >> but I certainly thought that readability is not good. >> I updated the patch, so I will add this to the next commitfest. > > Thanks for the patch. > > The code expects that there will be two PQgetResult() calls required. > One to fetch the result of SHOW command and the other to extract NULL. > If we require more calls or unexpected results, we should throw and > error. The patch just checks the first result and consumes the > remaining without verifying them. Also, it looks like we can not clear > result of PQgetResult() before using the values or copying them > somewhere else [1]. Here's updated patch which tries to do that. > Please let me know if this looks good to you. > > > [1] https://www.postgresql.org/docs/devel/static/libpq-exec.html: > PQgetvalue(). > -- > Best Wishes, > Ashutosh Bapat > EnterpriseDB Corporation > The Postgres Database Company -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company PQsendQuery_for_target_session_attrs_v3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke wrote: > From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] >> Per the documentation [1], "PQgetResult must be called repeatedly >> until it returns a null pointer, indicating that the command is >> done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE >> case, violates that. The patch fixes it. The patch however jumps to >> keep_going without changing conn->status, which means that it will end >> up again in the same case. While that's fine, may be we should use a >> local loop on PQgetResult() to keep the code readable. > Thank you for reviewing the patch. > I created it with reference to pqSetenvPoll() in > interfaces/libpq/fe-protocol2.c, > but I certainly thought that readability is not good. > I updated the patch, so I will add this to the next commitfest. Thanks for the patch. The code expects that there will be two PQgetResult() calls required. One to fetch the result of SHOW command and the other to extract NULL. If we require more calls or unexpected results, we should throw and error. The patch just checks the first result and consumes the remaining without verifying them. Also, it looks like we can not clear result of PQgetResult() before using the values or copying them somewhere else [1]. Here's updated patch which tries to do that. Please let me know if this looks good to you. [1] https://www.postgresql.org/docs/devel/static/libpq-exec.html: PQgetvalue(). -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company PQsendQuery_for_target_session_attrs_v3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] > Per the documentation [1], "PQgetResult must be called repeatedly > until it returns a null pointer, indicating that the command is > done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE > case, violates that. The patch fixes it. The patch however jumps to > keep_going without changing conn->status, which means that it will end > up again in the same case. While that's fine, may be we should use a > local loop on PQgetResult() to keep the code readable. Thank you for reviewing the patch. I created it with reference to pqSetenvPoll() in interfaces/libpq/fe-protocol2.c, but I certainly thought that readability is not good. I updated the patch, so I will add this to the next commitfest. Regards, Daisuke, Higuchi PQsendQuery_for_target_session_attrs_v2.patch Description: PQsendQuery_for_target_session_attrs_v2.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
Please add this to the next commitfest, so that we don't forget it. On Wed, Feb 1, 2017 at 3:58 PM, Ashutosh Bapat wrote: > On Tue, Jan 31, 2017 at 9:53 AM, Higuchi, Daisuke > wrote: >> Hello, >> >> This this is my first posting to the mailing list. >> >> I am interested in multiple hosts of libpq [1], then I found the bug in this >> feature. >> When I set "target_session_attrs" to "any" and call PQsendQuery, my >> application is succeeded. >> However, when I set "target_session_attrs" to "read-write" and call >> PQsendQuery, "another command is already in progress" is occurred. >> I attached the test application to reproduce this problem. >> >> I think this is because PQgetResult is not called until PQgetResult has >> returned a null pointer. >> So, I attached the patch for fix this. >> >> [1] >> https://www.postgresql.org/message-id/flat/20150818041850.ga5...@wagner.pp.ru#20150818041850.ga5...@wagner.pp.ru >> > Interestingly, when I don't set PGPORT, PGHOST I get the same error > with the C program. The patch fixes the problem. > > Per the documentation [1], "PQgetResult must be called repeatedly > until it returns a null pointer, indicating that the command is > done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE > case, violates that. The patch fixes it. The patch however jumps to > keep_going without changing conn->status, which means that it will end > up again in the same case. While that's fine, may be we should use a > local loop on PQgetResult() to keep the code readable. > > I would have added a test with the patch, but it seems we don't have > much tests in interfaces/libpq. The bug is pretty trivial and would > have been caught easily had we had any tests. > > [1] https://www.postgresql.org/docs/devel/static/libpq-async.html > > -- > Best Wishes, > Ashutosh Bapat > EnterpriseDB Corporation > The Postgres Database Company -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
On Tue, Jan 31, 2017 at 9:53 AM, Higuchi, Daisuke wrote: > Hello, > > This this is my first posting to the mailing list. > > I am interested in multiple hosts of libpq [1], then I found the bug in this > feature. > When I set "target_session_attrs" to "any" and call PQsendQuery, my > application is succeeded. > However, when I set "target_session_attrs" to "read-write" and call > PQsendQuery, "another command is already in progress" is occurred. > I attached the test application to reproduce this problem. > > I think this is because PQgetResult is not called until PQgetResult has > returned a null pointer. > So, I attached the patch for fix this. > > [1] > https://www.postgresql.org/message-id/flat/20150818041850.ga5...@wagner.pp.ru#20150818041850.ga5...@wagner.pp.ru > Interestingly, when I don't set PGPORT, PGHOST I get the same error with the C program. The patch fixes the problem. Per the documentation [1], "PQgetResult must be called repeatedly until it returns a null pointer, indicating that the command is done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE case, violates that. The patch fixes it. The patch however jumps to keep_going without changing conn->status, which means that it will end up again in the same case. While that's fine, may be we should use a local loop on PQgetResult() to keep the code readable. I would have added a test with the patch, but it seems we don't have much tests in interfaces/libpq. The bug is pretty trivial and would have been caught easily had we had any tests. [1] https://www.postgresql.org/docs/devel/static/libpq-async.html -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
Hello, This this is my first posting to the mailing list. I am interested in multiple hosts of libpq [1], then I found the bug in this feature. When I set "target_session_attrs" to "any" and call PQsendQuery, my application is succeeded. However, when I set "target_session_attrs" to "read-write" and call PQsendQuery, "another command is already in progress" is occurred. I attached the test application to reproduce this problem. I think this is because PQgetResult is not called until PQgetResult has returned a null pointer. So, I attached the patch for fix this. [1] https://www.postgresql.org/message-id/flat/20150818041850.ga5...@wagner.pp.ru#20150818041850.ga5...@wagner.pp.ru Regards, Daisuke Higuchi /* * gcc multiple_hosts_test.c -lpq -I/home/postgres/work/pgsql10/include -L/home/postgres/work/pgsql10/lib * if target_session_attrs=read-write, "another command is already in progress" is occured */ #include #include #include #ifdef WIN32 #include #endif #include "libpq-fe.h" int main( int argc, char *argv[]) { int i=0,rtn; PGconn *conn; PGresult *r; const char *keywords[5]; const char *values[5]; /* ** Connect to postgres */ keywords[0] = "dbname"; values[0] = "postgres"; keywords[1] = "port"; values[1] = (char *)getenv("PGPORT"); /* export PGPORT=5432,5433 */ keywords[1] = "host"; values[1] = (char *)getenv("PGHOST"); /* export PGHOST=localhost,localhost */ keywords[2] = "target_session_attrs"; values[2] = "read-write"; keywords[3] = NULL; values[3] = NULL; conn = PQconnectdbParams((const char * const*)&keywords, (const char * const*)&values, 1); if (PQstatus(conn) != CONNECTION_OK) { printf("Connection to database failed: %s \n",PQerrorMessage(conn)); goto ERR; } printf("host=%s,port=%s\n",PQhost(conn),PQport(conn)); /* ** Asynchronous statement */ printf("-- SHOW transaction_read_only --\n"); rtn = PQsendQuery(conn, "SHOW transaction_read_only"); if (rtn != 1) { printf( "SHOW command failed: %s", PQerrorMessage(conn)); goto ERR; } r = PQgetResult(conn); printf("SHOW transaction_read_only:%s\n",PQgetvalue(r, 0, 0)); r = PQgetResult(conn); PQclear(r); /* ** Disconnect */ PQfinish(conn); printf("Success!\n"); return(0); ERR: PQfinish(conn); printf("Failed!\n"); return(1); } PQsendQuery_for_target_session_attrs_v1.patch Description: PQsendQuery_for_target_session_attrs_v1.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers