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
> exa
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 shutdow
Tom Lane wrote:
>>> Why not? It'll fall out of the state again immediately in
>>> PostmasterStateMachine, no, if we do a CancelBackup here?
>>
>> 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().
>
> Er
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.
>
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 calle
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 determi
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.
You
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, s
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 "b
[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
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 BackupI
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
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, t
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 c
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 or --default-database=
Ouch. This calls for confusion with the -E flag of pg_dump,
which means 'encoding'. Something
> 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 shar
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.
-
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 wa
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
>> 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 link
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 -
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_
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
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
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?
Lau
Bruce Momjian 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
>>>
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
Any chance that my LDAP patch
http://momjian.us/mhonarc/patches/msg0.html
will get reviewed before the feature freeze?
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subsc
> 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.
> 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.
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 t
> > 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
33 matches
Mail list logo
