Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Date
Msg-id CAFj8pRAooeHyRZeBCSUviM=pZoLL9WkTSzVhg-qtygRV3K39BA@mail.gmail.com
Whole thread Raw
In response to Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]  (Dilip kumar <dilip.kumar@huawei.com>)
Responses Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
List pgsql-hackers
Hi

I am testing this feature on relative complex schema (38619 tables in db) and I got deadlock

[pavel@localhost bin]$ /usr/local/pgsql/bin/vacuumdb test2 -fz -j 4
vacuumdb: vacuuming database "test2"
vacuumdb: vacuuming of database "test2" failed: ERROR:  deadlock detected
DETAIL:  Process 24689 waits for RowExclusiveLock on relation 2608 of database 194769; blocked by process 24690.
Process 24690 waits for AccessShareLock on relation 1249 of database 194769; blocked by process 24689.
HINT:  See server log for query details.

ERROR:  deadlock detected
DETAIL:  Process 24689 waits for RowExclusiveLock on relation 2608 of database 194769; blocked by process 24690.
        Process 24690 waits for AccessShareLock on relation 1249 of database 194769; blocked by process 24689.
        Process 24689: VACUUM (FULL, ANALYZE) pg_catalog.pg_attribute;
        Process 24690: VACUUM (FULL, ANALYZE) pg_catalog.pg_depend;
HINT:  See server log for query details.
STATEMENT:  VACUUM (FULL, ANALYZE) pg_catalog.pg_attribute;
ERROR:  canceling statement due to user request
STATEMENT:  VACUUM (FULL, ANALYZE) pg_catalog.pg_depend;
ERROR:  canceling statement due to user request
STATEMENT:  VACUUM (FULL, ANALYZE) pg_catalog.pg_class;
ERROR:  canceling statement due to user request
STATEMENT:  VACUUM (FULL, ANALYZE) pg_catalog.pg_proc;
LOG:  could not send data to client: Broken pipe
STATEMENT:  VACUUM (FULL, ANALYZE) pg_catalog.pg_proc;
FATAL:  connection to client lost
LOG:  could not send data to client: Broken pipe
ERROR:  canceling statement due to user request
FATAL:  connection to client lost

   Schema   |          Name           | Type  |  Owner   |    Size    | Description
------------+-------------------------+-------+----------+------------+-------------
 pg_catalog | pg_attribute            | table | postgres | 439 MB     |
 pg_catalog | pg_rewrite              | table | postgres | 314 MB     |
 pg_catalog | pg_proc                 | table | postgres | 136 MB     |
 pg_catalog | pg_depend               | table | postgres | 133 MB     |
 pg_catalog | pg_class                | table | postgres | 69 MB      |
 pg_catalog | pg_attrdef              | table | postgres | 55 MB      |
 pg_catalog | pg_trigger              | table | postgres | 47 MB      |
 pg_catalog | pg_type                 | table | postgres | 31 MB      |
 pg_catalog | pg_description          | table | postgres | 23 MB      |
 pg_catalog | pg_index                | table | postgres | 20 MB      |
 pg_catalog | pg_constraint           | table | postgres | 17 MB      |
 pg_catalog | pg_shdepend             | table | postgres | 17 MB      |
 pg_catalog | pg_statistic            | table | postgres | 928 kB     |
 pg_catalog | pg_operator             | table | postgres | 552 kB     |
 pg_catalog | pg_collation            | table | postgres | 232 kB     |

Regards

Pavel Stehule


2015-01-27 3:26 GMT+01:00 Dilip kumar <dilip.kumar@huawei.com>:
On 23 January 2015 21:10, Alvaro Herrera Wrote,


> In case you're up for doing some more work later on, there are two
> ideas
> here: move the backend's TranslateSocketError to src/common, and try to
> merge pg_dump's select_loop function with the one in this new code.
> But that's for another patch anyway (and this new function needs a
> little battle-testing, of course.)
>
Thanks for your effort, I will take it up for next commitfest..


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Daniel Bausch
Date:
Subject: Re: Parallel Seq Scan
Next
From: Dean Rasheed
Date:
Subject: Re: Possible typo in create_policy.sgml