On Mon, Jan 18, 2016 at 11:06 PM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> On Mon, Jan 18, 2016 at 11:09 AM, Alvaro Herrera
> <
alvherre@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.
