Re: [PATCHES] fork/exec patch: pre-CreateProcess finalization
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Claudio Natoli wrote: > > [patch edited + resubmitted for review; not for committing] > > Hi Tom, > > figuring that, on balance, you are in fact going to prefer to take a > potential future hit in duplicated work (in passing context in the fork/exec > case) over moving the client auth code to PostgresMain, I've just gone ahead > and made a patch that implements your BackendFork ideas... > > Please let me know: > > * if the changes to the BackendFork / SubPostmasterMain logic are more or > less what you envisaged, and if you are content with them [Note: we can also > roll BackendInit back into BackendFork, making BackendFork (now BackendRun?) > pretty much exactly as it was before the fork/exec changes began] > > * if you are content with the above, whether or not you think I ought to do > the same for the SSDataBase logic. I'm hoping for a negative, as the #ifdef > logic is not as convoluted as that originally presented in BackendFork (ie. > to me, it looks like overkill in this case), but anticipating otherwise :-) > > Also: > * are you ok with the pgstat changes (I'm guessing yes, as you haven't > mentioned them, and since these changes are pretty similar to what you > suggested for BackendFork) > > Cheers, > Claudio > > > > > > > --- > Certain disclaimers and policies apply to all email sent from Memetrics. > For the full text of these disclaimers and policies see > href="http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em > ailpolicy.html > > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pg_usleep
> patch + new file attached. Haven't tested on Windows, but > should be fine. Would be, except for a small typo (conditional operator has an additional : instead of a ?). Also, we might want to change to SleepEx, depending on how we eventually get signals implemented, but that's a story for another day. This, + the pipe() patch from a couple days ago, means we can just about tick off the "Problems with select()" item on the Win32 TODO list :-) Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Solaris thread patch
I have confirmed that Solaris needs the "-mt" link flag when building threaded apps using non-gcc compilers, so I am adding it to the template file for Solaris. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/template/solaris === RCS file: /cvsroot/pgsql-server/src/template/solaris,v retrieving revision 1.9 diff -c -c -r1.9 solaris *** src/template/solaris23 Dec 2003 18:40:53 - 1.9 --- src/template/solaris30 Dec 2003 22:31:30 - *** *** 12,14 --- 12,18 THREAD_SUPPORT=yes NEED_REENTRANT_FUNCS=yes # 5.6 2003-09-13 THREAD_LIBS="-pthread" + if test "$GCC" != yes + then THREAD_LIBS="-mt $THREAD_LIBS" + fi + ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] pg_usleep
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I wrote:
There are a couple of other places where [select()] is used for small
sleeps (storage/lmgr/s_lock.c and access/transam/xact.c) -
What is the preferred way to handle these 2 cases? We could handle them
with #ifdef'd code inline, or create a new function pg_usleep(), or
possibly handle it with conditional macros inline. If a new function or
macro, where should they go?
I'd go with a new function. There is no reason to try to "optimize"
this code by putting it inline; if you're trying to delay, another few
nanoseconds to enter a subroutine doesn't matter.
As for where, maybe make a new file in src/port/. That would make it
relatively easy to use the same function in client-side code if we
needed to.
patch + new file attached. Haven't tested on Windows, but should be fine.
cheers
andrew
/*-
*
* pg_usleep.c
*platform independent version of usleep
*
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
*
* Uses select() everywhere except for Windows, where it doesn't work
*
* IDENTIFICATION
*$PostgreSQL$
*
*-
*/
#include "postgres.h"
#ifdef WIN32
#include
#else
#include
#include
#endif
void
pg_usleep (unsigned int usecs)
{
#ifdef WIN32
Sleep(usecs < 500 : 1 : (usecs+500)/ 1000);
#else
struct timeval tv;
tv.tv_sec = usecs / 100;
tv.tv_usec = usecs % 100;
select(0,NULL,NULL,NULL,&tv);
#endif
}
Index: src/Makefile.global.in
===
RCS file: /projects/cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.172
diff -c -w -r1.172 Makefile.global.in
*** src/Makefile.global.in 19 Dec 2003 23:29:15 - 1.172
--- src/Makefile.global.in 30 Dec 2003 18:50:56 -
***
*** 342,348
#
# substitute implementations of the C library
! LIBOBJS = @LIBOBJS@ path.o sprompt.o thread.o
ifneq (,$(LIBOBJS))
LIBS += -lpgport
--- 342,348
#
# substitute implementations of the C library
! LIBOBJS = @LIBOBJS@ path.o sprompt.o thread.o pg_usleep.o
ifneq (,$(LIBOBJS))
LIBS += -lpgport
Index: src/backend/access/transam/xact.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.158
diff -c -w -r1.158 xact.c
*** src/backend/access/transam/xact.c 2 Dec 2003 19:26:47 - 1.158
--- src/backend/access/transam/xact.c 30 Dec 2003 18:50:56 -
***
*** 562,572
if (CommitDelay > 0 && enableFsync &&
CountActiveBackends() >= CommitSiblings)
{
! struct timeval delay;
!
! delay.tv_sec = 0;
! delay.tv_usec = CommitDelay;
! (void) select(0, NULL, NULL, NULL, &delay);
}
XLogFlush(recptr);
--- 562,569
if (CommitDelay > 0 && enableFsync &&
CountActiveBackends() >= CommitSiblings)
{
! /* call platform independent usleep */
! pg_usleep(CommitDelay);
}
XLogFlush(recptr);
Index: src/backend/storage/lmgr/s_lock.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/lmgr/s_lock.c,v
retrieving revision 1.23
diff -c -w -r1.23 s_lock.c
*** src/backend/storage/lmgr/s_lock.c 27 Dec 2003 20:58:58 - 1.23
--- src/backend/storage/lmgr/s_lock.c 30 Dec 2003 18:50:56 -
***
*** 46,52
s_lock(volatile slock_t *lock, const char *file, int line)
{
/*
!* We loop tightly for awhile, then delay using select() and try
* again. Preferably, "awhile" should be a small multiple of the
* maximum time we expect a spinlock to be held. 100 iterations seems
* about right. In most multi-CPU scenarios, the spinlock is probably
--- 46,52
s_lock(volatile slock_t *lock, const char *file, int line)
{
/*
!* We loop tightly for awhile, then delay using pg_usleep() and try
* again. Preferably, "awhile" should be a small multiple of the
* maximum time we expect a spinlock to be held. 100 iterations seems
* about right. In most multi-CPU scenarios, the spinlock is probably
***
*** 84,90
int spins = 0;
int delays = 0;
int cur_delay = M
