Hello!
> 9 окт. 2017 г., в 10:23, Andrey Borodin написал(а):
>
> Thanks, Stephen, this actually pointed what to look for
> VM is WAL-logged [0]
> FSM is not [1]
>
> [0]
>
On Fri, Oct 6, 2017 at 10:34 AM, Michael Paquier
wrote:
> On Fri, Oct 6, 2017 at 11:22 PM, Tom Lane wrote:
>> I'd say no:
>>
>> 1. You don't know the granularity of the filesystem's timestamps, at least
>> not without making unportable assumptions.
On 10 October 2017 at 23:50, Stephen Frost wrote:
> Yeah, it sounds interesting, but I was just chatting w/ David about it
> and we were thinking about how checkpoints are really rather often done,
> so you end up with quite a few of these lists being out there.
>
> Now, if
Alvaro,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> Greg Stark wrote:
>
> > The general shape of what I would like to see is some log which lists
> > where each checkpoint starts and ends and what blocks are modified
> > since the previous checkpoint. Then to generate an incremental
Greg Stark wrote:
> The general shape of what I would like to see is some log which lists
> where each checkpoint starts and ends and what blocks are modified
> since the previous checkpoint. Then to generate an incremental backup
> from any point in time to the current you union all the block
On 8 October 2017 at 08:52, Andrey Borodin wrote:
>
> 1. Any other marker would be better (It can be WAL scan during archiving,
> some new LSN-based mechanics* et c.)
The general shape of what I would like to see is some log which lists
where each checkpoint starts and
On Sat, Oct 7, 2017 at 6:34 AM, Stephen Frost wrote:
>> > That’s actually what pg_rman is doing for what it calls incremental
>> > backups (perhaps that would be differential backup in PG
>> > terminology?), and the performance is bad as you can imagine. We could
>> > have a
Hi Michael!
> 9 окт. 2017 г., в 17:28, Michael Paquier
> написал(а):
>> VM is WAL-logged [0]
>> FSM is not [1]
>
> If you are willing to go down this road, here are my takes on the matter:
> - Any LSN map should be in a different file than FSM and VM. The VM
> uses 2
On Mon, Oct 9, 2017 at 2:23 PM, Andrey Borodin wrote:
>> I haven't gone and audited it myself, but I would certainly expect you
>> to be able to use the LSN for everything which is WAL'd. If you have
>> cases where that's not the case, it'd be useful to see them.
>
>
> 8 окт. 2017 г., в 20:11, Stephen Frost написал(а):
> * Andrey Borodin (x4...@yandex-team.ru) wrote:
>> But my other question still seems unanswered: can I use LSN logic for
>> incrementing FSM and VM? Seems like most of the time there is valid LSN
>
> I haven't gone and
Andrey,
* Andrey Borodin (x4...@yandex-team.ru) wrote:
> But my other question still seems unanswered: can I use LSN logic for
> incrementing FSM and VM? Seems like most of the time there is valid LSN
I haven't gone and audited it myself, but I would certainly expect you
to be able to use the
Tom, Alvaro, Michael, and especially Septhen, thank you for your valuable
comments.
I feel enlightened about mtime.
My takeaway is:
1. Any other marker would be better (It can be WAL scan during archiving, some
new LSN-based mechanics* et c.)
2. mtime could be used, with precautions described
Alvaro, Michael,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> Michael Paquier wrote:
> > That’s actually what pg_rman is doing for what it calls incremental
> > backups (perhaps that would be differential backup in PG
> > terminology?), and the performance is bad as you can imagine. We
Michael Paquier wrote:
> That’s actually what pg_rman is doing for what it calls incremental
> backups (perhaps that would be differential backup in PG
> terminology?), and the performance is bad as you can imagine. We could
> have a dedicated LSN map to do such things with 4 bytes per page. I am
> Le 6 oct. 2017 à 23:44, Alvaro Herrera a écrit :
>
> Michael Paquier wrote:
>
>> The only sane method for Postgres is really to scan the
>> page header LSNs, and of course you already know that.
>
> I hope the idea is not to have to scan every single page in the
>
Tom, Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Oct 6, 2017 at 11:22 PM, Tom Lane wrote:
> > Andrey Borodin writes:
> >> Is it safe to use file modification time to track that file were changes
> >> since previous backup?
>
Michael Paquier wrote:
> The only sane method for Postgres is really to scan the
> page header LSNs, and of course you already know that.
I hope the idea is not to have to scan every single page in the
database, because that would be too slow. It should be possible to
build this so that a
On Fri, Oct 6, 2017 at 11:22 PM, Tom Lane wrote:
> Andrey Borodin writes:
>> Is it safe to use file modification time to track that file were changes
>> since previous backup?
>
> I'd say no:
>
> 1. You don't know the granularity of the filesystem's
Andrey Borodin writes:
> Is it safe to use file modification time to track that file were changes
> since previous backup?
I'd say no:
1. You don't know the granularity of the filesystem's timestamps, at least
not without making unportable assumptions.
2. There's no
Hi, hackers!
Currently I'm working on page-level incremental backups using WAL-G
codebase[0]. And I have two questions that I cannot resolve myself.
Incremental backup is a set of changes, that should be applied over preexisting
backup. I use page LSN to understand should page be backup`ed or
20 matches
Mail list logo