From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Question about memory contexts in ReindexMultipleTables() |
Date: | 2017-02-17 14:51:58 |
Message-ID: | 376b294e-63d0-0926-9016-53f8d05912a2@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
When working on REINDEX CONCURRENTLY I noticed that the new memory
context created in the ReindexMultipleTables() seems pointless.
The purpose claimed in the code for introducing the
ReindexMultipleTables context is to make sure the list we build with
relation IDs survive the commit, since a commit destroys the
TopTransactionContext and ReindexMultipleTables() first runs one
transaction to list which tables should be reindexed and then reindexes
each index in a separate transaction.
But in the first transactions where the lsit is built we actually never
use TopTransactionContext, isntead PortalHeapMemory is used which is a
memory context which does not go away until the REINDEX command has
completed. So everything should work in the same way even if we just
remove the ReindexMultipleTables memory context.
Am I missing something? Should the ReindexMultipleTables memory context
be removed, or should we switch to TopTransactionContext at the begining
of ReindexMultipleTables() so temporary resources used in the initial
transaction can be freed?
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-02-17 15:02:19 | Re: Help text for pg_basebackup -R |
Previous Message | Stephen Frost | 2017-02-17 14:37:25 | Re: Provide list of subscriptions and publications in psql's completion |