On Mon, Apr 28, 2025 at 09:00:01PM +0300, Alexander Lakhin wrote:
> Thank you for the references! Unfortunately I still can't see where the
> lack of upgrade log files is discussed.
That was briefly discussed here:
https://postgr.es/m/644cf995-e3a5-4f69-9398-7db500e2673d%40dunslane.net
O
Hello Nathan,
28.04.2025 18:15, Nathan Bossart wrote:
I see a couple of other pg_upgrade failures on drongo and fairywren that
look similar, although these are for different tests:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2025-03-10%2019%3A26%3A35
http
On Sun, Apr 27, 2025 at 05:00:01PM +0300, Alexander Lakhin wrote:
> Both happened on Windows, but what's worse is that the failure logs
> contain no information on the exact reason. We can see:
> # Failed test 'pg_upgrade with transfer mode --swap: stdout matches'
> # at
> C:/tools/xmsys64/hom
Hello Nathan,
20.03.2025 04:02, Nathan Bossart wrote:
On Wed, Mar 19, 2025 at 04:28:23PM -0500, Nathan Bossart wrote:
And here is yet another new version of the full patch set. I'm planning to
commit 0001 (the new pg_upgrade transfer mode test) tomorrow so that I can
deal with any buildfarm ind
On Wed, Mar 19, 2025 at 12:44:38PM -0400, Andres Freund wrote:
> On 2025-03-19 12:28:33 -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>> > I'm currently planning to commit this sometime early-ish next week. One
>> > notable loose end is the lack of a pg_upgrade test with a non-default
>> > tab
Nathan Bossart writes:
> I'm currently planning to commit this sometime early-ish next week. One
> notable loose end is the lack of a pg_upgrade test with a non-default
> tablespace, but that is an existing problem that IMHO is best handled
> separately (since we can only test it in cross-version
On Thu, Mar 20, 2025 at 03:23:13PM -0500, Nathan Bossart wrote:
> I'm still aiming to commit this sometime early next week.
Committed. Thanks to everyone who chimed in on this thread.
While writing the attributions, I noticed that nobody seems to have
commented specifically on 0001. The closest
On Thu, Mar 20, 2025 at 11:11:46AM -0500, Nathan Bossart wrote:
> As promised, I've committed just 0001 for now. I'll watch closely for any
> issues in the buildfarm.
Seeing none, here's is a rebased patch set without 0001. The only changes
are some fleshed-out comments and commit messages. I'm
On Wed, Mar 19, 2025 at 09:02:42PM -0500, Nathan Bossart wrote:
> On Wed, Mar 19, 2025 at 04:28:23PM -0500, Nathan Bossart wrote:
>> On Wed, Mar 19, 2025 at 02:32:01PM -0500, Nathan Bossart wrote:
>>> In addition to testing with in-place tablespaces, we might also want to
>>> teach the transfer mod
On Wed, Mar 19, 2025 at 04:28:23PM -0500, Nathan Bossart wrote:
> On Wed, Mar 19, 2025 at 02:32:01PM -0500, Nathan Bossart wrote:
>> In addition to testing with in-place tablespaces, we might also want to
>> teach the transfer modes test to do cross-version testing when possible.
>> In that case, w
On Wed, Mar 19, 2025 at 02:32:01PM -0500, Nathan Bossart wrote:
> In addition to testing with in-place tablespaces, we might also want to
> teach the transfer modes test to do cross-version testing when possible.
> In that case, we can test normal (non-in-place) tablespaces. However, that
> would
Hi,
On 2025-03-19 12:28:33 -0400, Tom Lane wrote:
> Nathan Bossart writes:
> > I'm currently planning to commit this sometime early-ish next week. One
> > notable loose end is the lack of a pg_upgrade test with a non-default
> > tablespace, but that is an existing problem that IMHO is best handl
Hi,
On 2025-03-18 21:14:22 -0500, Nathan Bossart wrote:
> From 8b6a5e0148c2f7a663f5003f12ae9461d2b06a5c Mon Sep 17 00:00:00 2001
> From: Nathan Bossart
> Date: Tue, 18 Mar 2025 20:58:07 -0500
> Subject: [PATCH v7 1/4] Add test for pg_upgrade file transfer modes.
>
> This new test checks all of p
On Tue, Mar 18, 2025 at 09:14:22PM -0500, Nathan Bossart wrote:
> And here is a new version of the full patch set.
I'm currently planning to commit this sometime early-ish next week. One
notable loose end is the lack of a pg_upgrade test with a non-default
tablespace, but that is an existing prob
On Tue, Mar 18, 2025 at 01:50:10PM -0400, Andres Freund wrote:
> On 2025-03-18 12:47:01 -0500, Nathan Bossart wrote:
>> On Tue, Mar 18, 2025 at 01:37:02PM -0400, Andres Freund wrote:
>> > - Do we need a new old cluster for each of the modes? That seems like
>> > wasted
>> > time? I guess it's r
On Tue, Mar 18, 2025 at 10:12:51AM -0400, Andres Freund wrote:
> On 2025-03-18 10:04:41 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > I'm not quite sure what the best thing is to do is for the pg_upgrade
>> > tests in particular, and it may well be best to do as you propose for
>> > now and f
On Tue, Mar 18, 2025 at 02:08:42PM -0500, Nathan Bossart wrote:
> For now, here's a new version of the test with a rewritten table. I also
> tried to fix the expected error regex to handle some of the other error
> messages for unsupported modes (as revealed by cfbot).
And here is a new version o
Hi,
On 2025-03-18 12:29:02 -0500, Nathan Bossart wrote:
> Here is a first sketch at a test that cycles through all the transfer modes
> and makes sure they succeed or fail with an error along the lines of "not
> supported on this platform." Each test verifies that some very simple
> objects make
On 2025-03-18 12:47:01 -0500, Nathan Bossart wrote:
> On Tue, Mar 18, 2025 at 01:37:02PM -0400, Andres Freund wrote:
> > - Do we need a new old cluster for each of the modes? That seems like wasted
> > time? I guess it's required for --link...
>
> It'll also be needed for --swap. We could opti
On Tue, Mar 18, 2025 at 01:37:02PM -0400, Andres Freund wrote:
> I'd add a few more complications:
>
> - Create and test a relation that was rewritten, to ensure we test the
> relfilenode != oid case and one that isn't rewritten.
+1
> - Perhaps create a tablespace?
+1, I don't think we have m
On 2025-Mar-18, Robert Haas wrote:
> The background here is that I'm kind of on the warpath against weird
> configurations that we only test on certain buildfarm animals at the
> moment, because the result of that is that CI is clean and then the
> buildfarm turns red when you commit. That's an un
Hi,
On 2025-03-18 10:04:41 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I'm not quite sure what the best thing is to do is for the pg_upgrade
> > tests in particular, and it may well be best to do as you propose for
> > now and figure that out later. But I question whether just rerunning
> >
Robert Haas writes:
> I'm not quite sure what the best thing is to do is for the pg_upgrade
> tests in particular, and it may well be best to do as you propose for
> now and figure that out later. But I question whether just rerunning
> all of those tests with several different mode flags is the r
On Mon, Mar 17, 2025 at 4:30 PM Nathan Bossart wrote:
> On Mon, Mar 17, 2025 at 04:04:45PM -0400, Robert Haas wrote:
> > On Mon, Mar 17, 2025 at 3:34 PM Nathan Bossart
> > wrote:
> >> * Once committed, I should update one of my buildfarm animals to use
> >> PG_TEST_PG_UPGRADE_MODE=--swap.
> >
On Mon, Mar 17, 2025 at 04:04:45PM -0400, Robert Haas wrote:
> On Mon, Mar 17, 2025 at 3:34 PM Nathan Bossart
> wrote:
>> * Once committed, I should update one of my buildfarm animals to use
>> PG_TEST_PG_UPGRADE_MODE=--swap.
>
> It would be better if we didn't need a separate buildfarm animal
On Mon, Mar 17, 2025 at 3:34 PM Nathan Bossart wrote:
> * Once committed, I should update one of my buildfarm animals to use
> PG_TEST_PG_UPGRADE_MODE=--swap.
It would be better if we didn't need a separate buildfarm animal to
test this, because that means you won't get notified by local testin
On Wed, Mar 05, 2025 at 08:34:37PM -0600, Nathan Bossart wrote:
> Thank you, Greg and Robert, for sharing your thoughts. With that, here's
> what I'm considering to be a reasonably complete patch set for this
> feature. This leaves about a month for rigorous testing and editing, so
> I'm hopeful
On Wed, Mar 5, 2025 at 03:40:52PM -0500, Greg Sabino Mullane wrote:
> On Wed, Mar 5, 2025 at 2:43 PM Nathan Bossart
> wrote:
>
> One other design point I wanted to bring up is whether we should bother
> generating a rollback script for the new "swap" mode. In short, I'm
> wondering
On Wed, Mar 05, 2025 at 03:40:52PM -0500, Greg Sabino Mullane wrote:
> I've seen various failures, but they always get caught quite early.
> Certainly early enough to easily abort, fix perms/mounts/etc., then retry.
> I think your instinct is correct that this reversion is more trouble than
> its w
On Wed, Mar 5, 2025 at 2:43 PM Nathan Bossart
wrote:
> One other design point I wanted to bring up is whether we should bother
> generating a rollback script for the new "swap" mode. In short, I'm
> wondering if it would be unreasonable to say that, just for this mode, once
> pg_upgrade enters t
On Wed, Mar 5, 2025 at 2:42 PM Nathan Bossart wrote:
> Of course, rollback would still be possible, but you'd really need to
> understand what "swap" mode does behind the scenes to do so safely. In any
> case, I'm growing skeptical that a probably-not-super-well-tested script
> that extremely few
On Fri, Feb 28, 2025 at 02:51:27PM -0600, Nathan Bossart wrote:
> Cool. I appreciate the design feedback.
One other design point I wanted to bring up is whether we should bother
generating a rollback script for the new "swap" mode. In short, I'm
wondering if it would be unreasonable to say that,
I've spent quite a bit of time recently trying to get this patch set into a
reasonable state. It's still a little rough around the edges, and the code
for the generated scripts is incomplete, but I figured I'd at least get
some CI testing going.
--
nathan
>From 0af23114cfe5d00ab0b69ff804bb92d58d
On Fri, Feb 28, 2025 at 2:40 PM Robert Haas wrote:
> Maybe we should rethink the decision not to transfer relfilenodes for
> sequences. Or have more than one way to do it. pg_upgrade
> --binary-upgrade --binary-upgrade-even-for-sequences, or whatever.
Sorry, I meant: pg_dump --binary-upgrade --bi
On Fri, Feb 28, 2025 at 3:01 PM Nathan Bossart wrote:
> That's exactly where I landed (see v3-0002). I haven't measured whether
> transferring relfilenodes or dumping the sequence data is faster for the
> existing modes, but for now I've left those alone, i.e., they still dump
> sequence data. T
On Fri, Feb 28, 2025 at 03:37:49PM -0500, Robert Haas wrote:
> On Fri, Feb 28, 2025 at 3:01 PM Nathan Bossart
> wrote:
>> That's exactly where I landed (see v3-0002). I haven't measured whether
>> transferring relfilenodes or dumping the sequence data is faster for the
>> existing modes, but for
On Wed, Nov 6, 2024 at 5:07 PM Nathan Bossart wrote:
> these user relation files will have the same name. Therefore, it can be
> much faster to instead move the entire data directory from the old cluster
> to the new cluster and to then swap the catalog relation files.
This is a cool idea.
> An
On Fri, Feb 28, 2025 at 02:41:22PM -0500, Robert Haas wrote:
> On Fri, Feb 28, 2025 at 2:40 PM Robert Haas wrote:
>> Maybe we should rethink the decision not to transfer relfilenodes for
>> sequences. Or have more than one way to do it. pg_upgrade
>> --binary-upgrade --binary-upgrade-even-for-sequ
Here is a rebased patch set for cfbot. I'm planning to spend some time
getting these patches into a more reviewable state in the near future.
--
nathan
>From 81fe66e0f0aa4f958a8707df669f60756c89bb85 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Nov 2024 15:59:51 -0600
Subject: [PAT
On Mon, Nov 18, 2024 at 10:34:00PM -0500, Bruce Momjian wrote:
> On Wed, Nov 6, 2024 at 04:07:35PM -0600, Nathan Bossart wrote:
>> For clusters with many relations, the file transfer step of pg_upgrade can
>> take the longest. This step clones, copies, or links the user relation
>> files from the
On Sun, Nov 17, 2024 at 01:50:53PM -0500, Greg Sabino Mullane wrote:
> On Wed, Nov 6, 2024 at 5:07 PM Nathan Bossart
> wrote:
>> Therefore, it can be much faster to instead move the entire data directory
>> from the old cluster
>> to the new cluster and to then swap the catalog relation files.
>
On Wed, Nov 6, 2024 at 04:07:35PM -0600, Nathan Bossart wrote:
> For clusters with many relations, the file transfer step of pg_upgrade can
> take the longest. This step clones, copies, or links the user relation
> files from the older cluster to the new cluster, so the amount of time it
> takes
On Wed, Nov 6, 2024 at 5:07 PM Nathan Bossart
wrote:
> Therefore, it can be much faster to instead move the entire data directory
> from the old cluster
> to the new cluster and to then swap the catalog relation files.
>
Thank you for breaking this up so clearly into separate commits. I think it
For clusters with many relations, the file transfer step of pg_upgrade can
take the longest. This step clones, copies, or links the user relation
files from the older cluster to the new cluster, so the amount of time it
takes is closely related to the number of relations. However, since v15,
we'v
44 matches
Mail list logo
