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 I'd like to apply
>>> the following doc patch also.
>>
>> +1 for the idea.
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 think about adding a mention to the
> system data
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
>>> > adding the parsing context in case of an error
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 that's not worth adding no
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 fo
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 wrote:
On 24 August 2016 at 05:50, Michael Paquier
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 wrote:
>>> On 24 August 2016 at 05:50, Michael Paquier
>>> wrote:
>>>
>> Everything else looks in good order.
>>>
>>> Committed. Th
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.
>>
>> Committed. Thanks.
>
> Thanks for the commit!
By the way, what has been commi
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 list (pgsql-hackers@postgresql.org)
To make changes t
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 pgsql-hackers mailing list (pgsql-hacker
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 doing that.
>>>
>>> I am inclined to mark this as ready for committer.
>>
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 now.
>
> The messages for recovery_target_lsn do
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 targets... e.g.
rec
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 PM, Adrien Nayrat
wrote:
> As Julien said,
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 said, there is nothing to notice that error comes from
recovery.conf.
My fea
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 notice that error comes from
>>> recovery.conf.
>>> My fear would be that an user
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 encounters an error like this. Il will be
>> difficult to link
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.
G
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 wider than that, we may want
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 way you do to show to user a different
>>> error me
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 while the original one is actually correct does
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 error_context_stack for each item
> par
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 seems a bit narrow as usua
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 incorrect recovery_target_lsn y
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 message :
> "FATAL: invali
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
> Yeah, that's really something that covers only a narro
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
>>>
>>> > Yeah, that's really something that covers only a narrow case, though
>>> > if we don't have it when we need it
On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
wrote:
> Christoph Berg wrote:
>> Re: Michael Paquier 2016-05-24
>>
>> > Yeah, that's really something that covers only a narrow case, though
>> > if we don't have it when we need it we're limited to some hacks.
>> > Perhaps people who have the adv
Christoph Berg wrote:
> Re: Michael Paquier 2016-05-24
>
> > Yeah, that's really something that covers only a narrow case, though
> > if we don't have it when we need it we're limited to some hacks.
> > Perhaps people who have the advanced level to use such a thing have
> > the level to use hacks
Re: Michael Paquier 2016-05-24
> Yeah, that's really something that covers only a narrow case, though
> if we don't have it when we need it we're limited to some hacks.
> Perhaps people who have the advanced level to use such a thing have
> the level to use hacks anyway..
I'd think recovery_targ
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 argument behind that
>> was to allow a maximum of thi
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 where a
> relation block got cor
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 t
33 matches
Mail list logo