On Mon, Sep 5, 2016 at 4:02 PM, Simon Riggs wrote:
> On 5 September 2016 at 06:55, Michael Paquier
> wrote:
>> On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs wrote:
>
>>> I noticed we don't mention what LSN is anywhere, so
On 5 September 2016 at 06:55, Michael Paquier wrote:
> On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs wrote:
>> I noticed we don't mention what LSN is anywhere, so I'd like to apply
>> the following doc patch also.
>
> +1 for the idea. What do you
On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs wrote:
> On 4 September 2016 at 14:32, Abhijit Menon-Sen wrote:
>> At 2016-09-04 07:02:01 +0100, si...@2ndquadrant.com wrote:
>>>
>>> > By the way, what has been committed does not include the patch
>>> >
On 4 September 2016 at 14:32, Abhijit Menon-Sen wrote:
> At 2016-09-04 07:02:01 +0100, si...@2ndquadrant.com wrote:
>>
>> > By the way, what has been committed does not include the patch
>> > adding the parsing context in case of an error as wanted upthread.
>> > Perhaps
At 2016-09-04 07:02:01 +0100, si...@2ndquadrant.com wrote:
>
> > By the way, what has been committed does not include the patch
> > adding the parsing context in case of an error as wanted upthread.
> > Perhaps that's not worth adding now as there is the GUC refactoring
> > potentially happening
On Sun, Sep 4, 2016 at 3:02 PM, Simon Riggs wrote:
> On 4 September 2016 at 04:50, Michael Paquier
> wrote:
>> On Sun, Sep 4, 2016 at 8:05 AM, Michael Paquier
>> wrote:
>>> On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs
On 4 September 2016 at 04:50, Michael Paquier wrote:
> On Sun, Sep 4, 2016 at 8:05 AM, Michael Paquier
> wrote:
>> On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs wrote:
>>> On 24 August 2016 at 05:50, Michael Paquier
On Sun, Sep 4, 2016 at 8:05 AM, Michael Paquier
wrote:
> On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs wrote:
>> On 24 August 2016 at 05:50, Michael Paquier
>> wrote:
>>
> Everything else looks in good order.
>>
>>
On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs wrote:
> On 24 August 2016 at 05:50, Michael Paquier wrote:
>
Everything else looks in good order.
>
> Committed. Thanks.
Thanks for the commit!
--
Michael
--
Sent via pgsql-hackers mailing
On 24 August 2016 at 05:50, Michael Paquier wrote:
>>> Everything else looks in good order.
Committed. Thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
On Tue, Aug 23, 2016 at 8:50 PM, Michael Paquier
wrote:
> On Tue, Aug 23, 2016 at 6:10 PM, Simon Riggs wrote:
>> On 23 August 2016 at 09:39, Petr Jelinek wrote:
>>
>>> Looks very reasonable to me (both patches). Thanks for
On Tue, Aug 23, 2016 at 6:10 PM, Simon Riggs wrote:
> On 23 August 2016 at 09:39, Petr Jelinek wrote:
>
>> Looks very reasonable to me (both patches). Thanks for doing that.
>>
>> I am inclined to mark this as ready for committer.
>
> Looking at it
On 23 August 2016 at 09:39, Petr Jelinek wrote:
> Looks very reasonable to me (both patches). Thanks for doing that.
>
> I am inclined to mark this as ready for committer.
Looking at it now.
The messages for recovery_target_lsn don't mention after or before, as
do other
On 08/23/2016 10:39 AM, Petr Jelinek wrote:
> On 23/08/16 09:33, Michael Paquier wrote:
>> On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas
>> wrote:
>>> On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier
>>> wrote:
On Mon, Aug 22, 2016 at 7:12
On 23/08/16 09:33, Michael Paquier wrote:
On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas wrote:
On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier
wrote:
On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat wrote:
As Julien
On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas wrote:
> On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier
> wrote:
>> On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat
>> wrote:
>>> As Julien said, there is nothing to
On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier
wrote:
> On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat
> wrote:
>> As Julien said, there is nothing to notice that error comes from
>> recovery.conf.
>> My fear would be that an user
On 8/22/16 8:28 AM, Michael Paquier wrote:
> Thinking a bit wider than that, we may want to know such context for
> normal GUC parameters as well, and that's not the case now. Perhaps
> there is actually a reason why that's not done for GUCs, but it seems
> that it would be useful there as well.
On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat wrote:
> As Julien said, there is nothing to notice that error comes from
> recovery.conf.
> My fear would be that an user encounters an error like this. Il will be
> difficult to link to the recovery.conf.
Thinking a bit
On 08/20/2016 04:16 PM, Michael Paquier wrote:
> On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote:
>> On 20/08/16 02:13, Michael Paquier wrote:
>>> On Fri, Aug 19, 2016 at 10:47 PM, Adrien Nayrat
>>> wrote:
>>> Using a PG_TRY/CATCH block the
On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote:
> On 20/08/16 02:13, Michael Paquier wrote:
>> On Fri, Aug 19, 2016 at 10:47 PM, Adrien Nayrat
>> wrote:
>> Using a PG_TRY/CATCH block the way you do to show to user a different
>> error message
On 20/08/2016 15:41, Michael Paquier wrote:
> On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote:
>> If we want to specifically name the recovery_target_lsn in the message, we
>> could probably do it using context.
>
> So that would be basically assigning
On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek wrote:
> If we want to specifically name the recovery_target_lsn in the message, we
> could probably do it using context.
So that would be basically assigning error_context_stack for each item
parsed for recovery.conf? That
On 20/08/16 02:13, Michael Paquier wrote:
On Fri, Aug 19, 2016 at 10:47 PM, Adrien Nayrat
wrote:
I reviewed this patch rebased to deal with
f6ced51f9188ad5806219471a0b40a91dde923aa, and minor adjustment (see below)
Thanks!
It do the job. However if you use an
On Fri, Aug 19, 2016 at 10:47 PM, Adrien Nayrat
wrote:
> I reviewed this patch rebased to deal with
> f6ced51f9188ad5806219471a0b40a91dde923aa, and minor adjustment (see below)
Thanks!
> It do the job. However if you use an incorrect recovery_target_lsn you
> get this
On 06/09/2016 02:33 PM, Michael Paquier wrote:
> On Wed, May 25, 2016 at 1:32 AM, Michael Paquier
> wrote:
>> On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
>> wrote:
>>> Christoph Berg wrote:
Re: Michael Paquier 2016-05-24
On Wed, May 25, 2016 at 1:32 AM, Michael Paquier
wrote:
> On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
> wrote:
>> Christoph Berg wrote:
>>> Re: Michael Paquier 2016-05-24
>>>
On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
wrote:
> Christoph Berg wrote:
>> Re: Michael Paquier 2016-05-24
>>
Christoph Berg wrote:
> Re: Michael Paquier 2016-05-24
>
Re: Michael Paquier 2016-05-24
On Mon, May 23, 2016 at 6:25 PM, Craig Ringer wrote:
> On 24 May 2016 at 09:12, Michael Paquier wrote:
>>
>> Hi all,
>>
>> Today somebody has pointed me out that it could be interesting to be
>> able to recovery up to a given LSN position. One
On 24 May 2016 at 09:12, Michael Paquier wrote:
> Hi all,
>
> Today somebody has pointed me out that it could be interesting to be
> able to recovery up to a given LSN position. One argument behind that
> was to allow a maximum of things to recover up to the point
Hi all,
Today somebody has pointed me out that it could be interesting to be
able to recovery up to a given LSN position. One argument behind that
was to allow a maximum of things to recover up to the point where a
relation block got corrupted by a specific record because of a broken
segment. So
33 matches
Mail list logo