[BUGS] libpq not reentrant
hi, this is my first post here and i don't know if there is a specific way to report a postgresql bug apart from a 'plain' meil to this list. anyway, here it is. libpq claims to be reentrant; to put it shortly it isn't. the problem arise when using crypt authentication. on the Linux/glibc2 arch, the call to crypt() is not reentrant and crypt_r or DES/libcrypto crypt should be used instead. we discovered this one while investigating a problem of garbled passwords in psycopg (the Posgresql/Python driver.) the problem disappeared when we stopped the multithreading during PQconnectdb. another way to solve the problem was to patch libpq to use crypt_r or DES crypt and leaving psycopg run multithreaded. another little note: crypt_r documentation says is enough to set to 0 the 'initialized' field of the crypt_data struct but then the crypted strings are not the same generated by plain crypt (or DES crypt). to get the same result a memset to 0 of the entire crypt_data struct is required. hope this help, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Abandon the search for Truth; settle for a good fantasy. -- Anonymous msg03457/pgp0.pgp Description: PGP signature
Re: [BUGS] libpq not reentrant
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > libpq claims to be reentrant; to put it shortly it isn't. the problem > arise when using crypt authentication. on the Linux/glibc2 arch, the > call to crypt() is not reentrant and crypt_r or DES/libcrypto crypt > should be used instead. Hmm. Good point; but crypt_r isn't portable, so we can't easily switch over to it. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] libpq not reentrant
Il ven, 2002-01-18 alle 15:59, Tom Lane ha scritto: > Federico Di Gregorio <[EMAIL PROTECTED]> writes: > > libpq claims to be reentrant; to put it shortly it isn't. the problem > > arise when using crypt authentication. on the Linux/glibc2 arch, the > > call to crypt() is not reentrant and crypt_r or DES/libcrypto crypt > > should be used instead. > > Hmm. Good point; but crypt_r isn't portable, so we can't easily switch > over to it. Thoughts? i don't know about other OSs/libcs and if they are reentrant or not. lets try to summarize (some help with people using postgres on other OSs will be usefull here): Linux/glibc crypt not reentrant crypt_r reentrant and always available DES crypt reentrant if pgsql is compiled with ssl support i can see ./configure trying to find a reentrant crypt and revert to a not-reentrant one only as a last resort. as i said, i don't know about other OSs, maybe OSs without glic/crypt_r already have a reentrant version of crypt. i can also try to patch libpq and the configure stuff to do that, if you're interested in including such a patch in postgres. ciao, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra msg03459/pgp0.pgp Description: PGP signature
Re: [BUGS] libpq not reentrant
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> i can see ./configure trying to find a reentrant crypt and revert to a
> not-reentrant one only as a last resort.
Well, the lack of any man page for crypt_r on Linux doesn't give me a
warm feeling about its level of supportedness there. crypt_r() does
exist on HPUX, but there seems to be a little problem of compatibility.
I read in the Linux /usr/include/crypt.h:
#ifdef __USE_GNU
/* Reentrant versions of the functions above. The additional argument
points to a structure where the results are placed in. */
struct crypt_data
{
char keysched[16 * 8];
char sb0[32768];
char sb1[32768];
char sb2[32768];
char sb3[32768];
/* end-of-aligment-critical-data */
char crypt_3_buf[14];
char current_salt[2];
long int current_saltbits;
int direction, initialized;
};
extern char *crypt_r (__const char *__key, __const char *__salt,
struct crypt_data * __restrict __data) __THROW;
...
which immediately leaves one wondering whether __USE_GNU is defined by
default. But assuming it is, let's compare to HPUX, where the crypt
man page saith:
SYNOPSIS
#include
#include
char *crypt(const char *key, const char *salt);
char *crypt_r(const char *key, const char *salt, CRYPTD *cd);
...
Reentrant Interfaces
cd is a pointer to a CRYPTD object, which is defined in .
For crypt_r(), cd is used as a buffer to store the result string.
So right off the bat, configure is going to have a task guessing
the correct type of the third argument to crypt_r. (Who knows what
it is on other Unixen...)
Given that as of 7.2, MD5 is the preferred password encryption method
and crypt() is deprecated, I'm not inclined to spend a lot of work
trying to develop a bulletproof autoconf procedure for making crypt
re-entrant. I'm strongly inclined to just document the problem and
leave it at that. Comments?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] libpq not reentrant
Il ven, 2002-01-18 alle 16:21, Tom Lane ha scritto: > So right off the bat, configure is going to have a task guessing > the correct type of the third argument to crypt_r. (Who knows what > it is on other Unixen...) very bad, indeed. i think i'll solve that (on my side) by adding a configure option to psycopg to be used to allow threading when the user is *sure* postgres has been compiled with a reentrant version of crypt. > Given that as of 7.2, MD5 is the preferred password encryption method > and crypt() is deprecated, I'm not inclined to spend a lot of work > trying to develop a bulletproof autoconf procedure for making crypt > re-entrant. I'm strongly inclined to just document the problem and > leave it at that. Comments? yes. what about using crypt from DES (reentrant) if postgres is being linked with it? is the MD5 stuff reentrant? thank you for your promptly response, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] La felicità è una tazza di cioccolata calda. Sempre. -- Io msg03461/pgp0.pgp Description: PGP signature
Re: [BUGS] libpq not reentrant
Federico Di Gregorio <[EMAIL PROTECTED]> writes: >> Given that as of 7.2, MD5 is the preferred password encryption method >> and crypt() is deprecated, I'm not inclined to spend a lot of work >> trying to develop a bulletproof autoconf procedure for making crypt >> re-entrant. I'm strongly inclined to just document the problem and >> leave it at that. Comments? > yes. what about using crypt from DES (reentrant) if postgres is being > linked with it? Dunno, how would we detect that? Is it any more portable than crypt_r? Is it worth the trouble? > is the MD5 stuff reentrant? Yes. It's all our own code, so we don't have to rely on the vagaries of local libraries, either. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] libpq not reentrant
Il ven, 2002-01-18 alle 16:35, Tom Lane ha scritto: > Federico Di Gregorio <[EMAIL PROTECTED]> writes: > >> Given that as of 7.2, MD5 is the preferred password encryption method > >> and crypt() is deprecated, I'm not inclined to spend a lot of work > >> trying to develop a bulletproof autoconf procedure for making crypt > >> re-entrant. I'm strongly inclined to just document the problem and > >> leave it at that. Comments? > > > yes. what about using crypt from DES (reentrant) if postgres is being > > linked with it? > > Dunno, how would we detect that? Is it any more portable than crypt_r? ./cofigure --help ... --with-openssl[=DIR]build with OpenSSL support [/usr/local/ssl] so the right library is already detected. the function is called des_crypt and is completely compatible with std. i think that a AC_SEARCH_LIBS(crypto, des_crypt) in configure.in will suffice. then: #ifdef HAVE_DES_CRYPT #define crypt des_crypt #endif in the right file will do the trick. (i know this is not a real patch, sorry. i can make one later at home if you need.) > Is it worth the trouble? i don't know if other drivers/applications have an aggressive multithreaded approach as psycopg has, but if they do, yes, it is worth, imo. if psycopg is the only one, no, because i will fix the problem in it. > > is the MD5 stuff reentrant? > > Yes. It's all our own code, so we don't have to rely on the vagaries of > local libraries, either. great. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] All'inizio ho scritto un programma proprietario, in esclusiva per il cliente; è stato tristissimo, perchè mi ha succhiato un pezzo di anima. -- Alessandro Rubini msg03463/pgp0.pgp Description: PGP signature
Re: [BUGS] libpq not reentrant
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > so the right library is already detected. the function is called > des_crypt and is completely compatible with std. i think that a > AC_SEARCH_LIBS(crypto, des_crypt) > in configure.in will suffice. then: > #ifdef HAVE_DES_CRYPT > #define crypt des_crypt > #endif Hmm. If it uses the same API as crypt(), how can it be reentrant --- is it malloc'ing the result string? The resulting leak probably isn't significant for libpq's purposes, but I'm curious to know. > in the right file will do the trick. (i know this is not a real patch, > sorry. i can make one later at home if you need.) Please put together and test a complete patch. I don't really care for the #define crypt, BTW --- seems too likely to cause problems. I'd suggest #ifdef'ing around the call to crypt(). Also, if the result string is malloc'd, code along the lines of #ifdef HAVE_DES_CRYPT foo = des_crypt(...); #else foo = crypt(...); #endif ... use foo ... #ifdef HAVE_DES_CRYPT /* des_crypt returns malloc'd string */ free(foo); #endif doesn't seem too unreasonable. Or even #ifdef HAVE_DES_CRYPT foo = des_crypt(...); #else foo = strdup(crypt(...)); #endif ... use foo ... free(foo); which would at least narrow the window for problems when using non-reentrant crypt. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] libpq not reentrant
> So right off the bat, configure is going to have a task guessing > the correct type of the third argument to crypt_r. (Who knows what > it is on other Unixen...) > > Given that as of 7.2, MD5 is the preferred password encryption method > and crypt() is deprecated, I'm not inclined to spend a lot of work > trying to develop a bulletproof autoconf procedure for making crypt > re-entrant. I'm strongly inclined to just document the problem and > leave it at that. Comments? As of 7.2 we are only going to recommend crypt for backward compatibility with older releases. I will add a mention in libpq docs that crypt authentication is not thread-safe. Even when crypt did work it wasn't always portable between OS's. Is that how we want to go? -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] libpq not reentrant
Bruce Momjian <[EMAIL PROTECTED]> writes: > As of 7.2 we are only going to recommend crypt for backward > compatibility with older releases. I will add a mention in libpq docs > that crypt authentication is not thread-safe. Even when crypt did work > it wasn't always portable between OS's. Is that how we want to go? I really think that a mention in the docs (in the part where libpq re-entrancy is discussed) is sufficient. Especially given how close we are to 7.2 release. I would not favor adding a configure check now, even if Federico had the patch ready to go... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] libpq not reentrant
Il ven, 2002-01-18 alle 18:23, Tom Lane ha scritto: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > As of 7.2 we are only going to recommend crypt for backward > > compatibility with older releases. I will add a mention in libpq docs > > that crypt authentication is not thread-safe. Even when crypt did work > > it wasn't always portable between OS's. Is that how we want to go? > > I really think that a mention in the docs (in the part where libpq > re-entrancy is discussed) is sufficient. Especially given how close > we are to 7.2 release. I would not favor adding a configure check > now, even if Federico had the patch ready to go... agreed. i'll add a configure-time switch to psycopg and a big warning in the README. the time to write a (already deprecated) patch is better spent coding something else. thank you for your assistance, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Best friends are often failed lovers. -- Me msg03467/pgp0.pgp Description: PGP signature
Re: [BUGS] libpq not reentrant
Tom Lane writes: > Well, the lack of any man page for crypt_r on Linux doesn't give me a > warm feeling about its level of supportedness there. Tom, the man pages on Linux are completely worthless. If you want to get authorative information about what a function does and how it behaves, you need to use "info libc". -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] libpq not reentrant
Bruce Momjian writes: > As of 7.2 we are only going to recommend crypt for backward > compatibility with older releases. I will add a mention in libpq docs > that crypt authentication is not thread-safe. Even when crypt did work ^^ "may not be" > it wasn't always portable between OS's. Is that how we want to go? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] ehm...
On dom, gen 13, 2002 at 11:30:08 -0500, Tom Lane wrote: > Hm, you never did a VACUUM at all? Don't see how that can be --- > removal of CLOG segments is triggered by VACUUM. uhm... i was sure i didn't do vacuum... but... well... so I made other tests. > > Please let me know if you can still see the problem with today's snapshot. i've tried in these days, and it seems everything work right now... thanks a lot for your time, andrea ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] postgres error on debian woody
after having upgraded my linux debia woody release to all the new packagesm postgresql does not run anymore. The error i get is: Starting PostgreSQL postmaster. shift: can't shift that many Please help me. thanks dr. ing. marco giardini -- -- ing. Marco Giardini Cell +39 347 2548824 TecnoGi spa Tel. +39 0321 885422 Via del Vallo 7 Fax +39 0321 885333 Borgolavezzaro (NO) http://www.tecnogi.com Key fingerprint = B5 B4 AA 91 89 50 43 8F B1 6B C6 8C 34 79 5A 7F ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] build problem with postgresql on AIX 4.3.3
Hello
I am getting the following error when I build postgresql 7.1.1 on
AIX 4.3.3 machine. I am unable to figure it out what's the problem
is. I have GNU make and gcc on the system. It woulb be a great help
if you can help me.
Thanks
Hasan Ahmed
ACCC Systems
University of Illinois at Chicago
---
gmake[1]: Entering directory `/usr/local/src/postgresql-7.1.1/doc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/local/src/postgresql-7.1.1/doc'
gmake -C src all
gmake[1]: Entering directory `/usr/local/src/postgresql-7.1.1/src'
gmake -C backend all
gmake[2]: Entering directory `/usr/local/src/postgresql-7.1.1/src/backend'
gmake -C access all
gmake[3]: Entering directory
`/usr/local/src/postgresql-7.1.1/src/backend/access'
gmake -C common SUBSYS.o
gmake[4]: Entering directory
`/usr/local/src/postgresql-7.1.1/src/backend/access/common'
xlc -O2 -qmaxmem=16384 -qsrcmsg -qlonglong -I../../../../src/include -c
-o heaptuple.o heaptuple.c
"../../../../src/include/c.h", line 193.21: 1506-334 (S) Identifier int8
has already been defined on line 622 of "/usr/include/sys/inttypes.h".
"../../../../src/include/c.h", line 194.22: 1506-334 (S) Identifier int16
has already been defined on line 623 of "/usr/include/sys/inttypes.h".
"../../../../src/include/c.h", line 195.20: 1506-334 (S) Identifier int32
has already been defined on line 624 of "/usr/include/sys/inttypes.h".
"../../../../src/include/c.h", line 265.23: 1506-334 (S) Identifier int64
has already been defined on line 629 of "/usr/include/sys/inttypes.h".
113 | do { switch (att[i]->attlen) { case
sizeof(char): *(char *) (data) = ((char) (((Datum) (value[i])) &
0x00ff)); break; case sizeof(int16): *(int16 *) (data) = ((int16)
(((Datum) (value[i])) & 0x)); break; case sizeof(int32): *(int32
*) (data) = ((int32) (((Datum) (value[i])) & 0x)); break; default:
elog((-1), "store_att_byval: unsupported byval length %d", (int)
(att[i]->attlen)); break; } } while (0);
.a..
a - 1506-052 (S) Duplicate case label for value 0. Labels must be unique.
617 | do { int32 * _start = (int32 *) ((char *) td); int
_val = (0); Size _len = (len); if long) _start) & (sizeof(int32) - 1))
== 0 && (_len & (sizeof(int32) - 1)) == 0 && _val == 0 && _len <= 64) {
int32 * _stop = (int32 *) ((char *) _start + _len); while (_start < _stop)
*_start++ = 0; } else __memset((char *) _start,_val,_len); } while (0);
a.b
a - 1506-068 (E) Operation between types "illegal type*" and "illegal
type*" is not allowed.
b - 1506-281 (S) Prefix and postfix increment and decrement operators
cannot be applied to "illegal type*".
770 | do { int32 * _start = (int32 *) ((char *) td); int
_val = (0); Size _len = (len); if long) _start) & (sizeof(int32) - 1))
== 0 && (_len & (sizeof(int32) - 1)) == 0 && _val == 0 && _len <= 64) {
int32 * _stop = (int32 *) ((char *) _start + _len); while (_start < _stop)
*_start++ = 0; } else __memset((char *) _start,_val,_len); } while (0);
a.b
a - 1506-068 (E) Operation between types "illegal type*" and "illegal
type*" is not allowed.
b - 1506-281 (S) Prefix and postfix increment and decrement operators
cannot be applied to "illegal type*".
gmake[4]: *** [heaptuple.o] Error 1
gmake[4]: Leaving directory
`/usr/local/src/postgresql-7.1.1/src/backend/access/common'
gmake[3]: *** [common-recursive] Error 2
gmake[3]: Leaving directory
`/usr/local/src/postgresql-7.1.1/src/backend/access'
gmake[2]: *** [access-recursive] Error 2
gmake[2]: Leaving directory `/usr/local/src/postgresql-7.1.1/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/usr/local/src/postgresql-7.1.1/src'
gmake: *** [all] Error 2
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] build problem with postgresql on AIX 4.3.3
Hasan Ahmed <[EMAIL PROTECTED]> writes: > I am getting the following error when I build postgresql 7.1.1 on > AIX 4.3.3 machine. > xlc -O2 -qmaxmem=16384 -qsrcmsg -qlonglong -I../../../../src/include -c > -o heaptuple.o heaptuple.c > "../../../../src/include/c.h", line 193.21: 1506-334 (S) Identifier int8 > has already been defined on line 622 of "/usr/include/sys/inttypes.h". > "../../../../src/include/c.h", line 194.22: 1506-334 (S) Identifier int16 > has already been defined on line 623 of "/usr/include/sys/inttypes.h". This should be fixed in current sources (7.2beta5). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] jdbc:postgress problem.
Hi, when I'm trying to access database from the remote host using jdbc I'll get following error message: -- PostgreSQL basic test v6.3 rev 1 Connecting to Database URL = jdbc:postgresql://polaris:5432/coda_lg_db Exception caught. Something unusual has occured to cause the driver to fail. Please report this exception: Exception: java.sql.SQLException: No pg_hba.conf entry for host 129.57.33.170, user coda, database coda_lg_db Stack Trace: java.sql.SQLException: No pg_hba.conf entry for host 129.57.33.170, user coda, database coda_lg_db at org.postgresql.Connection.openConnection(Unknown Source) at org.postgresql.Driver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:517) at java.sql.DriverManager.getConnection(DriverManager.java:177) at basic.(basic.java:37) at basic.main(basic.java:197) End of Stack Trace --- Please help me to solve this problem. Thanking you in advance , vardan ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] odbc error
When trying to execute this :
select select DOC_MAST.MVNUMREG,DOC_MAST.MVDATREG from TESTDOC_MAST
DOC_MAST where DOC_MAST.MVNUMDOC = 57 AND DOC_MAST.MVSERIAL <> '000343'
AND DOC_MAST.MVALFDOC = ' ' AND EXTRACT(YEAR FROM DOC_MAST.MVDATDOC) =
EXTRACT(YEAR FROM {d '2001-11-26'}) AND DOC_MAST.MVPRD = 'DV' AND
DOC_MAST.MVANNDOC = '2001'
with psqlodbc 7.01.00.09, it sends me an error 'cause the type casting {d
'2001-11-26'} doesn't work.
---(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
Re: [BUGS] postgres error on debian woody
Marco Giardini <[EMAIL PROTECTED]> writes: > after having upgraded my linux debia woody release to all the new > packagesm postgresql does not run anymore. > The error i get is: > Starting PostgreSQL postmaster. > shift: can't shift that many This looks like it must be an error in the shell script that is supposed to invoke Postgres. Since that's not our code, we can't help you. Check with the Debian packagers. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] libpq not reentrant
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, new text for docs. That is entirely the wrong place to put it. There is a section specifically about libpq's reentrancy or lack of it; mention the issue there. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] libpq not reentrant
Peter Eisentraut wrote: > Bruce Momjian writes: > > > As of 7.2 we are only going to recommend crypt for backward > > compatibility with older releases. I will add a mention in libpq docs > > that crypt authentication is not thread-safe. Even when crypt did work > ^^ > "may not be" > > > it wasn't always portable between OS's. Is that how we want to go? BSD/OS manual page says: The crypt() function leaves its result in an internal static object and returns a pointer to that object. Subsequent calls to crypt() will modi- fy the same object. The crypt() function may not be safely called concurrently from multiple threads, e.g., the interfaces described by pthreads(3). and the API is the same for all OS's. However, I looked in the Solaris 8 crypt() manual page and found: http://docs.sun.com/ab2/coll.40.6/REFMAN3A/%40Ab2PageView/17377?Ab2Lang=C&Ab2Enc=iso-8859-1 In multithreaded applications, the return value is a pointer to thread-specific data. So here is at least one OS that has a thread-safe crypt, as you suggested. I will mention crypt() relies on the OS's version of crypt(), which is _may_not_be_ not thread-safe. I will then recommend MD5. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] postgres error on debian woody
Il mer, 2002-01-16 alle 18:34, Marco Giardini ha scritto: > after having upgraded my linux debia woody release to all the new > packagesm postgresql does not run anymore. > The error i get is: > > Starting PostgreSQL postmaster. > shift: can't shift that many this bited me too. why don't you use the Debian Bug Tracking (http://bugs.debian.org/) system to report distribution-specific bugs? ciao, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Don't dream it. Be it. -- Dr. Frank'n'further msg03479/pgp0.pgp Description: PGP signature
Re: [BUGS] libpq not reentrant
Peter Eisentraut wrote: > Bruce Momjian writes: > > > As of 7.2 we are only going to recommend crypt for backward > > compatibility with older releases. I will add a mention in libpq docs > > that crypt authentication is not thread-safe. Even when crypt did work > ^^ > "may not be" > > > it wasn't always portable between OS's. Is that how we want to go? OK, new text for docs. -- 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 Index: doc/src/sgml/libpq.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.85 diff -c -r1.85 libpq.sgml *** doc/src/sgml/libpq.sgml 2002/01/07 02:29:12 1.85 --- doc/src/sgml/libpq.sgml 2002/01/18 19:24:22 *** *** 2109,2118 libpq is thread-safe as of PostgreSQL 7.0, so long as no two threads ! attempt to manipulate the same PGconn object at the same time. In particular, ! you cannot issue concurrent queries from different threads through the same ! connection object. (If you need to run concurrent queries, start up multiple ! connections.) --- 2109,2125 libpq is thread-safe as of PostgreSQL 7.0, so long as no two threads ! attempt to manipulate the same PGconn object at the same ! time. In particular, you cannot issue concurrent queries from different ! threads through the same connection object. (If you need to run ! concurrent queries, start up multiple connections.) ! ! ! However, libpq clients using the ! crypt encryption method rely on the ! crypt() operating system function, which often is not ! thread-safe. It is better to use MD5 encryption, ! which is guarantted to be thread-safe on all platforms. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] libpq not reentrant
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, new text for docs. > > That is entirely the wrong place to put it. There is a section > specifically about libpq's reentrancy or lack of it; mention the > issue there. Uh, I put it in this section: Threading Behavior threads with libpq I don't see a section on re-entrancy. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] libpq not reentrant
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> That is entirely the wrong place to put it. There is a section >> specifically about libpq's reentrancy or lack of it; mention the >> issue there. > Uh, I put it in this section: Um ... duh ... I can only plead momentary brain fade. Yes, that is the right section. But I'd suggest moving it down a para or two, to put it next to the para pointing out that PQoidStatus etc are not thread-safe. That was the context I was expecting to see. Also, the "however" can be left out, and ditto "guarantted to be" (which is mispelled anyway...) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] libpq not reentrant
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> That is entirely the wrong place to put it. There is a section > >> specifically about libpq's reentrancy or lack of it; mention the > >> issue there. > > > Uh, I put it in this section: > > Um ... duh ... I can only plead momentary brain fade. Yes, that > is the right section. > > But I'd suggest moving it down a para or two, to put it next to the > para pointing out that PQoidStatus etc are not thread-safe. That > was the context I was expecting to see. > > Also, the "however" can be left out, and ditto "guarantted to be" > (which is mispelled anyway...) OK, have we decided we don't want to ever bother making crypt thread-safe? Is it a TODO item? -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] libpq not reentrant
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, have we decided we don't want to ever bother making crypt > thread-safe? Is it a TODO item? I can't get excited about it. However, if Federico or someone else wants to do the work ... 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
Re: [BUGS] libpq not reentrant
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> That is entirely the wrong place to put it. There is a section > >> specifically about libpq's reentrancy or lack of it; mention the > >> issue there. > > > Uh, I put it in this section: > > Um ... duh ... I can only plead momentary brain fade. Yes, that > is the right section. > > But I'd suggest moving it down a para or two, to put it next to the > para pointing out that PQoidStatus etc are not thread-safe. That > was the context I was expecting to see. > > Also, the "however" can be left out, and ditto "guarantted to be" > (which is mispelled anyway...) Done. Moved to bottom of section; words removed. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] libpq not reentrant
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, have we decided we don't want to ever bother making crypt > > thread-safe? Is it a TODO item? > > I can't get excited about it. However, if Federico or someone else > wants to do the work ... OK, it gets on the TODO: * Use thread-safe crypt() in libpq, if available -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] odbc error
> -Original Message-
> From: Samuele Brignoli
>
> When trying to execute this :
>
> select select DOC_MAST.MVNUMREG,DOC_MAST.MVDATREG from TESTDOC_MAST
> DOC_MAST where DOC_MAST.MVNUMDOC = 57 AND DOC_MAST.MVSERIAL <>
> '000343'
> AND DOC_MAST.MVALFDOC = ' ' AND EXTRACT(YEAR FROM DOC_MAST.MVDATDOC) =
> EXTRACT(YEAR FROM {d '2001-11-26'}) AND DOC_MAST.MVPRD = 'DV' AND
> DOC_MAST.MVANNDOC = '2001'
>
> with psqlodbc 7.01.00.09, it sends me an error 'cause the type casting {d
> '2001-11-26'} doesn't work.
Are you getting the following error ?
ERROR: Function 'date_part(unknown, unknown)' does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
regards,
Hiroshi Inoue
---(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
