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,
20 matches
Mail list logo
