On Tue, Apr 16, 2024 at 7:20 PM Jeff Davis wrote:
> We maintain the invariant:
>
>XLogCtl->logFlushResult <= XLogCtl->logWriteResult
>
> and the non-shared version:
>
>LogwrtResult.Flush <= LogwrtResult.Write
>
> and that the requests don't fall behind the results:
I had missed the fact
On Mon, 2024-04-08 at 15:47 -0400, Robert Haas wrote:
> - I couldn't understand why the "Operate
> XLogCtl->log{Write,Flush}Result with atomics" code was correct when I
> read it.
I reviewed ee1cbe806d. It followed a good process of discussion and
review. It was a bit close to the feature freeze
Hi,
On Saturday, April 13th, 2024 at 12:18 PM, Tomas Vondra wrote:
> On 4/13/24 01:03, David Steele wrote:
> > On 4/12/24 22:12, Tomas Vondra wrote:
> > > On 4/11/24 23:48, David Steele wrote:
> > > > On 4/11/24 20:26, Tomas Vondra wrote:
> > > >
> > > > > FWIW that discussion also mentions
On 4/13/24 21:02, Tomas Vondra wrote:
On 4/13/24 01:23, David Steele wrote:
Even for the summarizer, though, I do worry about the complexity of
maintaining it over time. It seems like it would be very easy to
introduce a bug and have it go unnoticed until it causes problems in the
field. A lot
On 4/13/24 01:23, David Steele wrote:
> On 4/12/24 22:27, Tomas Vondra wrote:
>>
>>
>> On 4/12/24 08:42, David Steele wrote:
>>> On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
> On 4/11/24 10:23, Tom Kincaid wrote:
>>
>> The extensive Beta process
On 4/13/24 01:03, David Steele wrote:
> On 4/12/24 22:12, Tomas Vondra wrote:
>> On 4/11/24 23:48, David Steele wrote:
>>> On 4/11/24 20:26, Tomas Vondra wrote:
>>>
FWIW that discussion also mentions stuff that I think the feature
should
not do. In particular, I don't think the
On 4/12/24 22:27, Tomas Vondra wrote:
On 4/12/24 08:42, David Steele wrote:
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has
On 4/12/24 22:12, Tomas Vondra wrote:
On 4/11/24 23:48, David Steele wrote:
On 4/11/24 20:26, Tomas Vondra wrote:
>>
FWIW that discussion also mentions stuff that I think the feature should
not do. In particular, I don't think the ambition was (or should be) to
make pg_basebackup into a
On Wed, Apr 10, 2024 at 5:27 PM Robert Haas wrote:
>
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> > Transform OR
On 4/12/24 08:42, David Steele wrote:
> On 4/11/24 20:26, Tomas Vondra wrote:
>> On 4/11/24 03:52, David Steele wrote:
>>> On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and
On 4/11/24 23:48, David Steele wrote:
> On 4/11/24 20:26, Tomas Vondra wrote:
>>
>> On 4/11/24 03:52, David Steele wrote:
>>> On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I
On 4/12/24 12:15, Robert Haas wrote:
On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote:
But they'll try because it is a new pg_basebackup feature and they'll
assume it is there to be used. Maybe it would be a good idea to make it
clear in the documentation that significant tooling will be
On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote:
> But they'll try because it is a new pg_basebackup feature and they'll
> assume it is there to be used. Maybe it would be a good idea to make it
> clear in the documentation that significant tooling will be required to
> make it work.
I don't
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I
Hi!
I also worked with this patch and until your explanation I didn’t fully
understand the reasons why it was wrong to have this implementation when
removing duplicate OR expressions.
Thank you, now I understand it!
I agree with explanation of Andrei Lepikhov regarding the fact that
there
On 4/11/24 03:52, David Steele wrote:
> On 4/11/24 10:23, Tom Kincaid wrote:
>>
>> The extensive Beta process we have can be used to build confidence we
>> need in a feature that has extensive review and currently has no known
>> issues or outstanding objections.
>
> I did have objections,
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I did have objections, here [1] and here [2]. I think the complexity,
space
>
> > Yeah, that's an excellent practive, but is why I'm less worried for
> > this feature. The docs at [1] caution about "not to remove earlier
> > backups if they might be needed when restoring later incremental
> > backups". Like Alvaro said, should we insist a bit more about the WAL
> >
On 4/10/24 09:50, Michael Paquier wrote:
On Wed, Apr 10, 2024 at 09:29:38AM +1000, David Steele wrote:
Even so, only keeping WAL for the last backup is a dangerous move in any
case. Lots of things can happen to a backup (other than bugs in the
software) so keeping WAL back to the last full
On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> I have another one that I'm not terribly happy about:
>
> Author: Alexander Korotkov
> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
>
> Transform OR clauses to ANY expression
I realize that this has been reverted now, but
On Tue, Apr 9, 2024 at 1:59 AM Peter Eisentraut wrote:
> On 09.04.24 00:58, Michael Paquier wrote:
> > That's more linked to the fact that I was going silent without a
> > laptop for a few weeks before the end of the release cycle, and a way
> > to say to not count on me, while I was trying to
On Tue, Apr 9, 2024 at 2:47 AM Robert Haas wrote:
>
> - I'm slightly worried about the TID store work (ee1b30f12, 30e144287,
> 667e65aac35), perhaps for no reason. Actually, the results seem really
> impressive,
First, thanks for the complement. I actually suspect if we had this
years ago, it
On Wed, Apr 10, 2024 at 09:29:38AM +1000, David Steele wrote:
> Even so, only keeping WAL for the last backup is a dangerous move in any
> case. Lots of things can happen to a backup (other than bugs in the
> software) so keeping WAL back to the last full (or for all backups) is
> always an
On 4/10/24 01:59, Andrey M. Borodin wrote:
On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
Maybe we should explicitly advise users to not delete that WAL from
their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
>> What exactly is the point of having a NodeTag in the struct though?
>> If you don't need it to be a valid Node, that seems pointless and
>> confusing. We certainly have plenty of other lists that contain
>> plain
On Tue, Apr 9, 2024 at 11:42 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> >> Yeah, that's one of the reasons I'm dubious that the committed
> >> patch was ready.
>
> > While inventing this GUC, I was thinking more about avoiding
> >
On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> >> * OrClauseGroupKey is not a Node type, so why does it have
> >> a NodeTag? I wonder what value will appear in that field,
> >> and what will happen if the struct
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
>> Yeah, that's one of the reasons I'm dubious that the committed
>> patch was ready.
> While inventing this GUC, I was thinking more about avoiding
> regressions rather than about unleashing the full power of this
>
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
>> * OrClauseGroupKey is not a Node type, so why does it have
>> a NodeTag? I wonder what value will appear in that field,
>> and what will happen if the struct is passed to any code
>> that expects real Nodes.
> I
On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> >> I don't know that I'd call it scary exactly, but I do think it
> >> was premature. A week ago there was no consensus that it was
> >> ready to commit, but Alexander
On Tue, Apr 9, 2024 at 8:37 AM Andrei Lepikhov
wrote:
> On 9/4/2024 09:12, Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> > Transform OR clauses to ANY
On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> * OrClauseGroupKey is not a Node type, so why does it have
> a NodeTag? I wonder what value will appear in that field,
> and what will happen if the struct is passed to any code
> that expects real Nodes.
I used that to put both
On Tue, Apr 9, 2024 at 8:55 AM Tom Lane wrote:
> Andrei Lepikhov writes:
> > On 9/4/2024 09:12, Tom Lane wrote:
> >> I have another one that I'm not terribly happy about:
> >> Author: Alexander Korotkov
> >> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >> Transform OR clauses to
On Tue, Apr 9, 2024 at 12:27 PM Tom Lane wrote:
> > Some of the most compelling cases for the transformation will involve
> > path keys. If the transformation enables the optimizer to build a
> > plain index scan (or index-only scan) with useful path keys, then that
> > might well lead to a far
Peter Geoghegan writes:
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
>> I don't know that I'd call it scary exactly, but I do think it
>> was premature. A week ago there was no consensus that it was
>> ready to commit, but Alexander pushed it (or half of it, anyway)
>> despite that.
>
On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> I don't know that I'd call it scary exactly, but I do think it
> was premature. A week ago there was no consensus that it was
> ready to commit, but Alexander pushed it (or half of it, anyway)
> despite that.
Some of the most compelling cases
> On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
>
> Maybe we should explicitly advise users to not delete that WAL from
> their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box Postgres
tools as some bulletproof
On 2024-Apr-09, Stefan Fercot wrote:
> At some point, the only way to really validate a backup is to actually try to
> restore it.
> And if people get encouraged to do that faster thanks to incremental backups,
> they could detect potential issues sooner.
> Ultimately, users will still need
Hi,
On Tuesday, April 9th, 2024 at 2:46 PM, Robert Haas
wrote:
> In all sincerity, I appreciate the endorsement. Basically what's been
> scaring me about this feature is the possibility that there's some
> incurable design flaw that I've managed to completely miss. If it has
> some more
On 9/4/2024 12:55, Tom Lane wrote:
Andrei Lepikhov writes:
* I really, really dislike jamming this logic into prepqual.c,
where it has no business being. I note that it was shoved
into process_duplicate_ors without even the courtesy of
expanding the header comment:
Yeah, I preferred to do
On Tue, Apr 9, 2024 at 7:24 AM Tomas Vondra
wrote:
> I think it's a bit more nuanced, because it's about backups/restore. The
> bug might be subtle, and you won't learn about it until the moment when
> you need to restore (or perhaps even long after that). At which point
> "You might have taken
On 4/9/24 01:33, Michael Paquier wrote:
> On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
>> I don't feel too particularly worried about this. Yes, backups are super
>> important because it's often the only thing you have left when things go
>> wrong, and the incremental aspect is
On 09.04.24 00:58, Michael Paquier wrote:
That's more linked to the fact that I was going silent without a
laptop for a few weeks before the end of the release cycle, and a way
to say to not count on me, while I was trying to keep my room clean to
avoid noise for others who would rush patches.
Andrei Lepikhov writes:
> On 9/4/2024 09:12, Tom Lane wrote:
>> I have another one that I'm not terribly happy about:
>> Author: Alexander Korotkov
>> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
>> Transform OR clauses to ANY expression
>> * What the medical community would call
On 9/4/2024 09:12, Tom Lane wrote:
I have another one that I'm not terribly happy about:
Author: Alexander Korotkov
Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
Transform OR clauses to ANY expression
Because I'm primary author of the idea, let me answer.
I don't
Robert Haas writes:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
> Hi,
> I'm moving this topic to a new thread for better visibility and less
On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
> I don't feel too particularly worried about this. Yes, backups are super
> important because it's often the only thing you have left when things go
> wrong, and the incremental aspect is all new. The code I've seen while
> doing the
On 4/8/24 21:47, Robert Haas wrote:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
>
> ...
>
> - Incremental backup could have all sorts of
On Tue, Apr 09, 2024 at 09:35:00AM +1200, Thomas Munro wrote:
> Mr Paquier this year announced his personal code freeze a few weeks
> back on social media, which seemed like an interesting idea I might
> adopt. Perhaps that is what some other people are doing without
> saying so, and perhaps the
On Tue, Apr 9, 2024 at 7:47 AM Robert Haas wrote:
> - The streaming read API stuff was all committed very last minute. I
> think this should have been committed much sooner. It's probably not
> going to break the world; it's more likely to have performance
> consequences. But if it had gone in
51 matches
Mail list logo
