On Thu, Jan 24, 2019 at 3:39 AM John Naylor <john.nay...@2ndquadrant.com> wrote: > > On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > Also, another case to think in this regard is the upgrade for standby > > servers, if you read below paragraph from the user manual [1], you > > will see what I am worried about? > > > > "What this does is to record the links created by pg_upgrade's link > > mode that connect files in the old and new clusters on the primary > > server. It then finds matching files in the standby's old cluster and > > creates links for them in the standby's new cluster. Files that were > > not linked on the primary are copied from the primary to the standby. > > (They are usually small.)" > > > > [1] - https://www.postgresql.org/docs/devel/pgupgrade.html > > I am still not able to get the upgraded standby to go into recovery > without resorting to pg_basebackup, but in another attempt to > investigate your question I tried the following (data1 = old cluster, > data2 = new cluster): > > > mkdir -p data1 data2 standby > > echo 'heap' > data1/foo > echo 'fsm' > data1/foo_fsm > > # simulate streaming replication > rsync --archive data1 standby > > # simulate pg_upgrade, skipping FSM > ln data1/foo -t data2/ > > rsync --archive --delete --hard-links --size-only --no-inc-recursive > data1 data2 standby > > # result > ls standby/data1 > ls standby/data2 > > > The result is that foo_fsm is not copied to standby/data2, contrary to > what the docs above imply for other unlinked files. Can anyone shed > light on this? >
Is foo_fsm present in standby/data1? I think what doc means to say is that it copies any unlinked files present in primary's new cluster (which in your case will be data2). -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
