public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 08/18] *an exclusive 3+ messages / 3 participants [nested] [flat]
* [PATCH 08/18] *an exclusive @ 2021-02-06 21:13 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Justin Pryzby @ 2021-02-06 21:13 UTC (permalink / raw) 3c84046490bed3c22e0873dc6ba492e02b8b9051 --- doc/src/sgml/ref/drop_index.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/sgml/ref/drop_index.sgml b/doc/src/sgml/ref/drop_index.sgml index 85cf23bca2..b6d2c2014f 100644 --- a/doc/src/sgml/ref/drop_index.sgml +++ b/doc/src/sgml/ref/drop_index.sgml @@ -45,7 +45,7 @@ DROP INDEX [ CONCURRENTLY ] [ IF EXISTS ] <replaceable class="parameter">name</r <para> Drop the index without locking out concurrent selects, inserts, updates, and deletes on the index's table. A normal <command>DROP INDEX</command> - acquires exclusive lock on the table, blocking other accesses until the + acquires an exclusive lock on the table, blocking other accesses until the index drop can be completed. With this option, the command instead waits until conflicting transactions have completed. </para> -- 2.17.0 --lc9FT7cWel8HagAv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0009-Doc-review-for-psql-dX.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Horribly slow pg_upgrade performance with many Large Objects @ 2025-04-08 17:51 Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2025-04-08 17:51 UTC (permalink / raw) To: Nathan Bossart <[email protected]>; +Cc: Hannu Krosing <[email protected]>; PostgreSQL Hackers <[email protected]> Nathan Bossart <[email protected]> writes: > On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote: >> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade >> does *not* preserve database OIDs, which is problematic for using >> COPY to load pg_shdepend rows. > I think it does; see commit aa01051. Ah --- I thought I remembered something having been done about that, but I failed to find it because I was looking in pg_upgrade not pg_dump. Too bad aa01051 didn't update the comment at the top of pg_upgrade.c. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Horribly slow pg_upgrade performance with many Large Objects @ 2025-04-09 17:16 Nathan Bossart <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Nathan Bossart @ 2025-04-09 17:16 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Hannu Krosing <[email protected]>; PostgreSQL Hackers <[email protected]> On Tue, Apr 08, 2025 at 01:51:22PM -0400, Tom Lane wrote: > Nathan Bossart <[email protected]> writes: >> On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote: >>> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade >>> does *not* preserve database OIDs, which is problematic for using >>> COPY to load pg_shdepend rows. > >> I think it does; see commit aa01051. > > Ah --- I thought I remembered something having been done about that, > but I failed to find it because I was looking in pg_upgrade not > pg_dump. Too bad aa01051 didn't update the comment at the top of > pg_upgrade.c. I'll apply the attached patch to fix the comment shortly. -- nathan ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-04-09 17:16 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-02-06 21:13 [PATCH 08/18] *an exclusive Justin Pryzby <[email protected]> 2025-04-08 17:51 Re: Horribly slow pg_upgrade performance with many Large Objects Tom Lane <[email protected]> 2025-04-09 17:16 ` Re: Horribly slow pg_upgrade performance with many Large Objects Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox