Re: [HACKERS] pgAccess fails to launch on HPUX
Tatsuo Ishii writes: If I had known that this was possible I would have done it myself already. ;-) This is a good idea in general because in a default installation pgaccess won't find libpgtcl on any system because it doesn't have the benefit of the -rpath/-R business. Please review/remove the note at the Really? On my RedHat 6.2 derived Linux distribution pgaccess successfully finds libpgtcl.so without any problem. (using Tcl8.0) Then you probably have LD_LIBRARY_PATH set, or you have the linker configured to look into the directory by default. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] RE: [ODBC] RE: [PATCHES] Fix for ODBC close
-Original Message- From: Bruce Momjian OK, I have a pretty good guess about the cause of the ODBC shutdown failure message in the server logs. Sending 'X' is still causing the error message. The error you are seeing is from the backend libpq code, the area that communicates with clients. while ODBC closes with: SOCK_put_char(self, 'X'); SOCK_flush_output(self); Probably you have to put above code before calling shutdown() not after. shutdown(sock, 2) disables both sends and receives on the socket. Regards, Hiroshi Inoue
[HACKERS] Re: [ODBC] RE: [PATCHES] Fix for ODBC close
-Original Message- From: Bruce Momjian OK, I have a pretty good guess about the cause of the ODBC shutdown failure message in the server logs. Sending 'X' is still causing the error message. The error you are seeing is from the backend libpq code, the area that communicates with clients. while ODBC closes with: SOCK_put_char(self, 'X'); SOCK_flush_output(self); Probably you have to put above code before calling shutdown() not after. shutdown(sock, 2) disables both sends and receives on the socket. Thanks. I was so focused on close() I never noticed the shutdown(). Can someone please test now? Hiroshi, should I be concerned that a send() that does not send the full packet just returns an error and does not retry? Is libpq() so complex because of async connections? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] ODBC backward versions
-Original Message- From: Bruce Momjian Sent: Sunday, February 11, 2001 11:01 AM To: PostgreSQL-development Subject: [HACKERS] ODBC backward versions I checked the logs, and we released the new 6.4 backend protocol on 1998-10-30. That was 2.5 years ago. We normally allow older clients to communicate with newer servers, but often we don't support newer clients talking to older servers, sometimes even servers one release in the past. The reason is that the backend communication code gets confusing. For example, I know there were some libpq releases that could not talk to servers from the previous release. Libpq 2.x couldn't talk to pre-6.4 servers. Fortunately ODBC has never used libpq and could talk to wide range of versions. Should ODBC throw away the luck ? Well, the ability to give users choices of old servers is confusing them. 6.4 is so old, they assume they need a newer one to talk to 7.1, and hopefully clearer code will help coders in the future. We did allow newer servers to talk to older clients because it is harder to upgrade many clients than a single server. Seems the =6.3 compatibility code in our current ODBC is just adding confusion for coders and users and should be removed. Tom Lane agreed. Where's real coders for psqlodbc driver in the first place ? Byron has been unavailable for a long time and I've seen few improvements for a year or so. Does removing pre-6.4 code improve the status ? The problem is that there has been no maintainer of odbc driver. We have some new people interested, like Julie Case and I think a few others. I just reformatted the entire odbc directory, which will hopefully make it clearer and attract patches. I know it is clearer for me now. So, no, removing 6.4 does not improve ODBC, but it makes it simpler, and I doubt anyone wants to talk to a 6.3 server using 7.1 ODBC. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [INTERFACES] Re: [HACKERS] pgAccess fails to launch on HPUX
If I had known that this was possible I would have done it myself already. ;-) This is a good idea in general because in a default installation pgaccess won't find libpgtcl on any system because it doesn't have the benefit of the -rpath/-R business. Please review/remove the note at the Really? On my RedHat 6.2 derived Linux distribution pgaccess successfully finds libpgtcl.so without any problem. (using Tcl8.0) Then you probably have LD_LIBRARY_PATH set, or you have the linker configured to look into the directory by default. I thought the point in these discussions is libpgtl.so could not be loaded even if LD_LIBRARY_PATH or whatever is set. -- Tatsuo Ishii
Re: [INTERFACES] Re: [HACKERS] pgAccess fails to launch on HPUX
Tatsuo Ishii writes: I thought the point in these discussions is libpgtl.so could not be loaded even if LD_LIBRARY_PATH or whatever is set. No, the point is that we are trying to avoid the requirement that LD_LIBRARY_PATH has to be set before the system can be used. This works okay with C linkage programs because of the "rpath" feature, but pgaccess does not have the benefit of that so we needed another way for it to find libpgtcl. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: [ODBC] RE: [PATCHES] Fix for ODBC close
+ SOCK_put_char(self, 'X'); + SOCK_flush_output(self); + if (!shutdown(self-socket, 2)) /* no sends or receives */ closesocket(self-socket); I think you should issue the close() whether the shutdown() succeeds or not. Otherwise you have a file descriptor leak. In fact, given that you're going to close the socket, the separate shutdown call is a complete waste of cycles. Take it out. Hiroshi, should I be concerned that a send() that does not send the full packet just returns an error and does not retry? Is libpq() so complex because of async connections? Right, libpq only needs to loop because it runs the socket in nonblock mode. SOCK_flush_output looks OK to me. (SOCK_get_next_byte, on the other hand, goes wacko on error or close... probably should make it return a null character instead of random data.) regards, tom lane
Re: [HACKERS] ODBC backward versions
"Hiroshi Inoue" [EMAIL PROTECTED] writes: Does removing pre-6.4 code improve the status ? Yes, it does (IMHO anyway) because it removes a configuration option that is confusing new users. The odds that someone will want to use 7.1 ODBC with a pre-6.4 server seem very small to me, while we do frequently see questions about the 6.2/6.3/6.4 protocol switch. The problem is that there has been no maintainer of odbc driver. That's certainly true. I hope that someone will start taking responsibility for this code again. regards, tom lane
[HACKERS] Recovery of PGSQL after system crash failing!!!
Guess this what I get for attempting to use a beta version of pgsql in a production system. :( My database server crashed (kernel paging fault it looks like) and after reboot, postmaster refuses to start up. There error it gives is: DEBUG: starting up DEBUG: database system was interrupted at 2001-02-11 04:08:12 DEBUG: Checkpoint record at (0, 805076492) postmaster: reaping dead processes... Startup failed - abort And that is it, from running 'postmaster -D /usr/local/pgsql/data/'. I get the same thing each time I run it. I assume that WAL is for some reason failing to restore/recover the database. The system is a stock Debian 2.2 system, Dual PPro200, w/pgsql 7.1beta4. The system crash occured during the nightly update of the databases (from another, internal, non-pgsql, database system). Is there anyway to recover the database, or do I need to do a 'rm -rf data; initdb'? A quick response would be greatly appreciated. Thanks. --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
Re: [HACKERS] Recovery of PGSQL after system crash failing!!!
Ryan Kirkpatrick [EMAIL PROTECTED] writes: DEBUG: Checkpoint record at (0, 805076492) postmaster: reaping dead processes... Startup failed - abort Hm. All we can tell from this is that the startup subprocess exited with nonzero status. Did it leave a corefile? If so, what's the stack trace? regards, tom lane
[HACKERS] Re: [ODBC] RE: [PATCHES] Fix for ODBC close
Bruce Momjian wrote: -Original Message- From: Bruce Momjian OK, I have a pretty good guess about the cause of the ODBC shutdown failure message in the server logs. Sending 'X' is still causing the error message. The error you are seeing is from the backend libpq code, the area that communicates with clients. while ODBC closes with: SOCK_put_char(self, 'X'); SOCK_flush_output(self); Probably you have to put above code before calling shutdown() not after. shutdown(sock, 2) disables both sends and receives on the socket. Thanks. I was so focused on close() I never noticed the shutdown(). Can someone please test now? I had already tested it in win32 environment before I posted my previous mail. Regards, Hiroshi Inoue
Re: [HACKERS] ODBC backward versions
Tom Lane wrote: "Hiroshi Inoue" [EMAIL PROTECTED] writes: Does removing pre-6.4 code improve the status ? Yes, it does (IMHO anyway) because it removes a configuration option that is confusing new users. Right. There's even an idea(not mine) to remove the option by automatically detecting the server's version. However the option isn't entirely wrong because users could recognize by the option that ODBC driver supports multiple server versions. Unfotunately people are easy to forget that ODBC driver supports multiple versions even though the option exists. The odds that someone will want to use 7.1 ODBC with a pre-6.4 server seem very small to me, while we do frequently see questions about the 6.2/6.3/6.4 protocol switch. The problem is that there has been no maintainer of odbc driver. That's certainly true. I hope that someone will start taking responsibility for this code again. I myself have been using ODBC driver in production system. The absense of a maintainer has been a problem for me. Unfortunately I'm not familiar with ODBC that well and couldn't be a maintainer. I know a person who could maintain our ODBC driver other than Byron. I always recommended him to be a maintainer but he hasn't agreed. Recently I've fixed some light bugs unwillingly but it's hard for me to fix complicated bugs. For exmaple it's very hard for me to check if Ludek Finstrlein's patch([ODBC] pgsqODBC binding parameters II) is right. I'm expecting for the person to answer the question. Regards, Hiroshi Inoue
Re: [HACKERS] Recovery of PGSQL after system crash failing!!!
DEBUG: starting up DEBUG: database system was interrupted at 2001-02-11 04:08:12 DEBUG: Checkpoint record at (0, 805076492) postmaster: reaping dead processes... Startup failed - abort And that is it, from running 'postmaster -D /usr/local/pgsql/data/'. I get the same thing each time I run it. I assume that WAL is for some reason failing to restore/recover the database. The system is a stock Debian 2.2 system, Dual PPro200, w/pgsql 7.1beta4. The system crash occured during the nightly update of the databases (from another, internal, non-pgsql, database system). Is there anyway to recover the database, or do I need to do a 'rm -rf Please try to restart with option wal_debug = 1 so postmaster log will be more informative and send this log me. data; initdb'? A quick response would be greatly appreciated. Thanks. Please archieve PG' data dir - it probably will be useful to find bug. Vadim
[HACKERS] 7.0.3 spelling error
I just got this error message in 7.0.3: ERROR: to_char/to_number(): not unique decimal poit. Might want to ensure it's correctly spelled in 7.1 Chris -- Christopher Kings-Lynne Family Health Network (ACN 089 639 243)
