pg_rewind: Skip log directory for file type check like pg_wal
От
Soumyadeep Chakraborty
Тема
pg_rewind: Skip log directory for file type check like pg_wal
Дата
Msg-id
CAE-ML+-e4iWULcsK8DLWCuRQ3nYhQvV0OUpnUgHg+jFSp2Jkow@mail.gmail.com
Список
Дерево обсуждения
pg_rewind: Skip log directory for file type check like pg_wal Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
Re: pg_rewind: Skip log directory for file type check like pg_wal Alexander Kukushkin <cyberdemn@gmail.com>
Re: pg_rewind: Skip log directory for file type check like pg_wal Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
Re: pg_rewind: Skip log directory for file type check like pg_wal Alexander Kukushkin <cyberdemn@gmail.com>
Re: pg_rewind: Skip log directory for file type check like pg_wal Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
Re: pg_rewind: Skip log directory for file type check like pg_wal Alexander Kukushkin <cyberdemn@gmail.com>
Re: pg_rewind: Skip log directory for file type check like pg_wal Daniel Gustafsson <daniel@yesql.se>
Hello hackers, I think we should extend the "log" directory the same courtesy as was done for pg_wal (pg_xlog) in 0e42397f42b. Today, even if BOTH source and target servers have symlinked "log" directories, pg_rewind fails with: file "log" is of different type in source and target. Attached is a repro patch using the 004_pg_xlog_symlink.pl test to demonstrate the failure. Running make check PROVE_TESTS='t/004_pg_xlog_symlink.pl' in src/bin/pg_rewind should suffice after applying. This is because when we use the libpq query to fetch the filemap from the source server, we consider the log directory as a directory, even if it is a symlink. This is because pg_stat_file() is used in that query in libpq_traverse_files() and pg_stat_file() returns isdir=t for symlinks to directories. This shortcoming is somewhat called out: * XXX: There is no backend function to get a symbolic link's target in * general, so if the admin has put any custom symbolic links in the data * directory, they won't be copied correctly. We could fix the query and/or pg_stat_file(). However, we would also like to support deployments where only one of the primaries and/or standbys have the symlink. That is not hard to conceive, given primaries and standbys can have drastically disparate log volume and/or log collection requirements. Attached is a patch that treats "log" like we treat "pg_wal". Regards, Soumyadeep (VMware)
В списке pgsql-hackers по дате отправления