Follow-up during March 2008 CommitFest
On Thu, 2007-06-07 at 21:53 +0100, Simon Riggs wrote:
> On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote:
> > Simon Riggs wrote:
> > > On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
> > >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > >>> 2. pg_s
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
> On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote:
> > Simon Riggs wrote:
> > > On Fri,
On Thu, 2007-06-07 at 21:53 +0100, Simon Riggs wrote:
> We have a number of problems surrounding pg_stop_backup/shutdown:
I'll start coding up my proposals, in the absence of alternate views.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
-
On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote:
> Simon Riggs wrote:
> > On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> 2. pg_stop_backup() should wait until all archive files are safely
> >>> archived before returning
> >> Not sur
On Mar 30, 2007, at 5:51 PM, Florian G. Pflug wrote:
In realitly, however, I feare that most people will just create a
script
that does 'echo "select pg_stop_backup | psql"' or something similar.
If they're a bit more carefull, they will enable ON_ERROR_STOP, and
check
the return value of pgs
Simon Riggs wrote:
On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
2. pg_stop_backup() should wait until all archive files are safely
archived before returning
Not sure I agree with that one. If it fails, you can't tell whether the
action is done a
On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I'd like to make the following changes to recovery related code over the
> > next few days/weeks. If anybody insists I do this by freeze or not at
> > all, then I'll submit patches for 1,3,4,5,10 befo
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I'd like to make the following changes to recovery related code over the
> next few days/weeks. If anybody insists I do this by freeze or not at
> all, then I'll submit patches for 1,3,4,5,10 before Saturday night. I'd
> rather take a bit more time and do
I'd like to make the following changes to recovery related code over the
next few days/weeks. If anybody insists I do this by freeze or not at
all, then I'll submit patches for 1,3,4,5,10 before Saturday night. I'd
rather take a bit more time and do this in one drop and there are some
code dependen
