> On 16 May 2024, at 19:47, Tom Lane wrote:
> Yeah, it's not worth working harder than this. I do see one typo
> in your comment: s/supported then/supported when/. LGTM otherwise.
Thanks for review, I've pushed this (with the fix from above) to 14 through 12.
--
Daniel Gustafsson
Daniel Gustafsson writes:
>> On 5 Jul 2022, at 18:59, Tom Lane wrote:
>> Given the lack of field complaints, it's probably not worth trying
>> to do anything to restore that capability. But we really ought to
>> update pg_upgrade's code and docs in pre-v15 branches to say that
>> the minimum sup
> On 5 Jul 2022, at 18:59, Tom Lane wrote:
> Given the lack of field complaints, it's probably not worth trying
> to do anything to restore that capability. But we really ought to
> update pg_upgrade's code and docs in pre-v15 branches to say that
> the minimum supported source version is 9.0.
Andrew Dunstan writes:
> On 2022-07-05 Tu 15:17, Tom Lane wrote:
>> Hmm ... could you first look into why 09878cdd4 broke it? I'd supposed
>> that that was just detecting situations we must already have dealt with
>> in order for the pg_upgrade test to work, but crake's not happy.
> It's complai
On 2022-07-05 Tu 15:17, Tom Lane wrote:
> Andrew Dunstan writes:
>> So it's taken us a year to discover the issue :-( Perhaps if we're going
>> to say we support upgrades back to 9.0 we should have some testing to be
>> assured we don't break it without knowing like this. I'll see if I can
>> co
On Tue, Jul 5, 2022 at 12:41 PM Peter Geoghegan wrote:
> Actually, commit 74cf7d46 was where pg_resetxlog/pg_resetwal's -u
> argument was first added, for use by pg_upgrade. That commit is only
> about a year old, and was only backpatched to 9.6.
I just realized that this thread was where that wo
On Tue, Jul 5, 2022 at 11:53 AM Andrew Dunstan wrote:
> > Sure enough, 8.4's pg_controldata doesn't print anything about
> > oldestXID, because that info wasn't there then.
> >
> > Given the lack of field complaints, it's probably not worth trying
> > to do anything to restore that capability. Bu
Andrew Dunstan writes:
> So it's taken us a year to discover the issue :-( Perhaps if we're going
> to say we support upgrades back to 9.0 we should have some testing to be
> assured we don't break it without knowing like this. I'll see if I can
> coax crake to do that - it already tests back to 9
On 2022-07-05 Tu 12:59, Tom Lane wrote:
> Bruce Momjian writes:
>> This patch has been applied back to 9.6 and will appear in the next
>> minor release.
> I have just discovered that this patch broke pg_upgrade's ability
> to upgrade from 8.4:
>
> $ pg_upgrade -b ~/version84/bin -d ...
> Perform
Bruce Momjian writes:
> This patch has been applied back to 9.6 and will appear in the next
> minor release.
I have just discovered that this patch broke pg_upgrade's ability
to upgrade from 8.4:
$ pg_upgrade -b ~/version84/bin -d ...
Performing Consistency Checks
-
C
On Tue, Jul 27, 2021 at 09:25:22AM +0200, Drouvot, Bertrand wrote:
> Hi,
>
> On 7/27/21 4:39 AM, Bruce Momjian wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe
This patch has been applied back to 9.6 and will appear in the next
minor release.
---
On Tue, May 18, 2021 at 01:26:38PM +0200, Drouvot, Bertrand wrote:
> Hi,
>
> On 5/4/21 10:17 AM, Drouvot, Bertrand wrote:
>
>
> H
Hi,
On 2021-04-23 19:28:27 -0500, Justin Pryzby wrote:
> This (combination of) thread(s) seems relevant.
>
> Subject: pg_upgrade failing for 200+ million Large Objects
> https://www.postgresql.org/message-id/flat/12601596dbbc4c01b86b4ac4d2bd4d48%40EX13D05UWC001.ant.amazon.com
> https://www.postgr
On Fri, Apr 23, 2021 at 04:42:56PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-06-15 11:37:59 -0700, Noah Misch wrote:
> > On Tue, May 21, 2019 at 03:23:00PM -0700, Peter Geoghegan wrote:
> > > On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> > > > This week I upgraded one of my large(2.8T
Hi,
On 2019-06-15 11:37:59 -0700, Noah Misch wrote:
> On Tue, May 21, 2019 at 03:23:00PM -0700, Peter Geoghegan wrote:
> > On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> > > This week I upgraded one of my large(2.8TB), high-volume databases from 9
> > > to 11. The upgrade itself went fine
On Tue, May 21, 2019 at 03:23:00PM -0700, Peter Geoghegan wrote:
> On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> > This week I upgraded one of my large(2.8TB), high-volume databases from 9
> > to 11. The upgrade itself went fine. About two days later, we unexpectedly
> > hit transaction
On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> This week I upgraded one of my large(2.8TB), high-volume databases from 9 to
> 11. The upgrade itself went fine. About two days later, we unexpectedly hit
> transaction ID wraparound. What was perplexing about this was that the age of
> our
17 matches
Mail list logo
