On Wed, Sep 16, 2015 at 10:31 AM, Shulgin, Oleksandr <oleksandr.shul...@zalando.de> wrote: > I've also decided we really ought to suppress any possible ERROR level > messages generated during the course of processing the status request in > order not to prevent the originally running transaction to complete. The > errors so caught are just logged using LOG level and ignored in this new > version of the patch.
This plan has almost zero chance of surviving committer-level scrutiny, and if it somehow does, some other committer will scream bloody murder as soon as they notice it. It's not safe to just catch an error and continue on executing. You have to abort the (sub)transaction once an error happens. Of course, this gets at a pretty crucial design question for this patch, which is whether it's OK for one process to interrogate another process's state, and what the consequences of that might be. What permissions are needed? Can you DOS the guy running a query by pinging him for status at a very high rate? The other question here is whether it's really safe to do this. ProcessInterrupts() gets called at lots of places in the code, and we may freely add more in the future. How are you going to prove that ProcessCmdStatusInfoRequest() is safe to call in all of those places? How do you know that some data structure you find by chasing down from ActivePortal or current_query_stack doesn't have a NULL pointer someplace that you don't expect, because the code that initializes that pointer hasn't run yet? I'd like to see this made to work and be safe, but I think proving that it's truly robust in all cases is going to be hard. -- Robert Haas EnterpriseDB: 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