Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
On Fri, 3 May 2002, Tom Lane wrote: > But what we must *not* do is allow a new postmaster to start while the > old backends are still running; that would mean two sets of backends > running without contact with each other, which would be fatal for data > integrity. The SysV API lets us detect that case, but I don't see any > equally good way to do it if we are using anonymous shared memory. It's a hack (and has slight security implications), but you could just allow the postgres backends to keep the listening socket(s) open. Matthew. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Auto-reload of dynamic libraries
This small patch reloads dynamic libraries whose modification time is
greater than that at the time it was initially loaded. This means that
connections do not need to be reinitialised when a library is recompiled.
There is a problem with this, however: if dlopen()'ing the new patch
fails, the functions registered in the system against this patch will also
presumably break. This is, of course, what would happened if, a new
connection came in after the library was broken and it attempted to use
any of the functions in it.
Any ideas about ways around this? Need there be? Is this desired
behaviour?
Gavin
*** src/backend/utils/fmgr/dfmgr.c.orig Sat May 4 20:36:59 2002
--- src/backend/utils/fmgr/dfmgr.c Sat May 4 20:40:05 2002
***
*** 33,38
--- 33,39
dev_t device; /* Device file is on */
ino_t inode; /* Inode number of file */
void *handle; /* a handle for pg_dl* functions */
+ time_t mtime; /* modification time of the lib */
charfilename[1];/* Full pathname of file */
/*
***
*** 89,96
strcmp(fullname, file_scanner->filename) != 0;
file_scanner = file_scanner->next)
;
! if (file_scanner == (DynamicFileList *) NULL)
! {
/*
* Check for same files - different paths (ie, symlink or link)
*/
--- 90,118
strcmp(fullname, file_scanner->filename) != 0;
file_scanner = file_scanner->next)
;
! if(file_scanner) {
!
! /*
!* Check to make sure the currently loaded lib the most recently
!* compiled.
!*/
!
! stat(fullname,&stat_buf);
!
! if(stat_buf.st_mtime > file_scanner->mtime) {
!
! pg_dlclose(file_scanner->handle);
! file_scanner->handle = pg_dlopen(fullname);
!
! if (file_scanner->handle == (void *) NULL) {
! load_error = (char *) pg_dlerror();
! free((char *) file_scanner);
! elog(ERROR, "Load of file %s failed: %s", fullname, load_error);
! } else {
! file_scanner->mtime = stat_buf.st_mtime;
! }
! }
! } else if (file_scanner == (DynamicFileList *) NULL) {
/*
* Check for same files - different paths (ie, symlink or link)
*/
***
*** 119,125
file_scanner->device = stat_buf.st_dev;
file_scanner->inode = stat_buf.st_ino;
file_scanner->next = (DynamicFileList *) NULL;
!
file_scanner->handle = pg_dlopen(fullname);
if (file_scanner->handle == (void *) NULL)
{
--- 141,147
file_scanner->device = stat_buf.st_dev;
file_scanner->inode = stat_buf.st_ino;
file_scanner->next = (DynamicFileList *) NULL;
! file_scanner->mtime = stat_buf.st_mtime;
file_scanner->handle = pg_dlopen(fullname);
if (file_scanner->handle == (void *) NULL)
{
---(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: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane > Sent: Friday, May 03, 2002 6:07 PM > To: mlw > Cc: Marc G. Fournier; [EMAIL PROTECTED] > Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports > > > Rather than propagating the SysV semaphore API still further, why don't > we kill it now? (I'm willing to keep the shmem API, however.) Would this have the benefit of allow PostgreSQL to work properly in BSD jails, since lack of really working SysV IPC was the problem there? - J. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Native Windows, Apache Portable Runtime
Upon doing some inspection of apache 2.x, it seems that me making a SysV Windows .DLL for PostgreSQL, while a cool project, would be unnecessary. The APR (Apache Portable Runtime) seems to have all the necessary support. The problem is that it has its own API. We should find a way to extract the APR out of apache and make it a library within PostgreSQL. A quick look at the license seems to indicate this is OK. Should we notify the Apache guys just to be polite? It looks like the APR is pretty analogous to SysV with a few changes, so it should not be too hard to code it into PostgrsSQL. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Using views and MS access via odbc
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > If you'd not like to change the behavior, I would change it, OK ?
>
> To what? I don't want to simply undo the 7.2 change.
What I'm thinking is the following makeshift fix.
I expect it solves Ron's case though I'm not sure.
Returning UPDATE 0 seem to make no one happy.
regards,
Hiroshi Inoue
*** postgres.c.orig Thu Feb 28 08:17:01 2002
--- postgres.c Sat May 4 22:53:03 2002
***
*** 805,811
if (DebugLvl > 1)
elog(DEBUG, "ProcessQuery");
! if (querytree->originalQuery)
{
/* original stmt can override default
tag string */
ProcessQuery(querytree, plan, dest,
completionTag);
--- 805,811
if (DebugLvl > 1)
elog(DEBUG, "ProcessQuery");
! if (querytree->originalQuery ||
length(querytree_list) == 1)
{
/* original stmt can override default
tag string */
ProcessQuery(querytree, plan, dest,
completionTag);
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Native Windows, Apache Portable Runtime
mlw wrote: > > Upon doing some inspection of apache 2.x, it seems that me making a SysV > Windows .DLL for PostgreSQL, while a cool project, would be unnecessary. > > The APR (Apache Portable Runtime) seems to have all the necessary support. The > problem is that it has its own API. > > We should find a way to extract the APR out of apache and make it a library > within PostgreSQL. A quick look at the license seems to indicate this is OK. > Should we notify the Apache guys just to be polite? Definitely. They make also be able to offer some tips and guidance (i.e. there may already be a way of splitting it off easy, etc), but we'll never know if we don't say hello. (Hey, that rhymes!) :-) Regards and best wishes, Justin Clift > It looks like the APR is pretty analogous to SysV with a few changes, so it > should not be too hard to code it into PostgrsSQL. > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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: [HACKERS] Native Windows, Apache Portable Runtime
Justin Clift wrote: > > mlw wrote: > > > > Upon doing some inspection of apache 2.x, it seems that me making a SysV > > Windows .DLL for PostgreSQL, while a cool project, would be unnecessary. > > > > The APR (Apache Portable Runtime) seems to have all the necessary support. The > > problem is that it has its own API. > > > > We should find a way to extract the APR out of apache and make it a library > > within PostgreSQL. A quick look at the license seems to indicate this is OK. > > Should we notify the Apache guys just to be polite? > > Definitely. They make also be able to offer some tips and guidance > (i.e. there may already be a way of splitting it off easy, etc), but > we'll never know if we don't say hello. (Hey, that rhymes!) It is so easy to extract he APR it is silly. They even describe how in the README.dev. Except for NIH, I can't see any reason not to use t. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
"Joel Burton" <[EMAIL PROTECTED]> writes: >> Rather than propagating the SysV semaphore API still further, why don't >> we kill it now? (I'm willing to keep the shmem API, however.) > Would this have the benefit of allow PostgreSQL to work properly in BSD > jails, since lack of really working SysV IPC was the problem there? Was the problem just with semas, or was shmem an issue too? In any case, unless someone actually writes an alternative sema implementation that will work on BSD, nothing will happen... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Using views and MS access via odbc
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > If you'd not like to change the behavior, I would change it, OK ? >> >> To what? I don't want to simply undo the 7.2 change. > What I'm thinking is the following makeshift fix. > I expect it solves Ron's case though I'm not sure. > Returning UPDATE 0 seem to make no one happy. Agreed, that doesn't seem like it's going over well. Let's see, you propose returning the tag if there is only one replacement query, ie, we had just one DO INSTEAD rule. [ thinks... ] I guess the only thing that bothers me about this is the prospect that the returned tag is completely different from what the client expects. For example, consider a rule like ON UPDATE DO INSTEAD INSERT INTO history_table... With your patch, this would return an "INSERT nnn nnn" tag, which'd confuse a client that expects an "UPDATE nnn" response. (This is one of the issues that prompted changing the behavior to begin with.) Would it be reasonable to allow the rewritten query to return a tag only if (a) it's the only query, per your patch AND (b) it's the same query type as the original, unrewritten query? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Auto-reload of dynamic libraries
Gavin Sherry <[EMAIL PROTECTED]> writes: > This small patch reloads dynamic libraries whose modification time is > greater than that at the time it was initially loaded. This means that > connections do not need to be reinitialised when a library is recompiled. Is that a good idea? It's easy to imagine cases where a library is not designed to be unloaded (eg, it hooks into things in the main backend and doesn't have a way to unhook). I'd rather stick with the current behavior of unload/reload only when specifically commanded to. The patch as given fails in the same inode/different path case, btw. I think you wanted to make the test further down. 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: [HACKERS] Native Windows, Apache Portable Runtime
mlw <[EMAIL PROTECTED]> writes: > Upon doing some inspection of apache 2.x, it seems that me making a SysV > Windows .DLL for PostgreSQL, while a cool project, would be unnecessary. > The APR (Apache Portable Runtime) seems to have all the necessary support. Does it? AFAICT they intend to provide mutexes not counting semaphores. Their implementation atop SysV semaphores would work the way we need (ie, remember multiple unlocks arriving before a lock operation), but I'm unclear on whether any of the other ones would. 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: [HACKERS] Native Windows, Apache Portable Runtime
Tom Lane wrote: > > mlw <[EMAIL PROTECTED]> writes: > > Upon doing some inspection of apache 2.x, it seems that me making a SysV > > Windows .DLL for PostgreSQL, while a cool project, would be unnecessary. > > > The APR (Apache Portable Runtime) seems to have all the necessary support. > > Does it? AFAICT they intend to provide mutexes not counting semaphores. > Their implementation atop SysV semaphores would work the way we need > (ie, remember multiple unlocks arriving before a lock operation), but > I'm unclear on whether any of the other ones would. Ok, you got me, they do not provide a semaphore, only mutexes. We should be able to use APR in PostgreSQL, I'll implement a semaphore directory for Windows and UNIX. Someone will have to handle the Netware, beos and OS/2. (I may be able to do the OS/2 stuff, but it has, in fact, been 6 years since I even looked at OS/2 in any form.) We could provide a PGSemaphore based on an APR mutex and a counter, but I'm not sure of the performance impact. We may want to implement a "generic" semaphore like this and one optimized for platforms which we have development resources. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
Matthew Kirkwood <[EMAIL PROTECTED]> writes: > On Fri, 3 May 2002, Tom Lane wrote: >> The SysV API lets us detect that case, but I don't see any >> equally good way to do it if we are using anonymous shared memory. > It's a hack (and has slight security implications), but you > could just allow the postgres backends to keep the listening > socket(s) open. Hmm. That might be workable, but it feels shaky to me. The problem is that you are using a lock based on port number to interlock a data directory --- and port number and data directory are independently variable parameters. Consider $ postmaster -D /my/dir & -- dba thinks "oops, forgot to specify port" $ kill -9 pm-pid # bad idea $ postmaster -D /my/dir -p myport & Any backends started by the first postmaster will not be noticed by the second one, if the interlock is based on port number. We could get around this, of course: record the port number in the data directory lockfile, and test for existence of the old socket independently of trying to create a new one. But it seems ugly. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Native Windows, Apache Portable Runtime
mlw <[EMAIL PROTECTED]> writes:
> We could provide a PGSemaphore based on an APR mutex and a counter,
> but I'm not sure of the performance impact. We may want to implement a
> "generic" semaphore like this and one optimized for platforms which we
> have development resources.
Once we have the internal API redone, it should be fairly easy to
experiment with alternatives like that.
I'm planning to work on this today (need a break from thinking about
schemas ;-)). I'll run with the API I sketched yesterday, since no one
objected. Although I'm not planning on doing anything to the API of the
shared-mem routines, I'll break them out into a replaceable file as
well, just in case anyone wants to try a non-SysV implementation.
What I plan to do is:
1. Replace include/storage/ipc.h with "pg_sema.h" and "pg_shmem.h"
containing the hopefully-platform-independent API definitions, plus
ifdef'd sections along the lines of
#ifdef USE_SYSV_SEMAPHORES
typedef struct PGSemaphoreData {
int id;
int num;
} PGSemaphoreData;
typedef PGSemaphoreData *PGSemaphore;
#endif
AFAICS at the moment, only this typedef needs to vary across different
implementations as far as the header is concerned.
2. Break out the SysV-dependent code into backend/port/sysv_sema.c
and backend/port/sysv_shmem.c. storage/ipc/ipc.c will either go away
completely or get lots smaller.
3. Extend configure to define the correct USE_foo_SEMAPHORES symbol
in pg_config.h, and to symlink the correct implementation files to
backend/port/pg_sema.c and backend/port/pg_shmem.c. These two "files"
will be the ones compiled and linked into the backend.
I'm expecting that configure will default to use SysV semas and shared
memory unless told differently by the "template" script selected for
the platform. For instance src/template/darwin might contain something
like
USE_DARWIN_SEMAPHORES=1
SEMA_IMPLEMENTATION=src/backend/port/darwin/sem.c
to override the default semaphore implementation. Later we might want
some more-dynamic way of configuring the sema type, but this seems like
enough to get started.
Comments, better ideas?
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Using views and MS access via odbc
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > > If you'd not like to change the behavior, I would change it, OK ? > >> > >> To what? I don't want to simply undo the 7.2 change. > > > What I'm thinking is the following makeshift fix. > > I expect it solves Ron's case though I'm not sure. > > Returning UPDATE 0 seem to make no one happy. > > Agreed, that doesn't seem like it's going over well. Let's see, you > propose returning the tag if there is only one replacement query, ie, > we had just one DO INSTEAD rule. [ thinks... ] I guess the only thing > that bothers me about this is the prospect that the returned tag is > completely different from what the client expects. For example, > consider a rule like ON UPDATE DO INSTEAD INSERT INTO history_table... > With your patch, this would return an "INSERT nnn nnn" tag, which'd > confuse a client that expects an "UPDATE nnn" response. Is it worse than returning "UPDATE 0" ? Unfortunately "UPDATE 0" never means the result is unknown but clearly means no rows were affected. It can never be safe to return "UPDATE 0". regards, Hiroshi Inoue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
I have just committed changes to create a platform-independent internal API for semaphores, along the lines discussed yesterday. At this point, the Darwin (Mac OS X), BeOS, and QNX4 ports are probably broken. I will fix the Darwin port (probably not till tomorrow though); volunteers to clean up the BeOS and QNX4 ports are needed. BTW, there is a quick hack attempt at a POSIX-semaphore-based implementation in src/backend/port/posix_sema.c. I have not tested this yet, but expect to do so as part of fixing the Darwin port. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
> "Joel Burton" <[EMAIL PROTECTED]> writes: > >> Rather than propagating the SysV semaphore API still further, why don't > >> we kill it now? (I'm willing to keep the shmem API, however.) > > > Would this have the benefit of allow PostgreSQL to work properly in BSD > > jails, since lack of really working SysV IPC was the problem there? > > Was the problem just with semas, or was shmem an issue too? Not sure -- doesn't get far enough for me to tell. initdb dies with: creating template1 database in /usr/local/pgsql/data/base/1... IpcSemaphoreCreate: semget(key=1, num=17, 03600) failed: Function not implemented > In any case, unless someone actually writes an alternative sema > implementation that will work on BSD, nothing will happen... Was hoping that the discussions about the APR might let this work under BSD jails, assuming I can get the APR to compile. (For others: apparently PG will work under BSD jails if you recompile the BSD kernel w/some new settings, but my ISP for this project was unwilling to do that. Search the mailing list for messages on how to do this.) J. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
