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]
> https://github.com/postgres/postgres/blob/113b0045e20d40f726a0a30e33214455e4f1385e/src/backend/access/heap/visibilitymap.c
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.
>>
>> 2. There's no guarantee that the system cl
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 the lists were always k
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 backu
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 lis
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 ends and what blocks are m
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 dedicated LSN map to d
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 bits per blocks now, and the
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.
>
> Thanks, Stephen, this actuall
> 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 audited it myself, but
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 LS
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 by
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 coul
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
> database, because that wou
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?
> >
> > I'd say no:
> >
> > 1. You don't know
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 single
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 timestamps, at least
> not without making unpor
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 guarantee that the system cl
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 n
20 matches
Mail list logo