On 2025-03-31 12:51, Fujii Masao wrote:
I had the same thought during our off-list discussion. However,
after reviewing the recovery code - such as recoveryStopsBefore(),
which checks whether a consistent state is reached - I now believe
the manual’s definition of a consistent state may be incorr
On 2025-04-01 01:12, Fujii Masao wrote:
On 2025/03/31 22:45, Yugo Nagata wrote:
I prefer this approach clarifying that consistency and subtransaction
overflow
are separate concepts in the documentation.
Here are minor comments on the patch:
Thanks for the review!
- case CAC_NOTC
On Mon, 31 Mar 2025 12:51:06 +0900
Fujii Masao wrote:
>
>
> On 2025/03/28 0:13, torikoshia wrote:
> > On 2025-03-27 11:06, torikoshia wrote:
> >> Hi,
> >>
> >> I had another off-list discussion with Fujii-san, and according to the
> >> following manual[1], it seems that a transaction with an ov
On 2025-04-02 15:21, Fujii Masao wrote:
On 2025/04/01 20:54, torikoshia wrote:
Thank you for updating the patch!
LGTM.
I've pushed the patch. Thanks!
Thanks a lot!
I feel like changing the status to 'Ready for Committer', but since
Nagata-san may have additional comments, I'm leaving it a
On 2025/04/01 20:54, torikoshia wrote:
Thank you for updating the patch!
LGTM.
I've pushed the patch. Thanks!
I feel like changing the status to 'Ready for Committer', but since Nagata-san
may have additional comments, I'm leaving it as 'Needs Review'.
If any issues arise, let's contin
On 2025/03/31 22:45, Yugo Nagata wrote:
I prefer this approach clarifying that consistency and subtransaction overflow
are separate concepts in the documentation.
Here are minor comments on the patch:
Thanks for the review!
- case CAC_NOTCONSISTENT:
- if (EnableHo
On 2025/03/31 22:44, torikoshia wrote:
Here are some comments on the documentation.
Thanks for the review!
The following description in high-availability.sgml also seems to misuse the
word 'consistent':
When the parameter is set to true on a
standby server, it will begin accepting
On 2025/03/28 0:13, torikoshia wrote:
On 2025-03-27 11:06, torikoshia wrote:
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consiste
On 2025-03-27 11:06, torikoshia wrote:
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consistent state can also be delayed in the prese
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consistent state can also be delayed in the presence of
both of these conditions:
On 2025/03/24 23:18, torikoshia wrote:
On 2025-03-24 00:08, Fujii Masao wrote:
Do you also think the errhint message is unnecessary?
I agree with your idea to add a description of the overflowed subtransaction in
the manual, but I'm not sure all users will be able to find it.
Some people m
On 2025-03-24 00:08, Fujii Masao wrote:
Do you also think the errhint message is unnecessary?
I agree with your idea to add a description of the overflowed
subtransaction in the manual, but I'm not sure all users will be able
to find it.
Some people may not understand what needs to be done to
On 2025/03/21 21:29, torikoshia wrote:
Hi,
On 2025-03-21 02:15, Fujii Masao wrote:
Thanks for your review!
Personally, I feel 1st patch may be sufficient, but I would appreciate any
feedback.
Agreed.
- errdetail("Consistent recovery state has not been yet
re
Hi,
On 2025-03-21 02:15, Fujii Masao wrote:
Thanks for your review!
Personally, I feel 1st patch may be sufficient, but I would appreciate
any feedback.
Agreed.
- errdetail("Consistent recovery state has not been yet
reached.")));
+
On 2025/03/12 21:57, torikoshia wrote:
Hi,
After an off-list discussion with Fujii-san, I'm now trying to modify the
following message that is output when a client attempts to connect instead of
changing the log level as the original proposal:
$ psql: error: connection to server at "loc
Hi,
After an off-list discussion with Fujii-san, I'm now trying to modify
the following message that is output when a client attempts to connect
instead of changing the log level as the original proposal:
$ psql: error: connection to server at "localhost" (::1), port 5433
failed: FATAL: t
On 2025-03-04 03:17, Fujii Masao wrote:
Agreed and I feel that a message suggesting something like "check if
there are any overflowing transactions on the primary side" would make
it useful.
I’m wondering if this message might still be confusing for users.
Would they immediately understand wh
On 2025/03/04 0:20, torikoshia wrote:
On 2025-03-03 13:10, Fujii Masao wrote:
Thanks for your comments!
On 2025/02/03 22:35, torikoshia wrote:
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection t
On 2025-03-03 13:10, Fujii Masao wrote:
Thanks for your comments!
On 2025/02/03 22:35, torikoshia wrote:
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection to server at "localhost" (::1), port 5433
On 2025/02/03 22:35, torikoshia wrote:
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection to server at "localhost" (::1), port 5433 failed:
FATAL: the database system is not yet accepting connectio
20 matches
Mail list logo
