On Mon, Dec 5, 2016 at 6:54 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 12/5/16 2:14 PM, David Fetter wrote:
>> What do you see as the relationship between this proposal and the >> earlier one for admission control? >> >> https://www.postgresql.org/message-id/4b38c1c5020000250002d...@gw.wicourts.gov > > Without having read the paper reference in that email or the rest of the > thread... > One big difference from what Kevin describe though: I don't think it makes > sense for the connection layer to be able to parse queries. I suspect it > would take a very large amount of work to allow something that's not a > full-blown backend to parse, because it needs access to the catalogs. > *Maybe* it'd be possible if we used a method other than ProcArray to > register the snapshot that required, but you'd still have to duplicate all > the relcache stuff. I don't recall ever, on the referenced thread or any other, suggesting what you describe. Basically, I was suggesting that we create a number hooks which an admission control policy (ACP) could tie into, and we could create pluggable APCs. One ACP that I think would be useful would be one that ties into a hook placed at the point(s) where a transaction is attempting to acquire its first "contentious resource" -- which would include at least snapshot and locks. If the user was a superuser it would allow the transaction to proceed; otherwise it would check whether the number of transactions which were holding contentious resources had reached some (configurable) limit. If allowing the transaction to proceed would put it over the limit, the transaction would be blocked and put on a queue behind any other transactions which had already been blocked for this reason, and a transaction from the queue would be unblocked whenever the count of transactions holding contentious resources fell below the threshold. I don't see where parsing even enters into this. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
