Re: [PATCHES] Improve shutdown during online backup, take 4
Tom Lane wrote: I've attached a patch that works for me. I hope I got it right. Applied with additional cleanup. You hadn't thought very carefully about additional state transitions that would have to be introduced into the postmaster state machine to support a new state --- for example, as coded a SIGINT delivered to the postmaster after SIGTERM would fail to do anything at all, when of course it really ought to force us into fast shutdown. Also, it's not really that hard to disallow non-superusers from connecting in PM_WAIT_BACKUP state. Thank you for helping. You know, this is my first patch for server code. I know that I still have a lot to learn until I grok how all that works together. Yours, Laurenz Albe -- 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] Improve shutdown during online backup, take 4
Tom Lane wrote: Why? That seems like an entirely arbitrary specification. My resoning is that I think of smart/fast/immediate shutdown as three different things. For an immediate shutdown/crash thought it was best not to modify anything to facilitate an analysis of the problem. A fast shutdown that fails will end up as a crash or immediate shutdown. If you think that is is not important to only cancel backup mode if we are sure that the shutdown will be clean, we might as well also cancel online backup mode during an immediate shutdown. In that case, I'd agree that the call to CancelBackup() could be moved to WAIT_BACKUP (and executed only if it is no smart shutdown). It would have the advantage of having all backup mode related code in postmaster.c concentrated in one spot. Make a suggestion, and I'll implement it that way. Yours, Laurenz Albe -- 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] Improve shutdown during online backup, take 4
Tom Lane wrote: I concur that the messages added to pg_ctl are bizarrely formatted. Why would you put a newline in the middle of a sentence, when you could equally well emit something like WARNING: online backup mode is active. Shutdown will not complete until pg_stop_backup() is called. While we're on the subject, the messages added to xlog.c do not follow the style guidelines: in particular, errdetail should be a complete sentence, and the WARNING is trying to stuff independent thoughts into one message. I'd probably do errmsg(online backup mode cancelled), errdetail(\%s\ was renamed to \%s\., ... errmsg(online backup mode was not cancelled), errdetail(Failed to rename \%s\ to \%s\: %m, ... Attached is a patch that changes the messages along these lines. Thanks! Lastly, the changes to pmdie's SIGINT handling seem quite bogus. Don't you need to transition into WAIT_BACKUP rather than WAIT_BACKENDS state in that case too? Shouldn't you do CancelBackup *before* PostmasterStateMachine? The thing screams of race conditions. I suspect there must be a misunderstanding. You cannot really mean that the postmaster should enter WAIT_BACKUP state on a fast shutdown request. Sure, CancelBackup could be called earlier. It doesn't do much more than rename a file. My reason for calling it late was that backup mode should really only be cancelled if we manage to shutdown cleanly, and this is not clear until the last child is gone. I cannot see a race condition, except maybe the quite unlikely case that two instances of CancelBackup might run concurrently, and it *might* happen that one of them finds that backup_label is present but fails to remove it, because the other one already did. That would lead to a bogus backup mode not canceled message. Are you referring to that or is there something more fundamental I fail to see? Yours, Laurenz Albe backup-shut.msg.patch Description: backup-shut.msg.patch -- 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] Improve shutdown during online backup, take 4
Tom Lane wrote: Lastly, the changes to pmdie's SIGINT handling seem quite bogus. Don't you need to transition into WAIT_BACKUP rather than WAIT_BACKENDS state in that case too? Shouldn't you do CancelBackup *before* PostmasterStateMachine? The thing screams of race conditions. I suspect there must be a misunderstanding. You cannot really mean that the postmaster should enter WAIT_BACKUP state on a fast shutdown request. Why not? It'll fall out of the state again immediately in PostmasterStateMachine, no, if we do a CancelBackup here? I don't think these two paths of control should be any more different than really necessary. We cannot call CancelBackup there because that's exactly the state in which a smart shutdown waits for a superuser to issue pg_stop_backup(). Well, if there were anything conditional about calling it, then maybe that argument would hold some water, but the way you've got it here it *will* get called anyway, just after the PostmasterStateMachine call [...] I see. The other reason for the remark about race conditions is that the PostmasterStateMachine call should absolutely be the last thing that pmdie() does --- putting anything after it is wrong, especially things that might alter the PM state, as indeed CancelBackup could. I see that too. Thanks for explaining. If you actually want the behavior you propose, then the only correct way to implement it is to embed it into the state machine logic, ie, do the CancelBackup inside PostmasterStateMachine in some state transition taken after the last child is gone. I've attached a patch that works for me. I hope I got it right. Yours, Laurenz Albe cancel_backup.patch Description: cancel_backup.patch -- 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] Improve shutdown during online backup, take 3
Magnus Hagander wrote: This doesn't look like our normal coding standards, and should probably be changed: + if (0 != stat(BACKUP_LABEL_FILE, stat_buf)) (there's a number of similar places) Lacking guidelines, I now tried to copy how stat(2) is used in other parts of the code. Yours, Laurenz Albe backup-shut.doc.patch Description: backup-shut.doc.patch backup-shut.patch Description: backup-shut.patch -- 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] Improve shutdown during online backup, take 4
Alvaro Herrera wrote: I think the messages should not have a newline in the middle. Also, I am wondering if in PM_WAIT_BACKUP mode we should accept new connections from superusers only. I spent some thought on that. You'd need to wait until the user is authenticated before you can determine if he/she is a superuser and may connect (otherwise I think it would be a security leak that enables any attacker to find out whether a given user is a superuser without knowing the password). By that time the server process is already forked. I couldn't see a way to check the postmaster state at that point, so I decided not to try and keep it simple. If you have any ideas how I could do such a check reasonably, I'd be happy to try it, because basically I think it would be the right thing. Yours, Laurenz Albe -- 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] Improve shutdown during online backup, take 3
Simon Riggs wrote: Patch applies, and works as described. Looks good for final apply. Few minor thoughts: * Text in pg_ctl should be WARNING, not Warning. * CancelBackup() API looks strange, not sure why * Need to mention that CancelBackup() is not the right way to end a backup, so that function and pg_stop_backup should reference each other Other than those, I like it. Very useful patch. Thanks for the feedback! - I have replaced Warning with WARNING. - I have changed the API of CancelBackup() to return void. I don't use the return code anyway, and I guess it's less confusing and strange that way. - I have added comments to disambiguate pg_stop_backup() and CancelBackup(). CancelBackup now writes a message to the server log if it cannot delete backup_label - I hope that's not too verbose... Yours, Laurenz Albe backup-shut.patch Description: backup-shut.patch backup-shut.doc.patch Description: backup-shut.doc.patch -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Improve shutdown during online backup, take 2
This patch replaces the previous version http://archives.postgresql.org/pgsql-patches/2008-04/msg4.php As suggested by Simon Riggs in http://archives.postgresql.org/pgsql-patches/2008-04/msg00013.php , a smart shutdown will now wait for online backup mode to finish. The functions that touch backup_label have been moved to xlog.c. As suggested by Heikki Linnakangas in http://archives.postgresql.org/pgsql-patches/2008-04/msg00180.php , I have introduced a new postmaster state PM_WAIT_BACKUP. In this state the postmaster will still accept connections. Thanks for the feedback! I'll try to add a link at the Wiki page. Yours, Laurenz Albe backup-shut.doc.patch Description: backup-shut.doc.patch backup-shut.patch Description: backup-shut.patch -- 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] Improve shutdown during online backup
[what should happen if a smart shutdown request is received during online backup mode? I'll cc: the hackers list, maybe others have something to say to this] Heikki Linnakangas wrote: Albe Laurenz wrote: Moreover, if Shutdown == SmartShutdown, new connections won't be accepted, and nobody can connect and call pg_stop_backup(). So even if I'd add a check for (pmState == PM_WAIT_BACKENDS) !BackupInProgress() somewhere in the ServerLoop(), it wouldn't do much good, because the only way for somebody to cancel online backup mode would be to manually remove the file. Good point. So the only reasonable thing to do on smart shutdown during an online backup is to have the shutdown request fail, right? The only alternative being that a smart shutdown request should interrupt online backup mode. Or we can add another state, PM_WAIT_BACKUP, before PM_WAIT_BACKENDS, that allows new connections, and waits until the backup ends. That's an option. Maybe it is possible to restrict connections to superusers (who are the only ones who can call pg_stop_backup() anyway). Or, we could allow superuser connections in state PM_WAIT_BACKENDS... Opinions? Yours, Laurenz Albe -- 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] Improve shutdown during online backup
Simon Riggs wrote:
Few comments:
* smart shutdown waits for sessions to complete, yet this just ignores
smart shutdowns which is something a little different. I think we
should wait for the backup to complete and then shutdown.
If we add a function called something like BackupInProgress() to xlog.c,
exported via miscadmin.h then we can use it within the
PostmasterStateMachine() function like this
if (pmState == PM_WAIT_BACKENDS)
{
if (CountChildren() == 0
StartupPID == 0
(BgWriterPID == 0 || !FatalError)
WalWriterPID == 0
AutoVacPID == 0
!BackupInProgress()) new line
so that the postmaster doesn't need to know about how we do backups.
That way you don't need any of the special cases in your patch, nor is
there any need to duplicate the #defines.
I looked at that, and it won't work, for these reasons:
PostmasterStateMachine() is called once after a smart shutdown.
If there are children or a backup is in progress, pmState will remain
PM_WAIT_BACKENDS.
Now whenever a child exits, the reaper() will be called, which in turn
calls PostmasterStateMachine() again and advances pmState if appropriate.
This won't work for backups though, because removal of backup_label will
not send a SIGCHLD to the postmaster.
Moreover, if Shutdown == SmartShutdown, new connections won't be accepted,
and nobody can connect and call pg_stop_backup().
So even if I'd add a check for
(pmState == PM_WAIT_BACKENDS) !BackupInProgress() somewhere in the
ServerLoop(), it wouldn't do much good, because the only way for somebody
to cancel online backup mode would be to manually remove the file.
So the only reasonable thing to do on smart shutdown during an online
backup is to have the shutdown request fail, right? The only alternative being
that a smart shutdown request should interrupt online backup mode.
So - unless you point out a flaw in my reasoning - I'll implement it
that way, but will put all code that handles backup_label files into
xlog.c.
Yours,
Laurenz Albe
--
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] Improve shutdown during online backup
Simon Riggs wrote:
Few comments:
* smart shutdown waits for sessions to complete, yet this just ignores
smart shutdowns which is something a little different. I think we
should wait for the backup to complete and then shutdown.
That would be more consistent, I agree.
I'll undo my changes to pg_ctl as well, as they make no more sense then.
* The #defines at top of postmaster.c are duplicated from xlog.c
If we can't agree on a common header file then we should at least add a
comment to mention they are duplicated (in both locations).
If we add a function called something like BackupInProgress()
to xlog.c,
exported via miscadmin.h then we can use it within the
PostmasterStateMachine() function like this
if (pmState == PM_WAIT_BACKENDS)
{
if (CountChildren() == 0
StartupPID == 0
(BgWriterPID == 0 || !FatalError)
WalWriterPID == 0
AutoVacPID == 0
!BackupInProgress()) new line
so that the postmaster doesn't need to know about how we do backups.
That way you don't need any of the special cases in your patch, nor is
there any need to duplicate the #defines.
I realized that duplicating the #defines was ugly, and will do it
like that.
Thanks for the hints.
Yours,
Laurenz Albe
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Improve shutdown during online backup
This follows up on the discussion in http://archives.postgresql.org/pgsql-hackers/2008-03/msg01033.php - pg_ctl will refuse a smart shutdown during online backup. - The postmaster will also refuse to shutdown in smart mode in that case and log a message to that effect. - In fast shutdown mode, the server will rename backup_label after successfully shutting down and log the fact. Yours, Laurenz Albe backup-shut.doc.patch Description: backup-shut.doc.patch backup-shut.patch Description: backup-shut.patch -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] documentation patch for LDAP service lookup
Since nobody seemed to have objections to http://archives.postgresql.org/pgsql-hackers/2007-08/msg00960.php I submit a patch that adds reference to LDAP connection parameter lookup in two places: - one line in the psql man page after the example that uses a service parameter to establish a connection. - one line in the comments of pg_service.conf.sample I have also added a short paragraph to the libpq-ldap section that gives an example of a pg_service.conf entry with LDAP URL. Yours, Laurenz Albe ldap-doc.patch Description: ldap-doc.patch ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] pg_dumpall default database
Dave Page wrote: I agree with Peter: specifying the database name as implemented seems like it would be prone to confusion. OK, updated patch attached. This has -E dbname or --default-database=dbname Ouch. This calls for confusion with the -E flag of pg_dump, which means 'encoding'. Something else might be better. It would be nice to be able to specify the encoding for pg_dumpall, though, rather than having to set PG_CLIENTENCODING. Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Dynamic linking on AIX
This is a second try; this patch replaces http://archives.postgresql.org/pgsql-patches/2006-09/msg00185.php Incorporated are - Tom Lane's suggestions for a more sane approach at fixing Makefile.shlib - Rocco Altier's additions to make the regression test run by setting LIBPATH appropriately. - Two changes in /src/interfaces/ecpg/test/Makefile.regress and src/interfaces/ecpg/test/compat_informix/Makefile without which 'make' fails if configure was called with --disable-shared (this is not AIX-specific). The line in src/makefiles/Makefile.aix where I set 'libpath' also seems pretty ugly to me. Do you have a better idea? Basically I need to convert LDFLAGS like: -L../../dir -L /extra/lib -lalib -Wl,yxz -L/more/libs to :/extra/lib:/more/libs and couldn't think of a better way to do it. It will fail if there is a -L path that contains a blank :^( Yours, Laurenz Albe aixlink2.patch Description: aixlink2.patch ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Dynamic linking on AIX
I still would like to see a paragraph describing how AIX is different from other platforms and what we are doing here. Ok, I'll try to sum it up: Shared libraries in AIX are different from shared libraries in Linux. A shared library on AIX is an 'ar' archive containing shared objects. A shared object is produced by the linker when invoked appropriately (e.g. with -G), it is what we call a shared library on Linux. - On AIX, you can do a static as well as a dynamic - link against a shared library, it depends on how you - invoke the linker. When you link statically, the shared objects from the library are added to your executable as required; when you link dynamically, only references to the shared objects are included in the executable. Consequently you do not need a separate static library on AIX if you have a dynamic library. However, you CAN have static libraries (ar archives containing *.o files), and the linker will link against them. This will of course always be a static link. When the AIX linker searches for libraries to link, it will look for a library libxy.a as well as for a single shared object libxy.so when you tell it to -lyx. When it finds both in the same directory, it will prefer libpq.a unless invoked with -brtl. This is where the problem occurs: By default, PostgreSQL will (in the Linux way) create a shared object libpq.so and a static library libpq.a in the same directory. Up to now, since the linker was invoked without the -brtl flag, linking on AIX was always static, as the linker preferred libpq.a over libpq.so. We could have solved the problem by linking with -brtl on AIX, but we chose to go a more AIX-conforming way so that third party programs linking against PostgreSQL libraries will not be fooled into linking statically by default. The 'new way' on AIX is: - Create libxy.so.n as before from the static library libxy.a with the linker. - Remove libxy.a - Recreate libxy.a as a dynamic library with ar -cr libxy.a libxy.so.n - Only install libxy.a, do not install libxy.so Since linking is dynamic on AIX now, we have a new problem: We must make sure that the executable finds its library even if the library is not installed in one of the standard library paths (/usr/lib or /lib). On Linux this is done with an RPATH, on AIX the equivalent is LIBPATH that can be specified at link time with -blibpath:colon separated path . If you do not specify the LIBPATH, it is automatically computed from the -L arguments given to the linker. The LIBPATH, when set, must contain ALL directories where shared libraries should be searched, including the standard library directories. Makefile.aix has been changed to link executables with a LIBPATH that contains --libdir when PostgreSQL is configured with --enable-rpath (the default). The AIX equivalent for the Linux environment variable LD_LIBRARY_PATH is LIBPATH. The regression tests rely on LD_LIBRARY_PATH and have to be changed to set LIBPATH as well. I hope that's good enough, Laurenz Albe ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Dynamic linking on AIX
This patch fixes linking on AIX. Relevant threads on psql-hackers: http://archives.postgresql.org/pgsql-hackers/2006-09/msg01020.php http://archives.postgresql.org/pgsql-hackers/2006-09/msg01084.php http://archives.postgresql.org/pgsql-hackers/2006-09/msg01109.php Up to now, the default on AIX was to link statically. This was not intended; it's just that AIX has different ideas about shared libraries than Linux and nobody cared. --enable-rpath was matched to the AIX equivalent. I tested the patch on AIX 5.3 with gcc; it should also work with IBM's cc. The patch is backward compatible until AIX 4.3 at least, and I added a kludge to Makefile.shlib so that it should also build something operational on AIX 3.2.5. The change to src/interfaces/ecpg/test/Makefile.regress is not actually part of the patch, but without it building fails if you configure --with-ldap --disable-shared I tested building with --disable-shared and --enable-shared (with --enable-rpath and --disable-rpath). Yours, Laurenz Albe aixlink.patch Description: aixlink.patch ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Here is a new patch that replaces the previous one; it adds two macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend, respectively. I did not only add them to the Makefile for interfaces/libpq, but also everywhere something is linked against libpq in case somebody links static. Applied, but without that last part. It builds OK for me on Darwin, which is moderately picky about that sort of thing, but someone should try AIX. I'll do that today. Laurenz Albe ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Tom Lane wrote: Here is a new patch that replaces the previous one; it adds two macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend, respectively. I did not only add them to the Makefile for interfaces/libpq, but also everywhere something is linked against libpq in case somebody links static. Applied, but without that last part. It builds OK for me on Darwin, which is moderately picky about that sort of thing, but someone should try AIX. It builds fine on AIX 5.3 as long as you tell it to link with libpq.so. Static builds against libpq.a will fail. Should -lldap or -lldap_r be added to pg_config --libs? If yes, which of them? Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Tom Lane wrote: I have realized that my modifications in configure.in and src/interfaces/libpq/Makefile to link libpq against OpenLDAP are buggy. Here is a proposed patch to fix it. [...] # The backend doesn't need everything that's in LIBS, however ! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses -lldap_r $(PTHREAD_LIBS), $(LIBS)) This seems pretty risky. What if PTHREAD_LIBS contains -L switches? They'd get removed even if needed for other libraries. It would probably be safer not to put LDAP into LIBS at all, but invent two new macros for configure to set, say LDAP_LIBS and LDAP_LIBS_R, and add these to the link lines in the backend and libpq respectively. Here is a new patch that replaces the previous one; it adds two macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend, respectively. I did not only add them to the Makefile for interfaces/libpq, but also everywhere something is linked against libpq in case somebody links static. I don't know if that's necessary, or if static builds are supported - if not, the changes to those Makefiles should perhaps not be applied. Tested on Linux, AIX and Windows. Yours, Laurenz Albe ldaplink2.patch Description: ldaplink2.patch ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Fix linking of OpenLDAP libraries
Tom Lane wrote on September 04, 2006: Albe Laurenz [EMAIL PROTECTED] writes: # The backend doesn't need everything that's in LIBS, however ! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses -lldap_r $(PTHREAD_LIBS), $(LIBS)) This seems pretty risky. What if PTHREAD_LIBS contains -L switches? They'd get removed even if needed for other libraries. It would probably be safer not to put LDAP into LIBS at all, but invent two new macros for configure to set, say LDAP_LIBS and LDAP_LIBS_R, and add these to the link lines in the backend and libpq respectively. That seems like a good idea. I'll try to work it out and resubmit the fix. Yours, Laurenz Albe ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Documentation fix for --with-ldap
This is just a 'one line' change in the documentation of the --with-ldap flag of ./configure Yours, Laurenz Albe ldapdoc.patch Description: ldapdoc.patch ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Fix linking of OpenLDAP libraries
I have realized that my modifications in configure.in and src/interfaces/libpq/Makefile to link libpq against OpenLDAP are buggy. Here is a proposed patch to fix it. I write this to pgsql-hackers too because I want to share the difficulty I'm facing - maybe somebody has a better idea. To handle thread safety, OpenLDAP comes with a second library libldap_r. The thread safe API is identical to the normal API, the difference is that you must link against libldap_r instead of libldap to get thead safety. These are my problems: - While libpq should be thread safe when ./configured with --enable_thread_safety, the backend should be linked against the normal libldap. - At least on RedHat Linux, you need to link against the pthread library too if you want to link against libldap_r, because the latter has unresolved dependencies. My solution: - If thread safety is not desired, I link against libldap. No problem. - If thread safety is desired, I first try to link against libldap_r without the thread libraries, and only if that fails add the thread libraries to LIBS. - I tweak src/backend/Makefile so that it strips libldap_r and the thread libs from LIBS and replace it with libldap if necessary. That means that if --enable_thread_safety and --with-ldap is both specified, all executables except 'postgres' will be linked against libldap_r (and the thread libs, if necessary). I tested my patch on RedHat Enterprise Linux 3 and AIX 5.3. The behaviour for Windows (use the native WLDAP32.DLL) is unchanged. Yours, Laurenz Albe ldaplink.patch Description: ldaplink.patch ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Forcing current WAL file to be archived
Simon Riggs wrote: Patch included to implement xlog switching, using an xlog record processing instruction and forcibly moving xlog pointers. 1. Happens automatically on pg_stop_backup() Oh - so it will not be possible to do an online backup _without_ forcing a WAL switch any more? Laurenz Albe ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Forcing current WAL file to be archived
Tim Allen wrote: Patch included to implement xlog switching, using an xlog record processing instruction and forcibly moving xlog pointers. 1. Happens automatically on pg_stop_backup() Oh - so it will not be possible to do an online backup _without_ forcing a WAL switch any more? Well, previously, you would have always had to simulate a wal switch, by working out which is the current wal file and copying that. Otherwise your online backup wouldn't be complete. What Simon is describing sounds like a big step forward from that situation. It should let me delete half the code in my pitr backup/failover scripts. Definitely a Good Thing. Certainly a Good Thing, and it should be on by default. But couldn't there be situations where you'd like to do an online backup without a WAL switch? To avoid generating an archive WAL every day on a database with few changes, e.g.? Maybe not, I'm just wondering. Laurenz Albe ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] LDAP lookup of connection parameters
Bruce Momjian wrote: Albe Laurenz wrote: This patch for libpq allows you to enter an LDAP URL in pg_service.conf. The URL will be queried and the resulting string(s) parsed for keyword = value connection options. I have heavily modified your patch to be clearer. Please review the attached version and test it to make sure it still works properly. Thanks. Most of your modifications are fine, but a quick look tells me that your modifications in the parsing of the LDAP URL have been too invasive, e.g.: - you look for the port number in the 'dn' and not in the 'hostname' - you check the validity of 'scopestr' and 'attrs[0]' before it is '\0'-terminated Would you prefer that I try to fix your fixes (and stick with your coding style) or do you want another go? Yours, Laurenz Albe ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] LDAP lookup of connection parameters
This patch for libpq allows you to enter an LDAP URL in pg_service.conf. The URL will be queried and the resulting string(s) parsed for keyword = value connection options. The idea is to have connection information stored centrally on an LDAP server rather than on the client machine. I forgot to mention that there was a brief discussion about this on Hackers: http://archives.postgresql.org/pgsql-hackers/2006-02/msg00828.php My implementation follows the idea from http://archives.postgresql.org/pgsql-hackers/2006-02/msg01198.php I thought it would be good to have some real code as a basis for further discussion whether this is a desirable feature or not. I felt somewhat encouraged because PostgreSQL already has a dependency on OpenLDAP since http://archives.postgresql.org/pgsql-patches/2005-12/msg00375.php and I do not have to introduce a new dependency. Yours, Laurenz Albe ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] LDAP lookup of connection parameters
This patch for libpq allows you to enter an LDAP URL in pg_service.conf. The URL will be queried and the resulting string(s) parsed for keyword = value connection options. The idea is to have connection information stored centrally on an LDAP server rather than on the client machine. I forgot to mention that there was a discussion on Hackers about this: http://archives.postgresql.org/pgsql-hackers/2006-02/msg01182.php I have implemented a solution following the idea of http://archives.postgresql.org/pgsql-hackers/2006-02/msg01198.php because I thought that it was better to have something existing to talk about. Yours, Laurenz Albe ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] LDAP lookup of connection parameters
This patch for libpq allows you to enter an LDAP URL in pg_service.conf. The URL will be queried and the resulting string(s) parsed for keyword = value connection options. The idea is to have connection information stored centrally on an LDAP server rather than on the client machine. On Windows the native library wldap32.dll is used, else OpenLDAP. If --enable_thread_safety has been given, -lldap_r is appended to PTHREAD_LIBS so that libpq will be linked against the tread safe library. There should probably also be a documentation patch for the --with-ldap option of ./configure, but I didn't write it because it also belongs to the LDAP Auth patch. I have added German translations for the new messages - how can I get translations into other languages? Yours, Laurenz Albe ldap_service.patch Description: ldap_service.patch ldap_service_doc.patch Description: ldap_service_doc.patch ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] LDAP auth
Was there ever a decision in the libcurl thread? No, not yet. Personally I'm unconvinced that we should depend on libcurl: if it's going to use openldap to do LDAP work, then the only good reason to use libcurl rather than openldap directly is if there's some clear use-case for libcurl's other features. Which no one had presented AFAIR. I'm still willing to be convinced though. I'm almost done with implementing a patch that recognizes LDAP URLs in pg_services.conf and queries an LDAP server for a connection option string. Currently I'm coding against libldap, and I intend to submit the patch that way. If there are loud calls for another library, I think I could adapt the code without much hassle. The only other protocol I can think of that might make sense is HTTP, but I personally have never heard of a web server employed that way. Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
