From: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pg_rewind: Skip log directory for file type check like pg_wal |
Date: | 2023-03-06 02:10:27 |
Message-ID: | CAE-ML+-e4iWULcsK8DLWCuRQ3nYhQvV0OUpnUgHg+jFSp2Jkow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Fix-pg_rewind-when-log-is-a-symlink.patch | text/x-patch | 2.7 KB |
repro.patch | text/x-patch | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2023-03-06 03:18:39 | Re: SQL/JSON revisited |
Previous Message | Thomas Munro | 2023-03-05 23:32:49 | Re: [PATCH] Add CANONICAL option to xmlserialize |