On Mon, Jan 18, 2016 at 11:06 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Jan 18, 2016 at 11:09 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Amit Kapila wrote: > > > >> The reason for not updating the patch related to this thread is that it is > >> dependent on the work for refactoring the tranches for LWLocks [1] > >> which is now coming towards an end, so I think it is quite reasonable > >> that the patch can be updated for this work during commit fest, so > >> I am moving it to upcoming CF. > > > > Thanks. I think the tranche reworks are mostly done now, so is anyone > > submitting an updated version of this patch? > >
Before updating the patch, it is better to clarify few points as mentioned below. > > > Also, it would be very good if someone can provide insight on how this > > patch interacts with the other submitted patch for "waiting for > > replication" https://commitfest.postgresql.org/8/436/ > > Andres seems to think that the other patch is completely independent of > > this one, i.e. the "waiting for replication" column needs to exist > > separately and not as part of the "more descriptive" new 'waiting' > > column. > > Yeah, I really don't agree with that. I think that it's much better > to have one column that says what you are waiting for than a bunch of > separate columns that tell you whether you are waiting for individual > things for which you might be waiting. I think this patch, which > introduces the general mechanism, should win: and the other patch > should then be one client of that mechanism. > I agree with what you have said, but I think here bigger question is about the UI and which is the more appropriate place to store wait information. I will try to summarize the options discussed. Initially, we started with extending the 'waiting' column in pg_stat_activity, to which some people have raised concerns about backward compatability, so another option that came-up during discussion was to retain waiting as it-is and have an additional column 'wait_event' in pg_stat_activity, after that there is feedback that we should try to include wait information about background processes as well which raises a bigger question whether it is any good to expose this information via pg_stat_activity (pg_stat_activity doesn't display information about background processes) or is it better to have a new view as discussed here [1]. Second important and somewhat related point is whether we should save this information in PGPROC as 4 bytes or keep it in pgBackendStatus. I think it is better to store in PGPROC, if we want to save wait information for backend processes as well. I am of opinion that we should save this information in PGPROC and expose it via new view, but I am open to go other ways based on what others think about this matter. [1] - http://www.postgresql.org/message-id/CAA4eK1+=5Ex8-5NRr3u94=_t2p65v0kcjZ5rXddVmkx=lwa...@mail.gmail.com With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
