Hello Robert,
17.10.2023 17:39, Robert Haas wrote:
On Tue, Oct 17, 2023 at 4:57 AM Aleksander Alekseev
wrote:
v11-0001 and v11-0002 LGTM too.
Cool. Seems we are all in agreement, so committed these. Thanks!
Please look at the following sentence added by the commit:
...
to issu
On Tue, Oct 17, 2023 at 9:39 PM Robert Haas wrote:
>
> Cool. Seems we are all in agreement, so committed these. Thanks!
Thank you for getting this across the finish line!
On Tue, Oct 17, 2023 at 4:57 AM Aleksander Alekseev
wrote:
> v11-0001 and v11-0002 LGTM too.
Cool. Seems we are all in agreement, so committed these. Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
> > LGTM, except for one small detail: I noticed that you misspelled
> > "translations" in the commit message.
>
> Oops. Fixed locally.
v11-0001 and v11-0002 LGTM too. IMO "to assign a XID" sounds better
than "to generate a XID".
--
Best regards,
Aleksander Alekseev
On Mon, Oct 16, 2023 at 3:46 PM Peter Geoghegan wrote:
> On Mon, Oct 16, 2023 at 11:06 AM Robert Haas wrote:
> > I propose to commit these changes only to master. I have included a
> > fairly long paragraph about that in the commit message for 0002.
>
> LGTM, except for one small detail: I notice
On Mon, Oct 16, 2023 at 11:06 AM Robert Haas wrote:
> I propose to commit these changes only to master. I have included a
> fairly long paragraph about that in the commit message for 0002.
LGTM, except for one small detail: I noticed that you misspelled
"translations" in the commit message.
Than
On Fri, Oct 13, 2023 at 5:03 AM Aleksander Alekseev
wrote:
> > Thanks for working on this. I will be relieved once this is finally
> > taken care of.
>
> +1, and many thanks for your attention to the patchset and all the details!
Cool. I committed that and back-patched to v14, and here's the rest
Hi,
> Those all make sense to me.
>
> > [...]
>
> Of course. Your general approach seems wise.
>
> Thanks for working on this. I will be relieved once this is finally
> taken care of.
+1, and many thanks for your attention to the patchset and all the details!
--
Best regards,
Aleksander Aleksee
On Thu, Oct 12, 2023 at 1:10 PM Robert Haas wrote:
> On Thu, Oct 12, 2023 at 12:01 PM Peter Geoghegan wrote:
> > No objections from me.
>
> Here is a doc-only patch that I think could be back-patched as far as
> emergency mode exists. It combines all of the wording changes to the
> documentation
On Thu, Oct 12, 2023 at 12:01 PM Peter Geoghegan wrote:
> No objections from me.
Here is a doc-only patch that I think could be back-patched as far as
emergency mode exists. It combines all of the wording changes to the
documentation from v1-v3 of the previous version, but without changing
the me
On Thu, Oct 12, 2023 at 8:54 AM Robert Haas wrote:
> - I find the use of the word "generate" in error messages slightly
> odd. I think it's reasonable given the existing precedent, but the
> word I would have picked is "assign", which I see is what Aleksander
> actually had in v1. How would people
On Wed, Oct 4, 2023 at 8:07 AM Peter Geoghegan wrote:
> If you're willing to take over as committer here, I'll let the issue
> of backpatching go.
>
> I only ask that you note why you've not backpatched in the commit message.
Will do, but see also the last point below.
I have looked over these p
On Mon, Oct 2, 2023 at 1:25 PM Robert Haas wrote:
> I'm also pretty happy with these patches and would like to see at
> least 0001 and 0002 committed, and probably 0003 as well. I am,
> however, -1 on back-patching. Perhaps that is overly cautious, but I
> don't like changing existing messages in
On Mon, Oct 2, 2023 at 11:52 AM Pavel Borisov wrote:
> FWIW I think the patch is still in good shape and worth to be committed.
I'm also pretty happy with these patches and would like to see at
least 0001 and 0002 committed, and probably 0003 as well. I am,
however, -1 on back-patching. Perhaps t
Hi!
On Mon, 2 Oct 2023 at 03:34, Peter Geoghegan wrote:
>
> On Sun, Oct 1, 2023 at 11:46 AM Peter Eisentraut wrote:
> > What is the status of this patch discussion now? It had been set as
> > Ready for Committer for some months. Do these recent discussions
> > invalidate that? Does it need mo
On Sun, Oct 1, 2023 at 11:46 AM Peter Eisentraut wrote:
> What is the status of this patch discussion now? It had been set as
> Ready for Committer for some months. Do these recent discussions
> invalidate that? Does it need more discussion?
I don't think that recent discussion invalidated any
On 20.09.23 05:41, Peter Geoghegan wrote:
On Sun, May 14, 2023 at 6:06 PM Peter Geoghegan wrote:
BTW, Google cloud already just instruct their users to ignore the
xidStopLimit HINT about single user mode:
https://cloud.google.com/sql/docs/postgres/txid-wraparound
I read this just today, and
On Sun, May 14, 2023 at 6:06 PM Peter Geoghegan wrote:
> BTW, Google cloud already just instruct their users to ignore the
> xidStopLimit HINT about single user mode:
>
> https://cloud.google.com/sql/docs/postgres/txid-wraparound
I read this just today, and was reminded of this thread:
https://c
On Fri, May 12, 2023 at 9:14 PM John Naylor
wrote:
> Attached is v9, which is mostly editing the steps for restoring normal
> operation, which are in 0003 now but will be squashed into 0002. Comments to
> polish the wording welcome.
I'll try to get you more feedback on this soon.
BTW, Google c
Attached is v9, which is mostly editing the steps for restoring normal
operation, which are in 0003 now but will be squashed into 0002. Comments
to polish the wording welcome.
--
John Naylor
EDB: http://www.enterprisedb.com
From 0e9d6ea72216b196d37de4629736c0cf34e7cd5c Mon Sep 17 00:00:00 2001
Fr
On Thu, May 4, 2023 at 12:59 AM Peter Geoghegan wrote:
> I'd quite like to drop this topic, and get on with the work at hand.
I'd be grateful, and the other points you made are, of course, valid.
--
John Naylor
EDB: http://www.enterprisedb.com
On Wed, May 3, 2023 at 12:30 AM John Naylor
wrote:
> I went to go find the phrase that I thought I was reacted to, and ...
> nothing. I am also baffled. My comment was inexcusable.
I'd quite like to drop this topic, and get on with the work at hand.
But before I do that, I ask you to consider o
On Wed, May 3, 2023 at 10:04 AM Peter Geoghegan wrote:
>
> That's not the only reason, though. I also genuinely don't have the
> foggiest notion what was behind what you said. In particular, this
> part still makes zero sense to me:
>
> "Claim that others are holding you back, and then try to move
On Tue, May 2, 2023 at 6:46 PM John Naylor wrote:
> It might least be good for readability to gloss over the warning and only
> quote the MXID limit error message, but we'll have to see how it looks.
Apparently you expect me to join you in pretending that you didn't
lambast my review on this thr
On Tue, May 2, 2023 at 9:55 AM Peter Geoghegan wrote:
>
> On Mon, May 1, 2023 at 5:34 AM John Naylor
wrote:
> > 0003 is now a quick-and-dirty attempt at that, only in the docs. The
MXID part is mostly copy-pasted from the XID part, just to get something
together. I'd like to abbreviate that some
On Mon, May 1, 2023 at 7:55 PM Peter Geoghegan wrote:
> Obviously there are certain things that can hold back OldestMXact by a
> wildly excessive amount. But I don't think that there is anything that
> can hold back OldestMXact by a wildly excessive amount that won't more
> or less do the same thi
On Mon, May 1, 2023 at 5:34 AM John Naylor wrote:
> Well, since you have a placeholder "xidStopLimit mode" in your other patch,
> I'll confine my response to there. Inventing "modes" seems like an awkward
> thing to backpatch, not to mention moving the goalposts. My modest goal here
> is quite
On Mon, May 1, 2023 at 2:30 AM Peter Geoghegan wrote:
>
> On Sat, Apr 29, 2023 at 7:30 PM John Naylor
> wrote:
> > How about
> >
> > -HINT: To avoid a database shutdown, [...]
> > +HINT: To prevent XID exhaustion, [...]
> >
> > ...and "MXID", respectively? We could explain in the docs that vacu
On Sat, Apr 29, 2023 at 7:30 PM John Naylor
wrote:
> How about
>
> -HINT: To avoid a database shutdown, [...]
> +HINT: To prevent XID exhaustion, [...]
>
> ...and "MXID", respectively? We could explain in the docs that vacuum and
> read-only queries still work "when XIDs have been exhausted", e
On Sun, Apr 30, 2023 at 4:15 AM Peter Geoghegan wrote:
>
> On Sat, Apr 29, 2023 at 1:09 AM John Naylor
> wrote:
> > I made some small changes and wrote a suitably comprehensive commit
message. I separated the possible uses for single-user mode into a separate
paragraph in the "Note:" , moved the
On Sat, Apr 29, 2023 at 1:09 AM John Naylor
wrote:
> Looks good to me.
I'm strongly in favor of this. It's most unfortunate that it took this long.
> I've just made some small edits for v7 and wrote a commit message to explain
> how we got here. This can be backpatched all the way, as it's simp
On Tue, Apr 4, 2023 at 8:08 PM Aleksander Alekseev
wrote:
> [v6]
0001:
Looks good to me. I've just made some small edits for v7 and wrote a commit
message to explain how we got here. This can be backpatched all the way, as
it's simply a correction. I do want to test on v11 first just for
complet
On Tue, 4 Apr 2023 at 17:08, Aleksander Alekseev
wrote:
>
> Hi,
>
> > The proposed changes are in patchset v5.
>
> Pavel, John, thanks for your feedback.
>
> > I've looked into the patches v4.
> > For 0001:
> > I think long "not accepting commands that generate" is equivalent to
> > more concise "
Hi,
> The proposed changes are in patchset v5.
Pavel, John, thanks for your feedback.
> I've looked into the patches v4.
> For 0001:
> I think long "not accepting commands that generate" is equivalent to
> more concise "can't generate".
Frankly I don't think this is a good change for this parti
Hi!
I've looked into the patches v4.
For 0001:
I think long "not accepting commands that generate" is equivalent to
more concise "can't generate".
For 0003:
I think double mentioning of Vacuum at each errhist i.e.: "Execute a
database-wide VACUUM in that database" and "...or run a manual
database-
On Mon, Apr 3, 2023 at 7:33 PM Aleksander Alekseev
wrote:
> > Yes, the exact same text as it appeared in the [2] thread above, which
prompted Robert's comment I quoted. I take the point to mean: All of these
things need to be taken care of *first*, before vacuuming, so the hint
should order thing
Hi John,
Many thanks for all the great feedback!
> Okay, the changes look good. To go further, I think we need to combine into
> two patches, one with 0001-0003 and one with 0004:
>
> 1. Correct false statements about "shutdown" etc. This should contain changes
> that can safely be patched all
On Tue, Mar 21, 2023 at 6:44 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
Okay, the changes look good. To go further, I think we need to combine into
two patches, one with 0001-0003 and one with 0004:
1. Correct false statements about "shutdown" etc. This should contain
changes that
Hi John,
> Thanks for picking up this badly-needed topic again!
Many thanks for the review!
> 0001:
>
> +In this condition the system can still execute read-only transactions.
> +The active transactions will continue to execute and will be able to
> +commit.
>
> This is ambiguous. I'
Thanks for picking up this badly-needed topic again! I was irresponsible
last year and let it fall off my radar, but I'm looking at the patches, as
well as revisiting discussions from the last four (!?) years that didn't
lead to action.
0001:
+In this condition the system can still execute re
On Mon, Jan 16, 2023 at 03:50:57PM +0300, Aleksander Alekseev wrote:
> Hi hackers,
>
> > The proposed patchset changes the documentation and the error messages
> > accordingly, making them less misleading. 0001 corrects the
> > documentation but doesn't touch the code. 0002 and 0003 correct the
>
Hi hackers,
> The proposed patchset changes the documentation and the error messages
> accordingly, making them less misleading. 0001 corrects the
> documentation but doesn't touch the code. 0002 and 0003 correct the
> messages shown when approaching xidWrapLimit and xidWarnLimit
> accordingly.
A
Hi hackers,
While playing with 64-bit XIDs [1] my attention was drawn by the
following statement in the docs [2]:
"""
If these warnings are ignored, the system will shut down and refuse to
start any new transactions once there are fewer than three million
transactions left until wraparound.
"""
43 matches
Mail list logo
