Re: initdb -c "track_commit_timestamp=on" crashes in case of debug build

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: initdb -c "track_commit_timestamp=on" crashes in case of debug build
Date: 2025-01-06 14:41:54
Message-ID: a16ca682-c10f-4e2c-9734-c742c9319cda@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.01.25 14:14, Hayato Kuroda (Fujitsu) wrote:
> While working on another thread I found $subject. I've tested only on master,
> but I doubt this could happen even on PG16 and 17. You can reproduce by:
> ```
> $ initdb -D data -c "track_commit_timestamp=on"
> ...
> child process was terminated by signal 6: Aborted
> initdb: removing data directory "data"
> ```
>
> Back-trace I got is shown in [1].
>
> IIUC the crash was caused at TransactionIdSetCommitTs(), and the primal reason was that
> commit_ts module tried to store the bootstrap transaction.
>
> In the first place I'm not sure we want to fix this because this happens only for
> the debug mode... but if needed, the easiest way is not to activate the commit_ts
> in the bootstrap mode. I think this fix is enough because pg_last_committed_xact()
> and TransactionIdGetCommitTsData() won't seek the un-normal xid.
> Attached patch was created based on the idea.

Yes, this was previously reported [0] but nothing was done about it. We
just need to find some place to "do nothing" in bootstrap mode to avoid
the crash. Your patch seems ok to me for that.

[0]:
https://www.postgresql.org/message-id/8a8fda29-5a68-ba68-a2ff-8d17602b3762@enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-01-06 14:49:22 Re: Fwd: Re: A new look at old NFS readdir() problems?
Previous Message Tom Lane 2025-01-06 14:27:16 Re: Temporary Views Cleanup Issue