Re: [HACKERS] A weird bit in pg_upgrade/exec.c

2017-11-09 Thread Tom Lane
Alvaro Herrera writes: > I think odd coding this was introduced recently because of the > pg_resetxlog -> pg_resetwal renaming. Dunno about that, but certainly somebody fat-fingered a refactoring there. The 9.6 code looks quite different but doesn't seem to be doing

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

2017-11-09 Thread Tom Lane
a.akent...@postgrespro.ru writes: > I've came across a weird bit in pg_upgrade/exec.c > We have a function check_bin_dir() which goes like this (old_cluster and > new_cluster are global variables): > void check_bin_dir(ClusterInfo *cluster) > { > ... > get_bin_version(_cluster); >

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

2017-11-09 Thread Alvaro Herrera
a.akent...@postgrespro.ru wrote: > This function has two calls: > check_bin_dir(_cluster); > check_bin_dir(_cluster); > > I'd like to substitute these last two lines with this: > get_bin_version(cluster); Odd indeed. One would think that if a cluster variable is passed as parameter, the global

[HACKERS] A weird bit in pg_upgrade/exec.c

2017-11-09 Thread a . akenteva
Hello! I've came across a weird bit in pg_upgrade/exec.c We have a function check_bin_dir() which goes like this (old_cluster and new_cluster are global variables): void check_bin_dir(ClusterInfo *cluster) { ... get_bin_version(_cluster); get_bin_version(_cluster); ... } This