| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
| Subject: | Re: Advisory locks seem rather broken |
| Date: | 2012-05-04 14:21:01 |
| Message-ID: | 4505.1336141261@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-05-04 14:32:36 | Re: Advisory locks seem rather broken |
| Previous Message | Robert Haas | 2012-05-04 14:17:59 | Re: Advisory locks seem rather broken |