Re: pg_restore dependencies
От | Andrew Dunstan |
---|---|
Тема | Re: pg_restore dependencies |
Дата | |
Msg-id | 49DF6B61.6050607@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_restore dependencies (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_restore dependencies
|
Список | pgsql-hackers |
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> We still have a little work to do on dependencies in parallel >> pg_restore. The current test compares the candidate's locking >> dependencies with those of the running jobs, and allows the candidate is >> there isn't a match. That's not a broad enough test. The candidate will >> block if there's a currently running CREATE INDEX command on the table, >> for example, even though that doesn't require an exclusive lock. That's >> not catastrophic, in that the restore doesn't fail, but it's fairly bad >> because it reduces the achievable parallelism. Josh Berkus observed this >> during testing on a very large restore. >> > > Well, we certainly want to be able to run CREATE INDEXes in parallel, > so this would appear to require hard-wiring some conception of shared > versus exclusive lock into pg_restore. I think it might be a bit late > to consider that for 8.4. > I'm pretty sure I had the logic for this correct stuff originally, so I'm going to go back and check that. With luck it won't take long. It shouldn't hold up beta - it's just a bug we need to fix, and with any luck I'll actually have it fixed in the next few days. cheers andrew
В списке pgsql-hackers по дате отправления: