Greetings,
* Greg Stark (st...@mit.edu) wrote:
> Including the pre-truncation length in the wal record is the obviously
> solid approach and I none of the below is a good substitution for it.
I tend to agree with the items mentioned in Andres's recent email on
this thread too in terms of
On Tue, May 9, 2023 at 5:14 AM Aleksander Alekseev
wrote:
> > I admit I haven't done the legwork to nail down a test
> > case where everything comes together just right to show user-visible
> > breakage, but your success in finding one where it doesn't is no proof
> > of anything.
>
>
Including the pre-truncation length in the wal record is the obviously
solid approach and I none of the below is a good substitution for it.
But
On Tue, 25 Apr 2023 at 13:30, Andres Freund wrote:
>
> It isn't - but the alternatives aren't great either. It's not that easy to hit
> this
Hi Robert,
> I admit I haven't done the legwork to nail down a test
> case where everything comes together just right to show user-visible
> breakage, but your success in finding one where it doesn't is no proof
> of anything.
Respectfully, what made you think this was my intention?
Quite the
Hi,
On 2023-04-25 10:28:58 -0700, Andres Freund wrote:
> On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> > On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> > > What we've discussed somewhere in the past is to always truncate N+1 when
> > > creating the first page in N. I.e. if we extend
Hi,
On 2023-05-08 08:57:08 -0400, Robert Haas wrote:
> On Mon, May 1, 2023 at 12:54 PM Aleksander Alekseev
> wrote:
> > So I'm still unable to reproduce the described scenario, at least on PG16.
>
> Well, that proves that either (1) the scenario that I described is
> impossible for some unknown
On Mon, May 1, 2023 at 12:54 PM Aleksander Alekseev
wrote:
> So I'm still unable to reproduce the described scenario, at least on PG16.
Well, that proves that either (1) the scenario that I described is
impossible for some unknown reason or (2) something is wrong with your
test scenario. I bet
Hi,
> I think that to reproduce the scenario, you want the truncate to happen in
> its own checkpoint cycle.
OK, let's try this again.
In order to effectively disable the checkpointer I added the following lines
to postgresql.conf:
```
checkpoint_timeout = 3600
max_wal_size = 100G
```
I'm
Hi,
On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> > What we've discussed somewhere in the past is to always truncate N+1 when
> > creating the first page in N. I.e. if we extend into 23456.1, we truncate
> > 23456.2 to 0 blocks. As far
On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> What we've discussed somewhere in the past is to always truncate N+1 when
> creating the first page in N. I.e. if we extend into 23456.1, we truncate
> 23456.2 to 0 blocks. As far as I can tell, that'd solve this issue?
Yeah, although
Hi,
On 2023-04-21 09:42:57 -0400, Robert Haas wrote:
> Apologies if this has already been discussed someplace, but I couldn't
> find a previous discussion. It seems to me that base backups are
> broken in the face of a concurrent truncation that reduces the number
> of segments in a relation.
I
On Fri, Apr 21, 2023 at 5:19 PM Aleksander Alekseev
wrote:
> Naturally the database is consistent too. So it looks like the
> recovery protocol worked as expected after all, at least in the
> upcoming PG16 and this specific scenario.
>
> Did I miss anything? If not, perhaps we should just update
Hi,
> > Oh, I see. If the process will be killed this perhaps is not going to
> > happen. Whether this can happen if we pull the plug from the machine
> > is probably a design implementation of the particular filesystem and
> > whether it's journaled.
>
> Right. I mentioned that scenario in the
On Fri, Apr 21, 2023 at 10:56 AM Aleksander Alekseev
wrote:
> > Assuming this is the case perhaps we can reduce the scenario and
> > consider this simpler one:
> >
> > 1. The table is truncated
> > 2. The DBMS is killed before making a checkpoint
> > 3. We are in recovery and presumably see a
Hi again,
> Assuming this is the case perhaps we can reduce the scenario and
> consider this simpler one:
>
> 1. The table is truncated
> 2. The DBMS is killed before making a checkpoint
> 3. We are in recovery and presumably see a pair of 0.5 Gb segments
>
> Or can't we?
Oh, I see. If the
Hi,
Just a quick observation:
> basebackup.c's theory about relation truncation is that it doesn't
> really matter because WAL replay will fix things up. But in this case,
> I don't think it will, because WAL replay relies on the above
> invariant holding.
Assuming this is the case perhaps we
Hi,
Apologies if this has already been discussed someplace, but I couldn't
find a previous discussion. It seems to me that base backups are
broken in the face of a concurrent truncation that reduces the number
of segments in a relation.
Suppose we have a relation that is 1.5GB in size, so that
17 matches
Mail list logo
