[PATCHES] Typo in README
Hi there, Noticed a typo in the root README file. Patch below. Regards, BJ --- a/README +++ b/README @@ -20,7 +20,7 @@ PHP - http://www.php.net Python - http://www.initd.org/ Ruby - http://ruby.scripting.ca/postgres/ -Other language binding are available from a variety of contributing +Other language bindings are available from a variety of contributing parties. PostgreSQL also has a great number of procedural languages available, -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Typo in README
Brendan Jurd wrote: Hi there, Noticed a typo in the root README file. Patch below. Regards, BJ --- a/README +++ b/README @@ -20,7 +20,7 @@ PHP - http://www.php.net Python - http://www.initd.org/ Ruby - http://ruby.scripting.ca/postgres/ -Other language binding are available from a variety of contributing +Other language bindings are available from a variety of contributing parties. Thanks, fixed (not ignored). ;-) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] libpq patch for pqtypes hook api and PGresult creation
Here are the changes to libpq. It adds the ability to register an
Object Hook and create a home-grown result. Patch adds 4 functions.
We changed the name of PQresultSetFieldValue to PQsetvalue, which better
compliments PQgetvalue. If this patch is acceptable, we will move on to
making the required changes to pqtypes; some work has already been done.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/interfaces/libpq/exports.txt
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.19
diff -c -r1.19 exports.txt
*** src/interfaces/libpq/exports.txt19 Mar 2008 00:39:33 - 1.19
--- src/interfaces/libpq/exports.txt11 Apr 2008 17:36:26 -
***
*** 141,143
--- 141,147
pg_valid_server_encoding_id 139
PQconnectionNeedsPassword 140
lo_import_with_oid 141
+ PQaddObjectHook 142
+ PQremoveObjectHook143
+ PQmakeResult 144
+ PQsetvalue145
\ No newline at end of file
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.357
diff -c -r1.357 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 31 Mar 2008 02:43:14 - 1.357
--- src/interfaces/libpq/fe-connect.c 11 Apr 2008 17:36:26 -
***
*** 866,872
--- 866,887
* we are in PGRES_POLLING_WRITING connection state.
*/
if (PQconnectPoll(conn) == PGRES_POLLING_WRITING)
+ {
+ int objHooksCount;
+ const PGobjectHooks *objHooks;
+
+ if((objHooksCount = pqGetObjectHooks(objHooks)) 0)
+ {
+ int i;
+
+ for(i=0; i objHooksCount; i++)
+ if(objHooks[i].connCreate)
+
objHooks[i].connCreate(objHooks[i].name, conn);
+ }
+ pqReleaseObjectHooks();
+
return 1;
+ }
connect_errReturn:
if (conn-sock = 0)
***
*** 1973,1978
--- 1988,2006
static void
freePGconn(PGconn *conn)
{
+ int objHooksCount;
+ const PGobjectHooks *objHooks;
+
+ if((objHooksCount = pqGetObjectHooks(objHooks)) 0)
+ {
+ int i;
+
+ for(i=0; i objHooksCount; i++)
+ if(objHooks[i].connDestroy)
+ objHooks[i].connDestroy(objHooks[i].name, conn);
+ }
+ pqReleaseObjectHooks();
+
if (conn-pghost)
free(conn-pghost);
if (conn-pghostaddr)
Index: src/interfaces/libpq/fe-exec.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.194
diff -c -r1.194 fe-exec.c
*** src/interfaces/libpq/fe-exec.c 1 Jan 2008 19:46:00 - 1.194
--- src/interfaces/libpq/fe-exec.c 11 Apr 2008 17:36:27 -
***
*** 63,69
static PGresult *PQexecFinish(PGconn *conn);
static int PQsendDescribe(PGconn *conn, char desc_type,
const char *desc_target);
!
/*
* Space management for PGresult.
--- 63,69
static PGresult *PQexecFinish(PGconn *conn);
static int PQsendDescribe(PGconn *conn, char desc_type,
const char *desc_target);
! static int check_field_number(const PGresult *res, int field_num);
/*
* Space management for PGresult.
***
*** 139,144
--- 139,146
PQmakeEmptyPGresult(PGconn *conn, ExecStatusType status)
{
PGresult *result;
+ int objHooksCount;
+ const PGobjectHooks *objHooks;
result = (PGresult *) malloc(sizeof(PGresult));
if (!result)
***
*** 192,200
--- 194,341
result-client_encoding = PG_SQL_ASCII;
}
+ if((objHooksCount = pqGetObjectHooks(objHooks)) 0)
+ {
+ int i;
+
+ for(i=0; i objHooksCount; i++)
+ if(objHooks[i].resultCreate)
+ objHooks[i].resultCreate(objHooks[i].name,
conn, result);
+ }
+ pqReleaseObjectHooks();
+
return result;
}
+ PGresult *PQmakeResult(
+ PGconn *conn,
+ int numAttributes,
+ PGresAttDesc *attDescs)
+ {
+ int i;
+ PGresult *res;
+
+ if(numAttributes = 0 || !attDescs)
+ return NULL;
+
+ res = PQmakeEmptyPGresult(conn, PGRES_TUPLES_OK);
+ if(!res)
+ return NULL;
+
+ res-attDescs = (PGresAttDesc *)
+ pqResultAlloc(res, numAttributes * sizeof(PGresAttDesc), TRUE);
+
+ if(!res-attDescs)
+ {
+
Re: [PATCHES] libpq patch for pqtypes hook api and PGresult creation
On Fri, Apr 11, 2008 at 1:47 PM, Andrew Chernow [EMAIL PROTECTED] wrote: Here are the changes to libpq. It adds the ability to register an Object Hook and create a home-grown result. Patch adds 4 functions. We changed the name of PQresultSetFieldValue to PQsetvalue, which better compliments PQgetvalue. If this patch is acceptable, we will move on to making the required changes to pqtypes; some work has already been done. Whoops! One missing thing here...we forgot to make pqResultAlloc pubilc...pqResultAlloc - PQresultAlloc (see discussion in -hackers). Also, we could use pqResultStrdup (or keep it private, in which case we can re-implement in libpqtypes). merlin -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] libpq Win32 Mutex performance patch
I noticed several months ago, and came across it again today, that
libpq's pthread-win32.c implementation is using CreateMutex rather than
CRITICAL_SECTION. CreateMutex is like a semaphore in that it is
designed to be accessible via name system-wide. Even when you don't
give it a name, thus bound to process that created it, it still carries
significant overhead compared to using win32 CRITICAL_SECTIONs.
The attached patch replaces the win32 mutex calls with critical section
calls. The change will not affect the behavior of the windows
pthread_xxx functions.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/port/pthread-win32.h
===
RCS file: /projects/cvsroot/pgsql/src/port/pthread-win32.h,v
retrieving revision 1.2
diff -c -r1.2 pthread-win32.h
*** src/port/pthread-win32.h18 Apr 2007 08:32:40 - 1.2
--- src/port/pthread-win32.h11 Apr 2008 18:35:33 -
***
*** 2,8
#define __PTHREAD_H
typedef ULONG pthread_key_t;
! typedef HANDLE pthread_mutex_t;
typedef int pthread_once_t;
DWORD pthread_self(void);
--- 2,8
#define __PTHREAD_H
typedef ULONG pthread_key_t;
! typedef CRITICAL_SECTION *pthread_mutex_t;
typedef int pthread_once_t;
DWORD pthread_self(void);
Index: src/interfaces/libpq/pthread-win32.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/pthread-win32.c,v
retrieving revision 1.15
diff -c -r1.15 pthread-win32.c
*** src/interfaces/libpq/pthread-win32.c1 Jan 2008 19:46:00 -
1.15
--- src/interfaces/libpq/pthread-win32.c11 Apr 2008 18:35:33 -
***
*** 35,51
void
pthread_mutex_init(pthread_mutex_t *mp, void *attr)
{
! *mp = CreateMutex(0, 0, 0);
}
void
pthread_mutex_lock(pthread_mutex_t *mp)
{
! WaitForSingleObject(*mp, INFINITE);
}
void
pthread_mutex_unlock(pthread_mutex_t *mp)
{
! ReleaseMutex(*mp);
}
--- 35,69
void
pthread_mutex_init(pthread_mutex_t *mp, void *attr)
{
! if(mp)
! {
! *mp = (CRITICAL_SECTION *)malloc(sizeof(CRITICAL_SECTION));
! if(*mp)
! InitializeCriticalSection(*mp);
! }
}
void
pthread_mutex_lock(pthread_mutex_t *mp)
{
! if(mp *mp)
! EnterCriticalSection(*mp);
}
void
pthread_mutex_unlock(pthread_mutex_t *mp)
{
! if(mp *mp)
! LeaveCriticalSection(*mp);
}
+
+ /* If ever needed
+ pthread_mutex_destroy(pthread_mutex_t *mp)
+ {
+ if(mp *mp)
+ {
+ DeleteCriticalSection(*mp);
+ *mp = NULL;
+ }
+ }
+ */
\ No newline at end of file
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
Andrew Chernow wrote: I noticed several months ago, and came across it again today, that libpq's pthread-win32.c implementation is using CreateMutex rather than CRITICAL_SECTION. CreateMutex is like a semaphore in that it is designed to be accessible via name system-wide. Even when you don't give it a name, thus bound to process that created it, it still carries significant overhead compared to using win32 CRITICAL_SECTIONs. The attached patch replaces the win32 mutex calls with critical section calls. The change will not affect the behavior of the windows pthread_xxx functions. First of all, I like this in general :-) But a couple of comments. It changes the behavior when the pointer passed in is invalid from crash to silent working, right? This shouldn't actually matter, since these functions are only ever supposed to run from callers *inside libpq*, so it probalby doesn't matter... Which brings up the second point - is there any actual reason for adding the pthread_mutex_destroy call? Since libpq never calls it, and it's never used from outside libpq (it's not exported outside the library even), isn't it just going to end up as dead code? //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
Magnus Hagander wrote: It changes the behavior when the pointer passed in is invalid from crash to silent working, right? Correct, it a Habit. I sub-consciously write code that checks pointers. We can remove the pointer checks and let the thing dump core if people prefer. Which brings up the second point - is there any actual reason for adding the pthread_mutex_destroy call? Since libpq never calls it, and it's never used from outside libpq (it's not exported outside the library even), isn't it just going to end up as dead code? //Magnus The destroy call is within a comment. I only put it there in case it is ever needeed. BTW, I just noticed the commented destroy call forgot to free(*mp) ... ooppssseee. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander [EMAIL PROTECTED] wrote: Andrew Chernow wrote: I noticed several months ago, and came across it again today, that libpq's pthread-win32.c implementation is using CreateMutex rather than CRITICAL_SECTION. CreateMutex is like a semaphore in that it is designed to be accessible via name system-wide. Even when you don't give it a name, thus bound to process that created it, it still carries significant overhead compared to using win32 CRITICAL_SECTIONs. The attached patch replaces the win32 mutex calls with critical section calls. The change will not affect the behavior of the windows pthread_xxx functions. First of all, I like this in general :-) But a couple of comments. It changes the behavior when the pointer passed in is invalid from crash to silent working, right? This shouldn't actually matter, since these functions are only ever supposed to run from callers *inside libpq*, so it probalby doesn't matter... I noticed you conjured up a ecpg threading patch sometime around early 2007. You used a mutex there deliberately because that's what libpq did. Maybe that patch should be adjusted? merlin -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
Andrew Chernow [EMAIL PROTECTED] writes: The attached patch replaces the win32 mutex calls with critical section calls. The change will not affect the behavior of the windows pthread_xxx functions. Why have you defined the lock/unlock functions as willing to fall through silently if handed a null pointer? I think a crash in such a case is what we *want*. Silently not locking is surely not very safe. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: The attached patch replaces the win32 mutex calls with critical section calls. The change will not affect the behavior of the windows pthread_xxx functions. Why have you defined the lock/unlock functions as willing to fall through silently if handed a null pointer? I think a crash in such a case is what we *want*. Silently not locking is surely not very safe. regards, tom lane Yeah, both naughty. These functions were not implemented to spec. These pthread functions are all supposed to return an int (which is an errno value). I was trying not to change the existing prototypes ... should I? I can return EINVAL if something is NULL and ENOMEM if the malloc fails ... or just dump core. If you like the return value idea, I can make all occurances of pthread_xxx check the return value. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the return
value idea, let me know.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/port/pthread-win32.h
===
RCS file: /projects/cvsroot/pgsql/src/port/pthread-win32.h,v
retrieving revision 1.2
diff -c -r1.2 pthread-win32.h
*** src/port/pthread-win32.h18 Apr 2007 08:32:40 - 1.2
--- src/port/pthread-win32.h11 Apr 2008 19:22:17 -
***
*** 2,8
#define __PTHREAD_H
typedef ULONG pthread_key_t;
! typedef HANDLE pthread_mutex_t;
typedef int pthread_once_t;
DWORD pthread_self(void);
--- 2,8
#define __PTHREAD_H
typedef ULONG pthread_key_t;
! typedef CRITICAL_SECTION *pthread_mutex_t;
typedef int pthread_once_t;
DWORD pthread_self(void);
Index: src/interfaces/libpq/pthread-win32.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/pthread-win32.c,v
retrieving revision 1.15
diff -c -r1.15 pthread-win32.c
*** src/interfaces/libpq/pthread-win32.c1 Jan 2008 19:46:00 -
1.15
--- src/interfaces/libpq/pthread-win32.c11 Apr 2008 19:22:17 -
***
*** 35,51
void
pthread_mutex_init(pthread_mutex_t *mp, void *attr)
{
! *mp = CreateMutex(0, 0, 0);
}
void
pthread_mutex_lock(pthread_mutex_t *mp)
{
! WaitForSingleObject(*mp, INFINITE);
}
void
pthread_mutex_unlock(pthread_mutex_t *mp)
{
! ReleaseMutex(*mp);
}
--- 35,61
void
pthread_mutex_init(pthread_mutex_t *mp, void *attr)
{
! *mp = (CRITICAL_SECTION *)malloc(sizeof(CRITICAL_SECTION));
! InitializeCriticalSection(*mp);
}
void
pthread_mutex_lock(pthread_mutex_t *mp)
{
! EnterCriticalSection(*mp);
}
void
pthread_mutex_unlock(pthread_mutex_t *mp)
{
! LeaveCriticalSection(*mp);
}
+
+ /* If ever needed
+ void pthread_mutex_destroy(pthread_mutex_t *mp)
+ {
+ DeleteCriticalSection(*mp);
+ free(*mp);
+ *mp = NULL;
+ }
+ */
\ No newline at end of file
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Maintaining cluster order on insert
This idea has been rejected to do poor performance results reported later in the thread. --- Heikki Linnakangas wrote: While thinking about index-organized-tables and similar ideas, it occurred to me that there's some low-hanging-fruit: maintaining cluster order on inserts by trying to place new heap tuples close to other similar tuples. That involves asking the index am where on the heap the new tuple should go, and trying to insert it there before using the FSM. Using the new fillfactor parameter makes it more likely that there's room on the page. We don't worry about the order within the page. The API I'm thinking of introduces a new optional index am function, amsuggestblock (suggestions for a better name are welcome). It gets the same parameters as aminsert, and returns the heap block number that would be optimal place to put the new tuple. It's be called from ExecInsert before inserting the heap tuple, and the suggestion is passed on to heap_insert and RelationGetBufferForTuple. I wrote a little patch to implement this for btree, attached. This could be optimized by changing the existing aminsert API, because as it is, an insert will have to descend the btree twice. Once in amsuggestblock and then in aminsert. amsuggestblock could keep the right index page pinned so aminsert could locate it quicker. But I wanted to keep this simple for now. Another improvement might be to allow amsuggestblock to return a list of suggestions, but that makes it more expensive to insert if there isn't room in the suggested pages, since heap_insert will have to try them all before giving up. Comments regarding the general idea or the patch? There should probably be a index option to turn the feature on and off. You'll want to turn it off when you first load a table, and turn it on after CLUSTER to keep it clustered. Since there's been discussion on keeping the TODO list more up-to-date, I hereby officially claim the Automatically maintain clustering on a table TODO item :). Feel free to bombard me with requests for status reports. And just to be clear, I'm not trying to sneak this into 8.2 anymore, this is 8.3 stuff. I won't be implementing a background daemon described on the TODO item, since that would essentially be an online version of CLUSTER. Which sure would be nice, but that's a different story. - Heikki [ text/x-patch is unsupported, treating like TEXT/PLAIN ] Index: doc/src/sgml/catalogs.sgml === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/doc/src/sgml/catalogs.sgml,v retrieving revision 2.129 diff -c -r2.129 catalogs.sgml *** doc/src/sgml/catalogs.sgml31 Jul 2006 20:08:55 - 2.129 --- doc/src/sgml/catalogs.sgml8 Aug 2006 16:17:21 - *** *** 499,504 --- 499,511 entryFunction to parse and validate reloptions for an index/entry /row + row + entrystructfieldamsuggestblock/structfield/entry + entrytyperegproc/type/entry + entryliterallink linkend=catalog-pg-procstructnamepg_proc/structname/link.oid/literal/entry + entryGet the best place in the heap to put a new tuple/entry + /row + /tbody /tgroup /table Index: doc/src/sgml/indexam.sgml === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/doc/src/sgml/indexam.sgml,v retrieving revision 2.16 diff -c -r2.16 indexam.sgml *** doc/src/sgml/indexam.sgml 31 Jul 2006 20:08:59 - 2.16 --- doc/src/sgml/indexam.sgml 8 Aug 2006 17:15:25 - *** *** 391,396 --- 391,414 functionamoptions/ to test validity of options settings. /para + para + programlisting + BlockNumber + amsuggestblock (Relation indexRelation, + Datum *values, + bool *isnull, + Relation heapRelation); + /programlisting +Gets the optimal place in the heap for a new tuple. The parameters +correspond the parameters for literalaminsert/literal. +This function is called on the clustered index before a new tuple +is inserted to the heap, and it should choose the optimal insertion +target page on the heap in such manner that the heap stays as close +as possible to the index order. +literalamsuggestblock/literal can return InvalidBlockNumber if +the index am doesn't have a suggestion. + /para + /sect1 sect1 id=index-scanning Index: src/backend/access/heap/heapam.c === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/heap/heapam.c,v retrieving revision 1.218 diff -c -r1.218 heapam.c *** src/backend/access/heap/heapam.c 31 Jul 2006 20:08:59 -
Re: [PATCHES] libpq Win32 Mutex performance patch
Andrew Chernow wrote: Tom Lane wrote: Silently not locking is surely not very safe. Here is the dump code version of the patch. If anyone wants the return value idea, let me know. A more graceful solution would be to print something to stderr and then exit. This allows an app's atexit funcs to run. I don't think libpq should core dump an app by choice. I'd be pretty upset if a library I was using core dumped in some cases rather than exiting. andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
Andrew Chernow [EMAIL PROTECTED] writes: A more graceful solution would be to print something to stderr and then exit. stderr doesn't exist, or point to a useful place, in many environments. And a forced exit() is no better than a crash for most purposes. I don't think libpq should core dump an app by choice. The case that we are talking about is a bug, or would be a bug if it could happen (the fact that we've gotten along happily with no similar test in the existing code shows that it can't). Many forms of bug can result in core dumps; it's foolish to try to prevent them all. And bloating one line of code into five or more lines to defend against can't-happen cases is a good way to end up with unreadable, unmaintainable software. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: A more graceful solution would be to print something to stderr and then exit. stderr doesn't exist, or point to a useful place, in many environments. And a forced exit() is no better than a crash for most purposes. I don't think libpq should core dump an app by choice. The case that we are talking about is a bug, or would be a bug if it could happen (the fact that we've gotten along happily with no similar test in the existing code shows that it can't). Many forms of bug can result in core dumps; it's foolish to try to prevent them all. And bloating one line of code into five or more lines to defend against can't-happen cases is a good way to end up with unreadable, unmaintainable software. regards, tom lane +1 -dg -- David Gould [EMAIL PROTECTED] 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq Win32 Mutex performance patch
daveg wrote: On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: A more graceful solution would be to print something to stderr and then exit. stderr doesn't exist, or point to a useful place, in many environments. And a forced exit() is no better than a crash for most purposes. I don't think libpq should core dump an app by choice. The case that we are talking about is a bug, or would be a bug if it could happen (the fact that we've gotten along happily with no similar test in the existing code shows that it can't). Many forms of bug can result in core dumps; it's foolish to try to prevent them all. And bloating one line of code into five or more lines to defend against can't-happen cases is a good way to end up with unreadable, unmaintainable software. regards, tom lane +1 -dg okay. BTW, my real interest here is the libpq hooks patch requires a lock/unlock for every conn-create, conn-destroy, result-create, result-destroy. Currently, it looks like only the ssl stuff uses mutexes. Adding more mutex use is a good case for a more optimized approach on windows. andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
