From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] Incremental backup v2: add backup profile to base backup |
Date: | 2014-10-03 16:23:09 |
Message-ID: | CAGTBQpYixGSqwxZspG_PzSbFTWOgJyar+hhQK+70tMEw0ZLo7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 3, 2014 at 1:08 PM, Marco Nenciarini
<marco(dot)nenciarini(at)2ndquadrant(dot)it> wrote:
>>> Any comment will be appreciated. In particular I'd appreciate comments
>>> on correctness of relnode files detection and LSN extraction code.
>>
>> I didn't look at it in detail, but one future problem comes to mind:
>> Once you implement the server-side code that only sends a file if its
>> LSN is higher than the cutoff point that the client gave, you'll have to
>> scan the whole file first, to see if there are any blocks with a higher
>> LSN. At least until you find the first such block. So with a file-level
>> implementation of this sort, you'll have to scan all files twice, in the
>> worst case.
>>
>
> It's true. To solve this you have to keep a central maxLSN directory,
> but I think it introduces more issues than it solves.
I see that as a worthy optimization on the server side, regardless of
whether file or block-level backups are used, since it allows
efficient skipping of untouched segments (common for append-only
tables).
Still, it would be something to do after it works already (ie: it's an
optimization)
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2014-10-03 16:25:55 | Re: CREATE IF NOT EXISTS INDEX |
Previous Message | Bruce Momjian | 2014-10-03 16:20:27 | Re: Trailing comma support in SELECT statements |