On Sun, Feb 7, 2016 at 10:54 AM, Amit Kapila
wrote:
>
> On Tue, Feb 2, 2016 at 5:28 AM, Andres Freund wrote:
> >
> > Hi,
> >
> > currently if, when not in standby mode, we can't read a checkpoint
> > record, we automatically fall back to the previous checkpoint, and start
> > replay from there.
>
On Tue, Feb 2, 2016 at 5:28 AM, Andres Freund wrote:
>
> Hi,
>
> currently if, when not in standby mode, we can't read a checkpoint
> record, we automatically fall back to the previous checkpoint, and start
> replay from there.
>
> Doing so without user intervention doesn't actually seem like a go
On February 5, 2016 2:52:20 AM GMT+03:00, Jim Nasby
wrote:
>On 2/4/16 3:37 PM, Andres Freund wrote:
>> On 2016-02-03 09:28:24 -0500, Robert Haas wrote:
>>> Would we still have some way of forcing the older checkpoint record
>to
>>> be used if somebody wants to try to do that?
>>
>> I think curren
On 2/4/16 3:37 PM, Andres Freund wrote:
On 2016-02-03 09:28:24 -0500, Robert Haas wrote:
Would we still have some way of forcing the older checkpoint record to
be used if somebody wants to try to do that?
I think currently the best way to force an arbitrary checkpoint to be
used is creating a
On 2/4/16 5:09 PM, David G. Johnston wrote:
What the 2nd para in the documentation is saying is something different:
it is talking about reading all the pg_xlog files (in reverse order),
which is not pg_control, and see what checkpoint records are there, then
figure out which one
On Thu, Feb 4, 2016 at 3:57 PM, Alvaro Herrera
wrote:
> David G. Johnston wrote:
>
> > Learning by reading here...
> >
> > http://www.postgresql.org/docs/current/static/wal-internals.html
> > """
> > After a checkpoint has been made and the log flushed, the checkpoint's
> > position is saved in
David G. Johnston wrote:
> Learning by reading here...
>
> http://www.postgresql.org/docs/current/static/wal-internals.html
> """
> After a checkpoint has been made and the log flushed, the checkpoint's
> position is saved in the file pg_control. Therefore, at the start of
> recovery, the serve
On 2016-02-03 09:28:24 -0500, Robert Haas wrote:
> Would we still have some way of forcing the older checkpoint record to
> be used if somebody wants to try to do that?
I think currently the best way to force an arbitrary checkpoint to be
used is creating a "custom" backup label. Not that nice. N
On Mon, Feb 1, 2016 at 6:58 PM, Andres Freund wrote:
> currently if, when not in standby mode, we can't read a checkpoint
> record, we automatically fall back to the previous checkpoint, and start
> replay from there.
>
> Doing so without user intervention doesn't actually seem like a good
> idea.
On Mon, Feb 1, 2016 at 5:48 PM, Andres Freund wrote:
> On 2016-02-01 17:29:39 -0700, David G. Johnston wrote:
> > Learning by reading here...
> >
> > http://www.postgresql.org/docs/current/static/wal-internals.html
> > """
> > After a checkpoint has been made and the log flushed, the checkpoint
On 2016-02-01 17:29:39 -0700, David G. Johnston wrote:
> Learning by reading here...
>
> http://www.postgresql.org/docs/current/static/wal-internals.html
> """
> After a checkpoint has been made and the log flushed, the checkpoint's
> position is saved in the file pg_control. Therefore, at the s
On Mon, Feb 1, 2016 at 4:58 PM, Andres Freund wrote:
> Hi,
>
> currently if, when not in standby mode, we can't read a checkpoint
> record, we automatically fall back to the previous checkpoint, and start
> replay from there.
>
> Doing so without user intervention doesn't actually seem like a goo
Hi,
currently if, when not in standby mode, we can't read a checkpoint
record, we automatically fall back to the previous checkpoint, and start
replay from there.
Doing so without user intervention doesn't actually seem like a good
idea. While not super likely, it's entirely possible that doing s
13 matches
Mail list logo