Sorry for the late reply. I have checked those relfilenodes and they have existed.
I used tablespace to store data and it seems to be that pg_rewind copied everthing in the tablespace. Today I found an article posted by you (Michael Paquier) and you said that there was no tablespace support. If so, is there anyway to work around ? Regards, Hung Phan On Fri, Sep 15, 2017 at 1:55 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Sep 15, 2017 at 2:57 PM, Hung Phan <hungphan...@gmail.com> wrote: > > [...] > > Please do not top-post. This breaks the logic of the thread. > > > I use ver 9.5.3. > > You should update to the latest minor version available, there have > been quite a couple of bug fixes in Postgres since this 9.5.3. > > > I have just run again and get the debug log. It is very long so I attach > in mail > In this case the LSN where the promoted standby and the rewound node > diverged is clear: > servers diverged at WAL position 2/D69820C8 on timeline 12 > rewinding from last common checkpoint at 2/D6982058 on timeline 12 > The last segment on timeline 13 is 0000000D00000002000000E0, which may > be a recycled segment, still that's up to 160MB worth of data... > > And from what I can see a lot of the data comes from WAL segments from > past timelines, close to 1.3GB. The rest is more or less completely > coming from relation files from a different tablespace than the > default, tables with OID 16665 and 16683 covering the largest part of > it. What is strange to begin with is that there are many segments from > past timelines. Those should not stick around. > > Could you check if the relfilenodes of 16665 and 16683 exist on source > server but do *not* exist on the target server? When issuing a rewind, > a relation file that exists on both has no action taken on (see > process_source_file in filemap.c), and only a set of block are > registered. Based on what comes from your log file, the file is being > copied from the source to the target, not its blocks: > pg_tblspc/16386/PG_9.5_201510051/16387/16665 (COPY) > pg_tblspc/16386/PG_9.5_201510051/16387/16665.1 (COPY) > pg_tblspc/16386/PG_9.5_201510051/16387/16665_fsm (COPY) > And this leads to an increase of the data included in what is rewound. > So aren't you for example re-creating a new database after the standy > is promoted or something like that? > -- > Michael >
