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,
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
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.
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
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,
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
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
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
[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
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()
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
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,
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
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'.
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.
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
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
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.
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
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
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
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
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
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
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,
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
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
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
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
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
30 matches
Mail list logo
