Unable to start postgresql-14

On 12/22/23 22:48, Johnathan Tiamoh wrote:

Hello,

I am able to start postgresql because of the below error. Please is
there any help

User
You
FATAL:  xlog flush request 4392/164662F8 is not satisfied --- flushed
only to 4392/F000058

UserYouFATAL:  xlog flush request 4392/164662F8 is not satisfied ---
flushed only to 4392/F000058

More information needed:

1) Exact Postgres version e.g 14.x

2) Is it community version or fork?

3) What was the command you used to start the cluster?

4) Do you have replication/WAL archiving set up?

--
Adrian Klaver
adrian.klaver@aklaver.com

More information needed:

1) Exact Postgres version e.g 14.x

Postgresql Version 14. 10

2) Is it community version or fork?

Community version

3) What was the command you used to start the cluster?

systemctl start postgresql-14

4) Do you have replication/WAL archiving set up?

Yes.

Just to add. The data directory was accidentally deleted. At the time of
deletion. The secondary was broken.
I restore from backup and it couldn't start.

I ended up doing a pg_resetwal to start it and ended up with lots of data
corruption.

I have try a pg_dumpall to restore in a new server and it has equally
failed.

On Sat, Dec 23, 2023 at 11:35 AM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

On 12/23/23 10:05, Johnathan Tiamoh wrote:

More information needed:

1) Exact Postgres version e.g 14.x

Postgresql Version 14. 10

2) Is it community version or fork?

Community version

3) What was the command you used to start the cluster?

systemctl start postgresql-14

4) Do you have replication/WAL archiving set up?

Yes.

Just to add. The data directory was accidentally deleted. At the time of
deletion. The secondary was broken.

So that is the cause of the issue.

I restore from backup and it couldn't start.

Was this backup taken before the data directory was deleted?

If so how was the backup done?

I ended up doing a pg_resetwal to start it and ended up with lots of
data corruption.

Does this mean you recreated the data directory from some source and
then ran pg_resetwal?

I have try a pg_dumpall to restore in a new server and it has equally
failed.

Do you mean you did a pg_dumpall from the Postgres instance running on
the restored data directory?

--
Adrian Klaver
adrian.klaver@aklaver.com

Was this backup taken before the data directory was deleted?

Yes. I restored it from a 1-day old backup, but unfortunately, I couldn't
apply the logs.

If so how was the backup done?
It was taken with a customized script that uses pg_dump.

Does this mean you recreated the data directory from some source and
then ran pg_resetwal?

I recreated it from the backup

Do you mean you did a pg_dumpall from the Postgres instance running on
the restored data directory?

Yes. And it failed

On Sat, Dec 23, 2023 at 5:35 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

On 12/24/23 08:03, Johnathan Tiamoh wrote:

Was this backup taken before the data directory was deleted?

Yes. I restored it from a 1-day old backup, but unfortunately, I
couldn't apply the logs.

If the backup was done using pg_dump as mentioned below why where you
applying logs?

You need to provide more information about what the customized script
does and what logs you are using?

If so how was the backup done?
It was taken with a customized script that uses pg_dump.

Does this mean you recreated the data directory from some source and
then ran pg_resetwal?

I recreated it from the backup

Do you mean you did a pg_dumpall from the Postgres instance running on
the restored data directory?

Yes. And it failed

--
Adrian Klaver
adrian.klaver@aklaver.com

On Sun, Dec 24, 2023 at 11:04 AM Johnathan Tiamoh <johnathantiamoh@gmail.com>
wrote:

If so how was the backup done?
It was taken with a customized script that uses pg_dump.

That's your problem: pg_dump is a logical backup. All the WAL records are
now completely invalid.

If you want PITR, read
https://www.postgresql.org/docs/current/continuous-archiving.html *and then
use a dedicated PITR program*.like (alphabetically) barman or pgbackrest.

I like pgbackrest. It's always worked for me, and the developers respond
quickly to issues raised on github. Stephen also monitors this list.