Dear Michael,
> I'd suggest to keep them separate across multiple scripts, where they
> hold meaning, as one failure may get hidden by the other.
> track_commit_timestamp makes sense in the test module commit_ts, we
> should select a second location for transaction_timeout if we keep it
> at the e
On Wed, Jul 09, 2025 at 02:39:22AM +, Hayato Kuroda (Fujitsu) wrote:
> +# Some GUCs like track_commit_timestamp cannot be set to non-default value in
> +# bootstrap mode becasue they may cause crash. Ensure settings can be surely
> +# ignored.
> +command_ok(
> + [
> + 'initd
Dear Fujii-san, Andy,
> Shouldn't we also add a TAP test to verify that initdb works correctly
> with GUCs marked as GUC_NOT_IN_BOOTSTRAP?
Another place we can put the test is 001_initdb.pl, like:
```
--- a/src/bin/initdb/t/001_initdb.pl
+++ b/src/bin/initdb/t/001_initdb.pl
@@ -331,4 +331,15 @@
Fujii Masao writes:
> Shouldn't we also add a TAP test to verify that initdb works correctly
> with GUCs marked as GUC_NOT_IN_BOOTSTRAP?
After revert 5a6c39b6d, the test case could be as simply as below: I
also tested this change. Just FYI.
modified src/test/modules/commit_ts/t/001_base.pl
@@
On Sat, Jul 05, 2025 at 02:00:07PM -0400, Tom Lane wrote:
> Here's a fleshed-out implementation of Hayato-san's idea. I've
> not done anything about reverting 5a6c39b6d, nor have I done any
> checks to see if there are other GUCs we ought to mark similarly.
> (But at this point I'd be prepared to
On 2025/07/06 3:00, Tom Lane wrote:
I wrote:
Fujii Masao writes:
Or GUC ignore_system_indexes also should be treated in the same way
as transaction_timeout?
Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap
too. I've not done any research about what other GUCs can brea
> I wrote:
>> Fujii Masao writes:
>>> Or GUC ignore_system_indexes also should be treated in the same way
>>> as transaction_timeout?
>
>> Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap
>> too. I've not done any research about what other GUCs can break
>> initdb, but now I
I wrote:
> Fujii Masao writes:
>> Or GUC ignore_system_indexes also should be treated in the same way
>> as transaction_timeout?
> Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap
> too. I've not done any research about what other GUCs can break
> initdb, but now I'm starting
Fujii Masao writes:
> On 2025/07/05 2:17, Tom Lane wrote:
>> Oh, good point. But there doesn't seem to be any ill effect from
>> making BootstrapModeMain set BootstrapProcessing a bit earlier.
> Maybe. But I noticed that your patch also moves the line "IgnoreSystemIndexes
> = true;"
> earlier.
On 2025/07/05 2:17, Tom Lane wrote:
Fujii Masao writes:
On 2025/07/05 0:30, Tom Lane wrote:
As I remarked in the other thread, I don't like inventing a different
solution for each GUC. So if there are even two that need something
done, I think Hayato-san's idea has merit.
This code seem
Michael Paquier writes:
> This is assuming that the default value assigned to a GUC will always
> take the right decision in the bootstrap case, which is perhaps OK
> anyway in most cases, or we would know about that during initdb.
Yeah, I've been wondering about whether the code ought to accept
On Fri, Jul 04, 2025 at 11:30:17AM -0400, Tom Lane wrote:
> As I remarked in the other thread, I don't like inventing a different
> solution for each GUC. So if there are even two that need something
> done, I think Hayato-san's idea has merit.
>
> + /*
> + * Certain GUCs aren't safe to e
Fujii Masao writes:
> On 2025/07/05 0:30, Tom Lane wrote:
>> As I remarked in the other thread, I don't like inventing a different
>> solution for each GUC. So if there are even two that need something
>> done, I think Hayato-san's idea has merit.
> This code seems to assume that the processing
On 2025/07/05 0:30, Tom Lane wrote:
Fujii Masao writes:
On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote:
If more GUCs were found which cannot be set during the bootstrap mode, how about
introducing a new flag like GUC_DEFAULT_WHILE_BOOTSTRAPPING for GUC variables?
If the flag is set all
Fujii Masao writes:
> On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote:
>> If more GUCs were found which cannot be set during the bootstrap mode, how
>> about
>> introducing a new flag like GUC_DEFAULT_WHILE_BOOTSTRAPPING for GUC
>> variables?
>> If the flag is set all setting can be ignored w
On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
By the way, although it's a separate issue, I noticed that running
initdb -c transaction_timeout=1 causes an assertion failure:
I feel it may be able to discuss in other places
OK, I've started a new thread for this issu
Dear Fujii-san,
> By the way, although it's a separate issue, I noticed that running
> initdb -c transaction_timeout=1 causes an assertion failure:
I feel it may be able to discuss in other places but let me say one comment.
> running bootstrap script ... TRAP: failed Assert("all_timeouts_initia
On Fri, Jul 04, 2025 at 01:26:19AM +0900, Fujii Masao wrote:
> On 2025/07/03 22:31, Andy Fan wrote:
>> I checked the fix suggested by Hayato, I think his patch is better than
>> me because his patch checks at the startup time while my patch checks at
>> each time of RecordTransactionCommit. So v3 t
On 2025/07/03 22:31, Andy Fan wrote:
"Hayato Kuroda (Fujitsu)" writes:
Dear Michael, Fujii-san,
Ah, indeed, so it was reported a couple of months ago. I am not sure
that the argument about all the other GUCs potentially impacted holds
much value; we are talking about a specific code path
"Hayato Kuroda (Fujitsu)" writes:
> Dear Michael, Fujii-san,
>
>> Ah, indeed, so it was reported a couple of months ago. I am not sure
>> that the argument about all the other GUCs potentially impacted holds
>> much value; we are talking about a specific code path.
>
> Yeah, I did report but sad
Dear Michael, Fujii-san,
> Ah, indeed, so it was reported a couple of months ago. I am not sure
> that the argument about all the other GUCs potentially impacted holds
> much value; we are talking about a specific code path.
Yeah, I did report but sadly it was missed by others :-(. To clarify,
T
On Thu, Jul 03, 2025 at 09:48:40AM +0900, Fujii Masao wrote:
> Is this the same issue that was discussed in [1]?
>
> [1]
> https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com
Ah, indeed, so it was reported a couple of months ago. I am not sure
th
On 2025/07/02 9:38, Andy Fan wrote:
Hi,
When working with the commit_ts module, I find the following issue:
After configure with --enable-cassert option, then initdb with:
initdb -D x2 -c track_commit_timestamp=on
Then we can get the following core dump:
Is this the same issue that was
On Wed, Jul 02, 2025 at 09:03:35AM +, Bertrand Drouvot wrote:
> +* Don't bother to record commit_ts for Booststrap mode.
>
> typo: s/Booststrap/Bootstrap/
>
> Also, grep on "Bootstrap mode" and "bootstrap mode" gives much more
> occurrences
> for the later, so maybe use "bootstrap mo
Hi,
On Wed, Jul 02, 2025 at 01:38:18AM +, Andy Fan wrote:
> Michael Paquier writes:
>
> Hi,
>
> > On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
> >> However this is not true in BootstrapMode, this failure is masked by
> >> default because TransactionTreeSetCommitTsData returns f
Michael Paquier writes:
Hi,
> On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
>> However this is not true in BootstrapMode, this failure is masked by
>> default because TransactionTreeSetCommitTsData returns fast when
>> track_commit_timestamp is off.
>
> Agreed that there is no point
Hi,
When working with the commit_ts module, I find the following issue:
After configure with --enable-cassert option, then initdb with:
initdb -D x2 -c track_commit_timestamp=on
Then we can get the following core dump:
0 in raise of /lib/x86_64-linux-gnu/libc.so.6
1 in abort of /lib/x86_64-
On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
> However this is not true in BootstrapMode, this failure is masked by
> default because TransactionTreeSetCommitTsData returns fast when
> track_commit_timestamp is off.
Agreed that there is no point in registering a commit timestamp in
th
28 matches
Mail list logo
