Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
| От | Nathan Bossart |
|---|---|
| Тема | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
| Дата | |
| Msg-id | aLo7rnQ8MbPK2dGH@nathan обсуждение исходный текст |
| Ответ на | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
|
| Список | pgsql-hackers |
On Thu, Sep 04, 2025 at 01:59:36PM +0900, Michael Paquier wrote: > 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 labels, so perhaps this is a good time to establish some tests. > > I would argue in favor of these additions. Security labels are not > the most popular thing ever, AFAIK, but your patch makes the need more > relevant to have. The cheapest approach would be to add a LO creation > pattern in src/bin/pg_dump/t/002_pg_dump.pl, with an EXTRA_INSTALL > pointing at src/test/modules/dummy_seclabel/ to be able to create the > security label (we already do that in pg_upgrade and pg_basebackup so > the trick works). That should be enough to make sure that the binary > upgrade dumps have the seclabel data included. It's a bit funky, I > agree. So if you think that this is not worth the test cycles, I > won't push hard on this point, either. 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? -- nathan
Вложения
В списке pgsql-hackers по дате отправления: