On Sun, Oct 17, 2021 at 04:43:15PM -0500, Justin Pryzby wrote:
> On Sun, Aug 15, 2021 at 09:44:55AM -0500, Justin Pryzby wrote:
> > On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote:
> > > 1. Fix FullXidRelativeTo to be a little less trusting. It'd
> > > probably be sane to make it return F
On Sun, Aug 15, 2021 at 09:44:55AM -0500, Justin Pryzby wrote:
> On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote:
> > 1. Fix FullXidRelativeTo to be a little less trusting. It'd
> > probably be sane to make it return FirstNormalTransactionId
> > when it'd otherwise produce a wrapped-aroun
On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote:
> 1. Fix FullXidRelativeTo to be a little less trusting. It'd
> probably be sane to make it return FirstNormalTransactionId
> when it'd otherwise produce a wrapped-around FullXid, but is
> there any situation where we'd want it to throw an
gt;From 30204d85005d6288d2dc93bcd28ff4fb2454a703 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sun, 16 May 2021 16:23:02 -0400
Subject: [PATCH 1/3] prion failed with ERROR: missing chunk number 0 for toast
value 14334 in pg_toast_2619
It also seems like some assertions in procarray.c would be a
On Tue, May 18, 2021 at 01:04:18PM +0200, Drouvot, Bertrand wrote:
> On 5/17/21 8:56 PM, Andres Freund wrote:
>> On 2021-05-17 20:14:40 +0200, Drouvot, Bertrand wrote:
>>> I was also wondering if:
>>>
>>> * We should keep the old behavior in case pg_resetwal -x is being used
>>> without -u?
Hi,
On 2021-05-17 20:14:40 +0200, Drouvot, Bertrand wrote:
> FWIW a patch proposal to copy the oldest unfrozen XID during pg_upgrade (it
> adds a new (- u) parameter to pg_resetwal) has been submitted a couple of
> weeks ago, see: https://commitfest.postgresql.org/33/3105/
I'll try to look at it
On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote:
> And the reason oldestXID contains that is that pg_upgrade applied
> pg_resetwal, which does this:
>
> /*
> * For the moment, just set oldestXid to a value that will force
> * immediate autovacuum-for-w
Hi,
On 2021-05-16 18:42:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Why would it not be safe?
>
> I'm just wondering about the catalog tuples set up by pg_upgrade
> itself. If they're all frozen then they probably don't matter to
> this, but it might take some thought.
There shouldn'
Andres Freund writes:
> On 2021-05-16 18:21:21 -0400, Tom Lane wrote:
>> Hm, yeah. I'm not sure if transferring the value forward from the
>> old cluster is entirely safe, but if it is, that seems like a
>> promising route to a fix. (We should still have more sanity checking
>> around the Global
Hi,
On 2021-05-16 18:21:21 -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Sun, May 16, 2021 at 1:23 PM Tom Lane wrote:
> >> And the reason oldestXID contains that is that pg_upgrade applied
> >> pg_resetwal, which does this:
> >> * For the moment, just set oldestXid to a value that will
Hi,
On 2021-05-16 16:23:02 -0400, Tom Lane wrote:
> And the reason oldestXID contains that is that pg_upgrade applied
> pg_resetwal, which does this:
>
> /*
> * For the moment, just set oldestXid to a value that will force
> * immediate autovacuum-for-wraparou
Peter Geoghegan writes:
> On Sun, May 16, 2021 at 1:23 PM Tom Lane wrote:
>> And the reason oldestXID contains that is that pg_upgrade applied
>> pg_resetwal, which does this:
>> * For the moment, just set oldestXid to a value that will force
>> * immediate autovacuum-for-wraparound.
> This same
On Sun, May 16, 2021 at 1:23 PM Tom Lane wrote:
> it gets an insane value:
>
> oldestfxid 18446744071709568230, latest_completed 16613, oldestxid 2294983910
>
> And the reason oldestXID contains that is that pg_upgrade applied
> pg_resetwal, which does this:
>
> /*
> * For the mom
I wrote:
> What I do have that's new is that *I can reproduce it*, at long last.
I see what's happening, but I'm not quite sure where we should fix it.
> I do not have a lot of idea why, but I see something that is
> probably a honkin' big clue:
> 2021-05-15 17:28:05.965 EDT [2469444] LOG: HeapT
Heikki Linnakangas writes:
> After my commit c532d15ddd to split up copy.c, buildfarm animal "prion"
> failed in pg_upgrade
> (https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-11-23%2009%3A23%3A16):
prion's continued to fail, rarely, in this same way:
https://buildfarm.pos
Hi,
After my commit c532d15ddd to split up copy.c, buildfarm animal "prion"
failed in pg_upgrade
(https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-11-23%2009%3A23%3A16):
Upgrade Complete
Optimizer statistics are not transferred by pg_upgrade so,
once you
16 matches
Mail list logo
