On 25 September 2014 18:30, Andres Freund wrote:
> On 2014-09-25 18:18:09 +0100, Simon Riggs wrote:
>> On 25 September 2014 16:29, Andres Freund 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
On Thu, Sep 25, 2014 at 1:30 PM, Andres Freund 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 - quite frequent
On 2014-09-25 18:18:09 +0100, Simon Riggs wrote:
> On 25 September 2014 16:29, Andres Freund 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, but it's far fr
On 25 September 2014 16:29, Andres Freund 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 --> pro
On Thu, Sep 25, 2014 at 11:34 AM, Andres Freund wrote:
> On 2014-09-25 11:13:50 -0400, Robert Haas wrote:
>> On Wed, Sep 24, 2014 at 4:36 PM, Simon Riggs 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
On 2014-09-25 11:13:50 -0400, Robert Haas wrote:
> On Wed, Sep 24, 2014 at 4:36 PM, Simon Riggs 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
On 2014-09-24 21:36:50 +0100, Simon Riggs wrote:
> On 18 September 2014 01:22, Robert Haas 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
On Wed, Sep 24, 2014 at 4:36 PM, Simon Riggs 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 --> promoted.
On Thu, Sep 25, 2014 at 5:36 AM, Simon Riggs 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 (pgsql-hackers@pos
On 18 September 2014 01:22, Robert Haas 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 exact pat
On Wed, Sep 17, 2014 at 7:23 AM, Simon Riggs wrote:
> On 14 August 2014 20:27, Robert Haas wrote:
>> On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane wrote:
>>> Fujii Masao writes:
I'd like to propose to add new option "--immediate" to pg_ctl promote.
When this option is set, recovery ignor
On 14 August 2014 20:27, Robert Haas wrote:
> On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane wrote:
>> Fujii Masao 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 ex
On Mon, Sep 1, 2014 at 7:14 AM, Fujii Masao 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 promote as wel
On Mon, Sep 1, 2014 at 4:44 PM, Fujii Masao wrote:
> On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila
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 vac
On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila wrote:
> On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao 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 i
On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao 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 is faster tha
Fabrízio de Royes Mello wrote:
> Robert Haas 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? Because that's
On Thu, Aug 14, 2014 at 4:27 PM, Robert Haas 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? Because that's cra
On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane wrote:
> Fujii Masao 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 promotio
Fujii Masao 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 data loss.
TBH,
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 is faster than normal one but can cause data loss. So
it's useful if we want to
21 matches
Mail list logo
