Thread: Unable to start postgresql-14
Hello,
YouFATAL: xlog flush request 4392/164662F8 is not satisfied --- flushed only to 4392/F000058
I am able to start postgresql because of the below error. Please is there any help
You
FATAL: xlog flush request 4392/164662F8 is not satisfied --- flushed only to 4392/F000058
YouFATAL: xlog flush request 4392/164662F8 is not satisfied --- flushed only to 4392/F000058On 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
1) Exact Postgres version e.g 14.x
Postgresql Version 14. 10
2) Is it community version or fork?
2) Is it community version or fork?
Community version
3) What was the command you used to start the cluster?
3) What was the command you used to start the cluster?
systemctl start postgresql-14
4) Do you have replication/WAL archiving set up?
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/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
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?
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?
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?
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/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
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.