On Thu, Dec 10, 2015 at 4:57 PM, Andres Freund <and...@anarazel.de> wrote:
> On December 10, 2015 5:02:27 AM GMT+01:00, Michael Paquier 
> <michael.paqu...@gmail.com> wrote:
>>On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund <and...@anarazel.de>
>>> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
>>>> Oh, OK. I didn't read though your lines correctly. So you basically
>>>> mean that we would look at the init files that are on disk, and
>>>> if they are empty. If they are, we simply use XLogReadBufferExtended
>>>> to fetch the INIT_FORKNUM content and fill in another buffer for the
>>>> MAIN_FORKNUM. More or less right?
>>> We would not just do so if they're empty, we would just generally
>>copy the file
>>> via shared buffers, instead of copy_file(). But we'd get the file
>>> from the filesystem (which is fine, we make sure it is correct during
>>> replay).
>>So, this suggestion is basically implementing the reverse operation of
>>GetRelationPath() to be able to rebuild a RelFileNode from scratch and
>>then look at the shared buffers needed. Isn't it a bit brittle for
>>back-branches? RelFileNode stuff is available easily through records
>>when replaying individually FPIs, but not really in this code path.
> Oh, sorry. In definitely not thinking about doing this for the back branches. 
> That was more musing about a way to optimize this.

OK sure. Yeah that may be something worth investigating. The reverse
engineering of GetRelationPath would be interesting perhaps for some

So, do we go for something like the patch you attached in
20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
~9.4 we use the one I wrote in
Note that in both cases the patches are not complete, we need to fix
as well copy_relation_data@tablecmds.c so as the INIT_FORKNUM pages
are logged all the time. I am also thinking that the patch changing
WAL format of XLOG_FPI is overdoing it as we know that all the
INIT_FORKNUM will be generated for unlogged relations, so that's fine
to flush unconditionally INIT_FORKNUM buffers at replay.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to