Skip to content
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

Open
moench-tegeder opened this issue Sep 19, 2018 · 8 comments
Open

archive_ready does not work on PostgreSQL 10+ #150

moench-tegeder opened this issue Sep 19, 2018 · 8 comments

Comments

@moench-tegeder
Copy link
Contributor

check_archive_ready() calls check_wal_files()

return check_wal_files('/archive_status', '.ready', 10, 15);

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.
qq{SELECT count(*) AS count FROM pg_ls_waldir() WHERE name ~ E'^[0-9A-F]{24}$extrabit\$'}; ## no critic (RequireInterpolationOfMetachars)

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...).

@mbanck
Copy link
Contributor

mbanck commented Oct 17, 2018

FWIW, this was fixed in 8e6b3c2 but there has been no release yet.

@moench-tegeder
Copy link
Contributor Author

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().

@mbanck
Copy link
Contributor

mbanck commented Oct 17, 2018

Oh I see - that is indeed the case.

pinging @ChristophBerg as he committed that.

@ChristophKaser
Copy link

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?

@ChristophKaser
Copy link

Oh I see - that is indeed the case.

pinging @ChristophBerg as he committed that.

I think the person to ping was @df7cb

@turnstep
Copy link
Contributor

turnstep commented Apr 4, 2023

Looks like this was fixed as of 1e06b0d

@turnstep turnstep closed this as completed Apr 4, 2023
@mbanck
Copy link
Contributor

mbanck commented Oct 4, 2023

@turnstep how so, that commit (1e06b0d) is from 2015 - maybe it makes it possible to succesfully run check_archive_ready if one sets up an elaborate helper function (I did not check), but fact is that this check currently just reports OK on PG10+ as it does not check in pg_wal/archive_status but in pg_wal directly, please reopen.

postgres@db01:~$ touch /var/lib/postgresql/13/main/pg_wal/archive_status/000000010000000000000001.ready
postgres@db01:~$ touch /var/lib/postgresql/13/main/pg_wal/archive_status/000000010000000000000002.ready
postgres@db01:~$ LANG=C check_postgres -w 1 -c 1 --action archive_ready -H /var/run/postgresql/
POSTGRES_ARCHIVE_READY OK: DB "postgres" (host:/var/run/postgresql/) WAL ".ready" files found: 0 | time=0.02s files=0;1;1 

mbanck pushed a commit to credativ/check_postgres that referenced this issue Oct 4, 2023
@mbanck
Copy link
Contributor

mbanck commented Oct 4, 2023

With the above PR, I get:

postgres@db01:~$ LANG=C /tmp/check_postgres -w 1 -c 1 --action archive_ready -H /var/run/postgresql/
POSTGRES_ARCHIVE_READY CRITICAL: DB "postgres" (host:/var/run/postgresql/) WAL ".ready" files found: 2 | time=0.02s files=2;1;1 

@turnstep turnstep reopened this Oct 4, 2023
mbanck pushed a commit to credativ/check_postgres that referenced this issue Oct 4, 2023
mbanck pushed a commit to credativ/check_postgres that referenced this issue Oct 4, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants