Robert Haas <robertmh...@gmail.com> writes:
> Originally, I thought that the patch should include some kind of
> accounting mechanism to prevent that from happening, where we'd keep
> track of the number of fast-path locks that were outstanding and make
> sure to keep that many slots free in the main lock table, but Noah
> talked me out of it, on theory that (1) it was very unlikely to occur
> in practice and (2) if it did occur, then you probably need to bump up
> max_locks_per_transaction anyway and (3) it amounted to forcing
> failures in cases where that might not be strictly necessary, which is
> usually not a great thing to do.
I agree with that, as long as we can be sure that the system behaves
sanely (doesn't leave the data structures in a corrupt state) when an
out-of-memory condition does occur.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
