Re: [HACKERS] RESET CONNECTION?
Tatsuo Ishii wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. Hmm, what interface code are you talking about? I believe JDBC, for example, sets things inside the interface that would be broken by RESET CONNECTION. Here is a thread about it: http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php I think we had similar problem with client encoding and solved it by using parameter status. Why don't we solve the JDBC problem in the same way? Oh, yes, we could do that. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] RESET CONNECTION?
Alvaro Herrera wrote: Bruce Momjian wrote: Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. Hmm, what interface code are you talking about? I believe JDBC, for example, sets things inside the interface that would be broken by RESET CONNECTION. Here is a thread about it: http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php I think we had similar problem with client encoding and solved it by using parameter status. Why don't we solve the JDBC problem in the same way? -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] RESET CONNECTION?
Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. Imho, if it where at the protocol level, that would not be such an issue. If the interface gives access to the protocol level it is already depending on good will. Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] RESET CONNECTION?
Alvaro Herrera wrote: Bruce Momjian wrote: Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. Hmm, what interface code are you talking about? I believe JDBC, for example, sets things inside the interface that would be broken by RESET CONNECTION. Here is a thread about it: http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RESET CONNECTION?
Tatsuo Ishii wrote: I'm disappointed. Can you point out past discussion for this? Yes: http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php --- -- Tatsuo Ishii SRA OSS, Inc. Japan Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. --- Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] RESET CONNECTION?
Bruce Momjian wrote: Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. Hmm, what interface code are you talking about? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] RESET CONNECTION?
Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RESET CONNECTION?
Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. --- Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] RESET CONNECTION?
I'm disappointed. Can you point out past discussion for this? -- Tatsuo Ishii SRA OSS, Inc. Japan Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. --- Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] RESET CONNECTION idea
Our current RESET CONNECTION TODO item is: * Add RESET CONNECTION command to reset all session state This would include resetting of all variables (RESET ALL), dropping of temporary tables, removing any NOTIFYs, cursors, open transactions, prepared queries, currval()s, etc. This could be used for connection pooling. We could also change RESET ALL to have this functionality. The difficult of this features is allowing RESET ALL to not affect changes made by the interface driver for its internal use. One idea is for this to be a protocol-only feature. Another approach is to notify the protocol when a RESET CONNECTION command is used. I know we have GUC variables that are passed automatically to the client. I assume varaible changes are also automatically sent to the client. What if we create a 'reset_connection' guc that is initially false, and is set to 'true' when someone resets a connection. Then, when it happens, the client finds out, reconfigures whatever it needs, then sets the value back to 'false'. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RESET CONNECTION idea
Bruce Momjian pgman@candle.pha.pa.us writes: What if we create a 'reset_connection' guc that is initially false, and is set to 'true' when someone resets a connection. Then, when it happens, the client finds out, reconfigures whatever it needs, then sets the value back to 'false'. It seems to me that one could trivially break any driver that depends on such a thing, just by issuing SET reset_connection = true; Then the driver will think the connection has been reset when it has not, and become completely confused about the actual connection state. You can't avoid this by making the variable protected, because then the driver itself would be unable to clear it. In short I don't think this can work. We'd need an actual protocol message specifically to report RESET CONNECTION. The loss of backwards compatibility is not necessarily a bad thing; arguably, you *want* any client library that doesn't recognize the message to fail, since otherwise it will be out of sync about the connection state. Alternatively, depending on what level of client software you think should be issuing such things, we could make the RESET request be a new protocol message rather than a SQL statement. Then it couldn't even be invoked by a non-updated client, and so the compatibility problem goes away. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] RESET CONNECTION behavior
Can we get a list features we want for RESET CONNECTION? At this point, I see ideas but no consistent approach. Some say protocol only, others say an SQL command is fine, but the protocol has to find out it happened somehow. Is that a plan? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] RESET CONNECTION behavior
Bruce Momjian wrote: Can we get a list features we want for RESET CONNECTION? At this point, I see ideas but no consistent approach. Some say protocol only, others say an SQL command is fine, but the protocol has to find out it happened somehow. Is that a plan? I have enhanced our TODO for this item: * Add RESET CONNECTION command to reset all session state This would include resetting of all variables (RESET ALL), dropping of temporary tables, removing any NOTIFYs, cursors, open transactions, prepared queries, currval()s, etc. This could be used for connection pooling. We could also change RESET ALL to have this functionality. The difficult of this features is allowing RESET ALL to not affect changes made by the interface driver for its internal use. One idea is for this to be a protocol-only feature. Another approach is to notify the protocol when a RESET CONNECTION command is used. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
