Обсуждение: BUG #5070: Drop cascade fails on 8.4

Поиск
Список
Период
Сортировка

BUG #5070: Drop cascade fails on 8.4

От
"Cedric Berger"
Дата:
The following bug has been logged online:

Bug reference:      5070
Logged by:          Cedric Berger
Email address:      cedric@berger.to
PostgreSQL version: 8.4.1
Operating system:   Mac OS X, 10.6.1
Description:        Drop <schema> cascade fails on 8.4
Details:

I've a schema with actually 409 tables.
I've made a default installation of postgresql on the mac
(Installer version Version 8.4.1-1 from enterprise db).

Unfortunately, since I upgraded from 8.3, I cannot drop
these kind of schema anymore:

 postgres=# drop schema hard_12 cascade
 postgres-# ;
 WARNING:  out of shared memory
 ERROR:  out of shared memory
 HINT:  You might need to increase max_locks_per_transaction.

I've tried to double max_locks_per_transaction, double the values
of SHMMAX/SHMALL, there is no difference...

I had no issue with drop cascade with postgresql 8.2 and 8.3

Please let me know what more information is needed to help you
debug that problem.

Re: BUG #5070: Drop cascade fails on 8.4

От
Tom Lane
Дата:
"Cedric Berger" <cedric@berger.to> writes:
> I've a schema with actually 409 tables.
> I've made a default installation of postgresql on the mac
> (Installer version Version 8.4.1-1 from enterprise db).

> Unfortunately, since I upgraded from 8.3, I cannot drop
> these kind of schema anymore:

>  postgres=# drop schema hard_12 cascade
>  postgres-# ;

Works for me ... however such a command is certainly going to take a lot
of locks (at least 409, maybe many more if these tables have lots of
indexes).  So it's definitely possible that you'd overrun the default
lock table size.

>  WARNING:  out of shared memory
>  ERROR:  out of shared memory
>  HINT:  You might need to increase max_locks_per_transaction.

> I've tried to double max_locks_per_transaction, double the values
> of SHMMAX/SHMALL, there is no difference...

Did you actually restart the server after increasing
max_locks_per_transaction?

I suspect that you have an exceptionally small amount of free shared
memory because OSX's default shared memory limits are so small.  If
initdb chose a small value of max_connections because of that, that'd
be contributing to your problem, because the actual lock table size
is max_locks_per_transaction * max_connections.

OSX is extremely picky about shared memory parameters; there is only
one right way to do it, and that's described in our docs at
http://www.postgresql.org/docs/8.4/static/kernel-resources.html#SYSVIPC
In recent releases the right way is to create a /etc/sysctl.conf file
setting *all five* SHM parameters to valid values, then reboot.
If "sysctl -a | grep sysv.shm" doesn't show the expected values,
you didn't get it right.

            regards, tom lane