On Sat, Sep 06, 2025 at 10:12:11AM +0900, Michael Paquier wrote:
> Yep. This plan is safe to rely on.
Committed, thanks for reviewing!
--
nathan
On Mon, Sep 08, 2025 at 02:20:33PM -0500, Nathan Bossart wrote:
> Committed, thanks for reviewing!
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 05, 2025 at 01:12:49PM -0500, Nathan Bossart wrote:
> How does this look?
+# We can only test security labels if both the old and new installations
+# have dummy_seclabel.
+my $test_seclabel = 1;
+$old->start;
+if (!$old->check_extension('dummy_seclabel'))
+{
+
25 10:14:43 -0500
Subject: [PATCH v3 1/1] pg_upgrade: Transfer pg_largeobject_metadata's files
when possible.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 161a3e8b68 taught pg_upgrade to use COPY for large object
metadata for upgrades fro
On Thu, Sep 04, 2025 at 08:23:58PM -0500, Nathan Bossart wrote:
> Ah, I'd forgotten about EXTRA_INSTALL. That simplifies things. There's
> enough special handling for large objects in pg_upgrade that I think we
> ought to test it end-to-end, so I sneaked it into 006_tranfer_modes.pl.
> WDYT?
Nea
n Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 14 Aug 2025 10:14:43 -0500
Subject: [PATCH v2 1/1] pg_upgrade: Transfer pg_largeobject_metadata's files
when possible.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 161a3e8b68 taught pg
On Tue, Sep 02, 2025 at 09:43:40AM -0500, Nathan Bossart wrote:
> Do you think a new pg_upgrade test for security labels is worth the
> trouble? It seems doable, but it'd be an awfully expensive test for this.
> On the other hand, I'm not sure there's any coverage for pg_upgrade with
> security la
On Mon, Sep 01, 2025 at 03:19:46PM +0900, Michael Paquier wrote:
> I highly doubt that there are a lot of comments assigned to LOs, so
> these numbers are pretty cool IMO. Security labels are a pain to test
> in the upgrade path, or test_dummy_label could be extended with a new
> TAP test and a pg
On Thu, Aug 14, 2025 at 10:22:02AM -0500, Nathan Bossart wrote:
> Here is a patch. For background, the reason this is limited to upgrades
> from v16 and newer is because the aclitem data type (needed by
> pg_largeobject_metadata.lomacl) changed its storage format in v16 (see
> commit 7b378237aa).
On Tue, Aug 19, 2025 at 09:49:26AM +0200, Hannu Krosing wrote:
> Have you considered re-creating pg_shdepend from
> pg_largeobject_metadata directly instead of having special cases for
> dumping it ?
I considered it when you last brought up the idea [0], but my testing
indicated that it's measurab
Have you considered re-creating pg_shdepend from
pg_largeobject_metadata directly instead of having special cases for
dumping it ?
It would also be useful in cases of old (pg_upgraded since before pg
12) databases which might be missing it anyway.
On Thu, Aug 14, 2025 at 5:22 PM Nathan Bossart
244fdb47f9a276169 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 14 Aug 2025 10:14:43 -0500
Subject: [PATCH v1 1/1] pg_upgrade: Transfer pg_largeobject_metadata's files
when possible.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 16
12 matches
Mail list logo
