On 12/06/2012 09:23 PM, Bruce Momjian wrote:
On Thu, Dec 6, 2012 at 09:10:21PM -0500, Tom Lane wrote:
Bruce Momjian <br...@momjian.us> writes:
On Thu, Dec 6, 2012 at 07:53:57PM -0500, Tom Lane wrote:
Because CREATE INDEX CONCURRENTLY can't drop the index if it's already
failed. It's not because we want to do that, it's an implementation
restriction of the horrid kluge that is CREATE/DROP INDEX CONCURRENTLY.
Well, what is the logic that pg_dump dumps it then, even in
non-binary-upgrade mode?
Actually, I was thinking about proposing exactly that. Ideally the
system should totally ignore an invalid index (we just fixed some bugs
in that line already). So it would be perfectly consistent for pg_dump
to ignore it too, with or without --binary-upgrade.
One possible spanner in the works for pg_upgrade is that this would mean
there can be relation files in the database directories that it should
ignore (not transfer over). Dunno if that takes any logic changes.
As soon as pg_dump stopped dumping the CREATE INDEX, pg_upgrade would
stop creating creating it in the new cluster, and not transfer the index
files.
So we'll lose the index definition and leave some files behind? This
sounds a bit messy to say the least.
Making the user fix it seems much more sensible to me. Otherwise I
suspect we'll find users who get strangely surprised when they can no
longer find any trace of an expected index in their upgraded database.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
