On Wed, Sep 24, 2014 at 4:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
To me, being able to say pg_ctl promote_right_now -m yes_i_mean_it
seems like a friendlier interface than making somebody shut down the
server, run pg_resetxlog, and start it up again.
It makes sense to go from paused
On 2014-09-24 21:36:50 +0100, Simon Riggs wrote:
On 18 September 2014 01:22, Robert Haas robertmh...@gmail.com wrote:
fast promotion was actually a supported option in r8 of Postgres but
this option was removed when we implemented streaming replication in
r9.0
The *rough* requirement
On 2014-09-25 11:13:50 -0400, Robert Haas wrote:
On Wed, Sep 24, 2014 at 4:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
To me, being able to say pg_ctl promote_right_now -m yes_i_mean_it
seems like a friendlier interface than making somebody shut down the
server, run pg_resetxlog, and
On Thu, Sep 25, 2014 at 11:34 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-25 11:13:50 -0400, Robert Haas wrote:
On Wed, Sep 24, 2014 at 4:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
To me, being able to say pg_ctl promote_right_now -m yes_i_mean_it
seems like a friendlier
On 25 September 2014 16:29, Andres Freund and...@2ndquadrant.com wrote:
To me, being able to say pg_ctl promote_right_now -m yes_i_mean_it
seems like a friendlier interface than making somebody shut down the
server, run pg_resetxlog, and start it up again.
It makes sense to go from paused
On 2014-09-25 18:18:09 +0100, Simon Riggs wrote:
On 25 September 2014 16:29, Andres Freund and...@2ndquadrant.com wrote:
I think that's not really related. Such a promotion doesn't cause data
loss in the sense of loosing data a *clueful* operator wanted to
keep. Yes, it can be used wrongly,
On Thu, Sep 25, 2014 at 1:30 PM, Andres Freund and...@2ndquadrant.com wrote:
Yes it does cause data loss. The clueful operator has no idea where
they are so there is no used rightly in that case.
What? There definitely are cases where you don't need to know that to
the T. Just think of the -
On 25 September 2014 18:30, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-25 18:18:09 +0100, Simon Riggs wrote:
On 25 September 2014 16:29, Andres Freund and...@2ndquadrant.com wrote:
I think that's not really related. Such a promotion doesn't cause data
loss in the sense of loosing
On 18 September 2014 01:22, Robert Haas robertmh...@gmail.com wrote:
fast promotion was actually a supported option in r8 of Postgres but
this option was removed when we implemented streaming replication in
r9.0
The *rough* requirement is sane, but that's not the same thing as
saying this
On Thu, Sep 25, 2014 at 5:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
We go to a lot of trouble to ensure data is successfully on disk and
in WAL. I won't give that up, nor do I want to make it easier to lose
data than it already is.
+1.
--
Michael
--
Sent via pgsql-hackers mailing list
On 14 August 2014 20:27, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any
On Wed, Sep 17, 2014 at 7:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 14 August 2014 20:27, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
I'd like to propose to add new option
On Mon, Sep 1, 2014 at 7:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
I think there is one downside as well for this proposal that
apart from data loss, it can lead to uncommitted data occupying
space in database which needs to be later cleaned by vacuum.
This can happen with non-immediate
On Mon, Sep 1, 2014 at 4:44 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
I think there is one downside as well for this proposal that
apart from data loss, it can lead to uncommitted data occupying
space in database
On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any WAL data which have not
been replayed yet and exits immediately. Patch attached.
This promotion
On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any WAL data which have not
Fujii Masao masao.fu...@gmail.com writes:
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any WAL data which have not
been replayed yet and exits immediately. Patch attached.
This promotion is faster than normal one but can cause
On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any WAL data which have not
been replayed yet and exits immediately.
On Thu, Aug 14, 2014 at 4:27 PM, Robert Haas robertmh...@gmail.com wrote:
We already have the facilities to stop replay at a defined place. But
then what? Without this patch, do well tell the customer to stop
replay, do a pg_dump of the whole database, and restore it into a new
database?
Fabrízio de Royes Mello fabriziome...@gmail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
We already have the facilities to stop replay at a defined
place. But then what? Without this patch, do well tell the
customer to stop replay, do a pg_dump of the whole database, and
restore it
20 matches
Mail list logo
