Re: [BUGS] Deadlock condition in driver
We hit this problem and modified the driver to use non-blocking IO to fix it. You lose some of the more unusual features of the driver (such as switching the socket after open), but it does fix the blocking. Richard Evans On Wed, 21 May 2008, Daniel Migowski wrote: I came across a deadlock condition in the JDBC driver that rises when very large queries, containing thousends of statements are send to the server with statement.execute(). We already consider this case for batch execution and break the batch into an internal size that we expect is safe from deadlock. It looks like we should be doing the same for these one query batches. I'm not sure how tough that will be, but I'll take a look. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Deadlock condition in driver
Previously we did not want to move to nio to be able to support older JDK versions, but with the next major release we're ready to drop that support. If you have this code, I'd certainly be interested in looking at it. One of the big drawbacks of breaking up a single execute call into multiple batches is that in autocommit mode you would get one transaction per batch instead of the previous behavior of one transaction for the whole execute call. Kris Jurka On Thu, 22 May 2008, Richard Evans wrote: We hit this problem and modified the driver to use non-blocking IO to fix it. You lose some of the more unusual features of the driver (such as switching the socket after open), but it does fix the blocking. Richard Evans On Wed, 21 May 2008, Daniel Migowski wrote: I came across a deadlock condition in the JDBC driver that rises when very large queries, containing thousends of statements are send to the server with statement.execute(). We already consider this case for batch execution and break the batch into an internal size that we expect is safe from deadlock. It looks like we should be doing the same for these one query batches. I'm not sure how tough that will be, but I'll take a look. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] error message psql: expected authentication request from server, but received when using psql to connect remote database
TIAN Justin [EMAIL PROTECTED] writes: Thanks for your quick response; the server we used is 8.1.4, The error when using client 8.1.4, psql -U or -p -d testdb -h localhost Output: psql: expected authentication request from server, but received What is in the server's pg_hba.conf file? I'm particularly wondering what auth method is being selected ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Thomas H wrote: the patch discussed here [1] that supposedly made the win32 msvc builds use lc_locale properly has flaws. I think you misunderstood the feature [1] added recently. This new feature doesn't rely on lc_messages to localize the day and month names; it uses lc_time. Look at the archives for reference. [1] http://archives.postgresql.org/pgsql-patches/2008-04/msg00451.php -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
euler taveira de olivieira wrote: the patch discussed here [1] that supposedly made the win32 msvc builds use lc_locale properly has flaws. I think you misunderstood the feature [1] added recently. This new actually no. the problem is as i intended to point out with the system generated error messages. their language is supposedly controlled by LC_MESSAGES (as was the time/date output, according to the first february patch submission). please observe the (previously already submitted) test queries. i've removed the date/time testqueries to no further distract from the problem. the bogus query select x; always results in a german error messages no matter what LC_MESSAGES is set: endor=# set lc_messages to 'sv_SE'; SET endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# endor=# set lc_messages to 'de_DE'; SET endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# endor=# set lc_messages to 'English_United_States'; SET endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# endor=# set lc_messages to 'fr'; SET endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; setting LC_MESSAGES in postgres.conf doesn't change anything either. and the comment there says explicitly that LC_MESSAGES is used for system errors: lc_messages = 'English_United_States' # locale for system error message # strings nevertheless, everything is outputted in german now, errors as well as logs. which seems to hint at 8.3.1 ignoring the LC_MESSAGES and always using the os' locale. regards, thomas -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Thomas H. wrote: please observe the (previously already submitted) test queries. i've removed the date/time testqueries to no further distract from the problem. the bogus query select x; always results in a german error messages no matter what LC_MESSAGES is set: OK, that's another problem. AFAIK, that's a known problem because Windows doesn't have LC_MESSAGES. The above comment (pg_locale.c) suggests that there is no verification for the locale that is been set. A possible solution is to use IsValidLocaleName() [1] or LocaleNameToLCID() [2] but it seems that they're only available for Vista. :( Maybe we could emulate one of these functions with a mapping table [3]. [searching ...] It seems there are problems with LCIDs; they don't describe the locales acurately. pgwin hackers? Could you try to use one of the locale names described in [4]? /* * LC_MESSAGES category does not exist everywhere, but accept it anyway * * On Windows, we can't even check the value, so the non-doit case is a * no-op */ [1] http://msdn.microsoft.com/en-us/library/ms776379(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/ms776388(VS.85).aspx [3] http://msdn.microsoft.com/en-us/library/ms776260.aspx -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
