Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Um, FKs could conflict with each other too, so that by itself isn't
>> gonna fix anything.
> Good point. Looks like we'll need to make a list of "can't run in
> parallel with" items as well as strict dependencies.
Yeah, I was just thinking about that. The current archive format
doesn't really carry enough information for this. I think there
are two basic solutions we could adopt:
* Extend the archive format to provide some indication that "restoring
this object requires exclusive access to these dependencies".
* Hardwire knowledge into pg_restore that certain types of objects
require exclusive access to their dependencies.
The former seems more flexible, as well as more in tune with the basic
design assumption that pg_restore shouldn't have a lot of knowledge
about individual archive object types. But it would mean that you
couldn't use parallel restore with any pre-8.4 dumps. In the long run
that's no big deal, but in the short run it's annoying.
Another angle is that it's not clear what happens if the need for
exclusive access changes over time. You were just speculating about
reducing the lock strength required for ALTER TABLE ADD FOREIGN KEY.
I don't know if that's workable or not, but certainly reducing the
lock strength for some types of ALTER TABLE might be in our future.
Contrarily, we don't currently try hard to lock any non-table objects
(schemas, functions, etc) while building dependent objects; but that's
obviously not really right, and someday we might decide to fix it.
So having pg_dump prepare the list of exclusive dependencies at dump
time might be the wrong thing --- it would reflect the behavior of
the source server version, not the target which is what matters.
Thoughts?
regards, tom lane
