[Bug]: WAL archive failed can't dissapear about cloudnative-pg HOT 11 CLOSED

Just to be clear, you'd like to make the line disappear if, after a failure, things are now working correctly (i.e. failed timestamp < success timestamp). Am I right?

from cloudnative-pg.

@gbartolini Yes, it will be good. It seems everything works fine. the backup works fine.
And I would like to know the reason, why it happened

from cloudnative-pg.

Overlaps or is a special case of #2432 ?

from cloudnative-pg.

It is very interesting.
I created a new DB cluster and got the same issue with the WAL archive.

from cloudnative-pg.

Please look at #1402

from cloudnative-pg.

I ran command to reset the statistics of the archive. Now I have the walArchivingFailing issue

Continuous Backup status
First Point of Recoverability:  2024-01-20T00:00:06Z
Working WAL archiving:          Starting Up
WALs waiting to be archived:    0
Last Archived WAL:              -
Last Failed WAL:                -

I restarted pod and will check tomorrow, if something is changed

from cloudnative-pg.

the issue with backups:
{"level":"info","ts":"2024-01-17T13:50:31Z","logger":"wal-archive","msg":"Archived WAL file","logging_pod":"banners-db-1","walName":"pg_wal/0000000F000000000000002F","startTime":"2024-01-17T13:50:30Z","endTime":"2024-01-17T13:50:31Z","elapsedWalTime":0.717355918} {"level":"info","ts":"2024-01-17T13:55:31Z","logger":"wal-archive","msg":"Archived WAL file","logging_pod":"banners-db-1","walName":"pg_wal/0000000F0000000000000030","startTime":"2024-01-17T13:55:30Z","endTime":"2024-01-17T13:55:31Z","elapsedWalTime":0.69901278} {"level":"info","ts":"2024-02-20T08:04:56Z","logger":"postgres","msg":"record","logging_pod":"banners-db-1","record":{"log_time":"2024-02-20 08:04:56.543 UTC","user_name":"postgres","database_name":"postgres","process_id":"3514065","connection_from":"[local]","session_id":"65d45d23.359ed1","session_line_num":"1","command_tag":"idle","session_start_time":"2024-02-20 08:04:51 UTC","virtual_transaction_id":"4/1407","transaction_id":"0","error_severity":"ERROR","sql_state_code":"42601","message":"syntax error at or near \"SELECT\"","query":"SELECT * FROM pg_backup_stop\nSELECT * FROM pg_backup_stop;","query_pos":"30","application_name":"psql","backend_type":"client backend","query_id":"0"}} {"level":"info","ts":"2024-02-20T08:05:11Z","logger":"postgres","msg":"record","logging_pod":"banners-db-1","record":{"log_time":"2024-02-20 08:05:11.915 UTC","user_name":"postgres","database_name":"postgres","process_id":"3514065","connection_from":"[local]","session_id":"65d45d23.359ed1","session_line_num":"2","command_tag":"SELECT","session_start_time":"2024-02-20 08:04:51 UTC","virtual_transaction_id":"4/1408","transaction_id":"0","error_severity":"ERROR","sql_state_code":"42P01","message":"relation \"pg_backup_stop\" does not exist","query":"SELECT * FROM pg_backup_stop;","query_pos":"15","application_name":"psql","backend_type":"client backend","query_id":"0"}}

from cloudnative-pg.

Why are you trying to manually run (with errors) SELECT * FROM pg_backup_stop\nSELECT * FROM pg_backup_stop; and SELECT * FROM pg_backup_stop;?

from cloudnative-pg.

In my experience, not everyone would like to always reset the last time of failure of the archiver. Postgres allows you to do it, and you can do it, as shown above. I will close this issue unless you have further enquiries.

from cloudnative-pg.

I (no-one) didn't run the command SELECT * FROM pg_backup_stop.
And now, I have issue with all my DBs - Last Failed WAL and with same data - 2024-03-01

from cloudnative-pg.

I (no-one) didn't run the command SELECT * FROM pg_backup_stop. And now, I have issue with all my DBs - Last Failed WAL and with same data - 2024-03-01

CloudNativePG for sure isn't running that command, as the only occurrence of pg_backup_stop in the code is this:

In any case, this is not related to the initial content of the issue. Hence I am closing this ticket.

from cloudnative-pg.