Hi Euler:
On Sun, Oct 2, 2016 at 5:33 AM, Euler Taveira <euler@timbira.com.br> wrote:
> This is another feature.
Yes, which allows an easier workaround around the problem. Personally
I do not need it because I do not vacuumm paralell and I can easily
write a simple dozen lines in perl which achieves it, but I feel it
can help people like the OP.
> Also, it will *sometimes* solve the problem.
No, it does not solve the problem ( paralell vacuum of system catalogs
can still deadlock ). What it does is let you transform a deadlockish
operation ( full paralell database wide vacuum ) into a non
deadlockish one ( full paralell non-system plus linear system )
without too much effort.
> Why don't you implement your parallel + serialization idea or Alvaro's
> two lists idea?
Well, I want a servant, not a nanny. If I command vacuum db to do full
paralell system catalog vacuum, I want it to do it ( although I WILL
tolerate a warning and MAY tolerate a confirmation request ).
Besides, I proposed the schema solution because I thought that
paralell vacuum would need some code building a table list, and the -t
option will need code to process tables from a list. Code examination
revealed I was correct in both. Adding the options is a simple matter
of adding some simple code ( a couple options, a couple string lists
to hold their data, a couple ifs in the table scanning loop used when
no table list given, a modification to make it happen when schema
optins are given ( presently it plays only when no -t options and
paralell is requested, I need to activate it when schema options are
present too, either in serial or paralell mode ), and the working code
remains untouched). I could refactor a bit to make several runs
easier, have a built in list of system data, and many other things,
but this is a deeper modification which I do not feel presently
prepared to attack. I may do it in the future, but I feel anyone
needing to run full paralell vacuums has a big system and should have
this kind of ops scripted, so it is not going to be that useful.
Bear in mind my work is not specifically in postgres like yours, Its
just a tool. I've been using it since before it had SQL, and have some
experience with C and libpq, but I do not feel confortable adding
complex code even to a simple client program.
> I'm not against adding schema options, I just think it's
> not the right way to solve the deadlock problem.
As I said, it does not solve the problem, just builds an easier path
than the present ones around it ( you can do exactly the same by
querying the catalog on a script and emitting two vacuumdb commands
with a table list ).
Francisco Olarte.