-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
archive_ready does not work on PostgreSQL 10+ #150
Comments
FWIW, this was fixed in 8e6b3c2 but there has been no release yet. |
Um, no - I rather think it was broken by that commit. With the new version and PostgreSQL10, check_wal_files() ignores the $subdir parameter (where "/archive_status" is passed in) and just uses pg_ls_waldir() - which does not list the contents of the archive_status directory, and the WHERE clause ("WHERE name ~ E'^[0-9A-F]{24}$extrabit$'" whith $extrabit being passed as ".ready") cannot succeed. There are no .ready files in the output of pg_ls_waldir(). |
Oh I see - that is indeed the case. pinging @ChristophBerg as he committed that. |
It seems archive_ready does not work for the current version of postgres (13) and always finds 0 ready files. is there some workaround to get it running? |
I think the person to ping was @df7cb |
Looks like this was fixed as of 1e06b0d |
@turnstep how so, that commit (1e06b0d) is from 2015 - maybe it makes it possible to succesfully run
|
This addresses issue bucardo#150.
With the above PR, I get:
|
This fixes issue bucardo#150.
The archive_ready check uses the wal_files check with dedicated options - however, since wal_files was fixed for version 10 in 8e6b3c2 it called pg_ls_waldir() even for the archive_ready check which is not appropriate as this only lists files in pg_wal and not in pg_wal/archive_status. This change makes the wal_files check call pg_ls_archive_statusdir() instead if $extrabit (i.e. .ready) is set, fixing issue bucardo#150.
check_archive_ready() calls check_wal_files()
check_postgres/check_postgres.pl
Line 3826 in fd9702c
That's fine on PostgreSQL < 10, but on 10+ check_wal_files() calls pg_ls_wal_dir(), which lists only files in the wal dir, but not it's subdirectories.
check_postgres/check_postgres.pl
Line 8700 in fd9702c
Thus the WHERE clause will never be true, and COUNT() always returns 0.
I've currently no idea how to fix this in an elegant way: of course one could fall back to the "old" query, but that requires SUPERUSER privileges for pg_ls_dir() (or GRANTs on that, or a wrapper...).
The text was updated successfully, but these errors were encountered: