Thank you Robert for committing the patch.
commit fc70a4b0df38bda6a13941f1581f25fbb643c7f3
I've changed the status to Committed.
On Mon, Mar 27, 2017 at 6:09 AM, Michael Paquier
wrote:
> On Sat, Mar 25, 2017 at 5:26 PM, Kuntal Ghosh
> wrote:
>> On Fri, Mar 24, 2017 at 9:23 PM, Robert Haas wro
On Sat, Mar 25, 2017 at 5:26 PM, Kuntal Ghosh
wrote:
> On Fri, Mar 24, 2017 at 9:23 PM, Robert Haas wrote:
>> I think this is still not good. The places where pgstat_bestart() has
>> been added are not even correct. For example, the call added to
>> BackgroundWriterMain() occurs after the secti
On Fri, Mar 24, 2017 at 9:23 PM, Robert Haas wrote:
> On Thu, Mar 23, 2017 at 7:29 AM, Michael Paquier
> wrote:
>> On Thu, Mar 23, 2017 at 8:19 PM, Kuntal Ghosh
>> wrote:
>>> Hence, to be consistent with others, bgworker processes can be
>>> initialized from BackgroundWorkerInitializeConnectionB
On Thu, Mar 23, 2017 at 7:29 AM, Michael Paquier
wrote:
> On Thu, Mar 23, 2017 at 8:19 PM, Kuntal Ghosh
> wrote:
>> Hence, to be consistent with others, bgworker processes can be
>> initialized from BackgroundWorkerInitializeConnectionBy[Oid].
>
> Yeah, I am fine with that. Thanks for the updated
On Thu, Mar 23, 2017 at 8:19 PM, Kuntal Ghosh
wrote:
> Hence, to be consistent with others, bgworker processes can be
> initialized from BackgroundWorkerInitializeConnectionBy[Oid].
Yeah, I am fine with that. Thanks for the updated versions.
--
Michael
--
Sent via pgsql-hackers mailing list (
On Wed, Mar 22, 2017 at 9:54 PM, Robert Haas wrote:
> On Wed, Mar 22, 2017 at 12:20 PM, Robert Haas wrote:
>> On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier
>> wrote:
>>> Okay, switched as ready for committer. One note for the committer
>>> though: keeping the calls of pgstat_bestart() out of
On Thu, Mar 23, 2017 at 1:24 AM, Robert Haas wrote:
> I mean, your argument boils down to "somebody might want to
> deliberately hide things from pg_stat_activity". But that's not
> really a mode we support in general, and supporting it only for
> certain cases doesn't seem like something that th
On Wed, Mar 22, 2017 at 12:20 PM, Robert Haas wrote:
> On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier
> wrote:
>> Okay, switched as ready for committer. One note for the committer
>> though: keeping the calls of pgstat_bestart() out of
>> BackgroundWorkerInitializeConnection() and
>> Background
On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier
wrote:
> Okay, switched as ready for committer. One note for the committer
> though: keeping the calls of pgstat_bestart() out of
> BackgroundWorkerInitializeConnection() and
> BackgroundWorkerInitializeConnectionByOid() keeps users the
> possibilit
On Tue, Mar 21, 2017 at 10:37 PM, Kuntal Ghosh
wrote:
> On Tue, Mar 21, 2017 at 10:52 AM, Michael Paquier
> wrote:
> We reserve a slot for each possible BackendId, plus one for each
> possible auxiliary process type. For a non-auxiliary process,
> BackendId is used to refer the backend status in
On Tue, Mar 21, 2017 at 10:52 AM, Michael Paquier
wrote:
Thank you for the review.
> Unfortunately this is true only for background workers that connect to
> a database. And this would break for bgworkers that do not do that.
> The point to fix is here:
> + if (MyBackendId != InvalidBackendId)
On Fri, Mar 17, 2017 at 6:19 PM, Kuntal Ghosh
wrote:
> On Thu, Mar 16, 2017 at 1:18 PM, Michael Paquier
> wrote:
>> + /* We have userid for client-backends and wal-sender processes */
>> + if (beentry->st_backendType == B_BACKEND ||
>> beentry->st_backendType == B_WAL_SENDER)
>> + beent
On Thu, Mar 16, 2017 at 1:18 PM, Michael Paquier
wrote:
> On Wed, Mar 15, 2017 at 9:14 PM, Kuntal Ghosh
> wrote:
>> I've attached the updated patches.
>
> Thanks for the new versions. This begins to look really clear.
Thanks again for the review.
> Having some activity really depends on the back
On Wed, Mar 15, 2017 at 9:14 PM, Kuntal Ghosh
wrote:
> I've attached the updated patches.
Thanks for the new versions. This begins to look really clear.
> In 0001-Infra-to-expose-all-backend-processes-in-pg_stat_get.patch,
> I've extended BackendStatusArray to to store auxiliary processes.
> Bac
On Tue, Mar 14, 2017 at 1:50 PM, Michael Paquier
wrote:
> "writer" would be better if defined as "background writer" instead?
> You are forgetting in this list autovacuum workers and the startup
> process, the latter is important for nodes in recovery.
>
Modified "writer" as "background writer". I
On Wed, Mar 15, 2017 at 4:52 AM, Robert Haas wrote:
> On Tue, Mar 14, 2017 at 7:22 AM, Kuntal Ghosh
> wrote:
>> I do have extended localBackendStatusTable with slots for non-backend
>> processes. But, I've renamed it as localProcStatusTable since it
>> includes all processes. I'll keep the variab
On Tue, Mar 14, 2017 at 7:22 AM, Kuntal Ghosh
wrote:
> I do have extended localBackendStatusTable with slots for non-backend
> processes. But, I've renamed it as localProcStatusTable since it
> includes all processes. I'll keep the variable name as
> localBackendStatusTable in the updated patch to
On Tue, Mar 14, 2017 at 1:50 PM, Michael Paquier
wrote:
> Here is a first pass on this patch.
Thanks Michael for the review.
>
> void
> -pgstat_bestart(void)
> +pgstat_procstart(void)
> I would not have thought that this patch justifies potentially
> breaking extensions.
Since I'm using this met
On Fri, Mar 10, 2017 at 2:36 PM, Kuntal Ghosh
wrote:
> On Fri, Mar 10, 2017 at 3:11 AM, Andres Freund wrote:
>> On 2017-03-09 16:37:29 -0500, Tom Lane wrote:
>>> Robert Haas writes:
>>> > On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
>>> > wrote:
>>> >> In practice, I think it's common to do
On Fri, Mar 10, 2017 at 3:11 AM, Andres Freund wrote:
> On 2017-03-09 16:37:29 -0500, Tom Lane wrote:
>> Robert Haas writes:
>> > On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
>> > wrote:
>> >> In practice, I think it's common to do a quick select * from
>> >> pg_stat_activity to determine wh
On 2017-03-09 16:37:29 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
> > wrote:
> >> In practice, I think it's common to do a quick select * from
> >> pg_stat_activity to determine whether a database instance is in use.
>
> > I thought of the s
Robert Haas writes:
> On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
> wrote:
>> In practice, I think it's common to do a quick select * from
>> pg_stat_activity to determine whether a database instance is in use.
> I thought of the same kind of thing, and it was discussed upthread.
> There se
Hi,
On 2017-03-09 14:30:21 -0500, Peter Eisentraut wrote:
> In practice, I think it's common to do a quick select * from
> pg_stat_activity to determine whether a database instance is in use.
> (You always see your own session, but that's easy to eyeball.) If we
> add all the various background
On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
wrote:
> Perhaps I'm confused by the title of this thread/CF entry, but
> background workers already do show up in pg_stat_activity. (You can
> verify that by testing the background sessions patch.) So which
> additional things are we aiming to se
Perhaps I'm confused by the title of this thread/CF entry, but
background workers already do show up in pg_stat_activity. (You can
verify that by testing the background sessions patch.) So which
additional things are we aiming to see with this?
In practice, I think it's common to do a quick sele
Hello Amit,
On Tue, Mar 7, 2017 at 4:24 PM, Amit Langote
wrote:
> Hi Kuntal,
>
> Patches apply and compile fine. Works as advertised.
>
> Some minor comments on the patches themselves.
>
Thanks for the review.
> In 0001:
>
> - * pgstat_bestart() -
> + * pgstat_procstart() -
> + *
> + * Initial
Hi Kuntal,
Patches apply and compile fine. Works as advertised.
Some minor comments on the patches themselves.
In 0001:
- * pgstat_bestart() -
+ * pgstat_procstart() -
+ *
+ * Initialize this process's entry in the PgBackendStatus array.
+ * Called from InitPostgres and AuxiliaryProcessMain.
Hello everyone,
As discussed in this thread, I've attached a set of patches to show
auxiliary processes, autovacuum launcher and bgworker along with other
backends in pg_stat_activity. For now, I've extended
BackendStatusArray to store auxiliary processes. Backends use slots
indexed in the range f
On Tue, Dec 13, 2016 at 11:40:54AM -0500, Robert Haas wrote:
> Let's confine ourselves to fixing one problem at a time. I think we
> can get where we want to be in this case by adding one new column and
> some new rows to pg_stat_activity.
Agreed. Let's also remove the abuse of WAL senders with t
On Mon, Dec 12, 2016 at 6:45 PM, Kevin Grittner wrote:
> On Mon, Dec 12, 2016 at 10:33 AM, Andres Freund
> wrote:
> > On 2016-12-12 13:26:32 -0300, Alvaro Herrera wrote:
> >> Robert Haas wrote:
>
> >>> 1. Show all processes that have a PGPROC in pg_stat_activity,
>
> >>> 2. Add a second view, sa
On Mon, Dec 12, 2016 at 8:13 PM, Michael Paquier
wrote:
> On Tue, Dec 13, 2016 at 10:05 AM, Craig Ringer wrote:
>> We should probably expose a proc_type or something, with types:
>>
>> * client_backend
>> * bgworker
>> * walsender
>> * autovacuum
>> * checkpointer
>> * bgwriter
>
> A text field i
On 13 December 2016 at 09:13, Michael Paquier wrote:
> On Tue, Dec 13, 2016 at 10:05 AM, Craig Ringer wrote:
>> We should probably expose a proc_type or something, with types:
>>
>> * client_backend
>> * bgworker
>> * walsender
>> * autovacuum
>> * checkpointer
>> * bgwriter
>
> A text field is a
On Tue, Dec 13, 2016 at 10:05 AM, Craig Ringer wrote:
> We should probably expose a proc_type or something, with types:
>
> * client_backend
> * bgworker
> * walsender
> * autovacuum
> * checkpointer
> * bgwriter
A text field is adapted then, more than a single character.
> for simpler filtering
On 13 December 2016 at 01:45, Kevin Grittner wrote:
> On Mon, Dec 12, 2016 at 10:33 AM, Andres Freund wrote:
>> On 2016-12-12 13:26:32 -0300, Alvaro Herrera wrote:
>>> Robert Haas wrote:
>
1. Show all processes that have a PGPROC in pg_stat_activity,
>
2. Add a second view, say pg_stat_
On Tue, Dec 13, 2016 at 1:45 AM, Robert Haas wrote:
> And now I'm noticing that Michael Paquier previously started a thread
> on this problem which I failed to note before starting this one:
>
> http://postgr.es/m/CAB7nPqSYN05rGsYCTahxTz+2hBikh7=m+hr2JTXaZv_Ei=q...@mail.gmail.com
Yes. I already h
On Mon, Dec 12, 2016 at 10:33 AM, Andres Freund wrote:
> On 2016-12-12 13:26:32 -0300, Alvaro Herrera wrote:
>> Robert Haas wrote:
>>> 1. Show all processes that have a PGPROC in pg_stat_activity,
>>> 2. Add a second view, say pg_stat_system_activity,
>> I vote 1.
>
> +1
+1
--
Kevin Grittner
On Mon, Dec 12, 2016 at 11:19 AM, Robert Haas wrote:
> So, one of the problems in this patch as committed is that for any
> process that doesn't show up in pg_stat_activity, there's no way to
> see the wait event information. That sucks. I think there are
> basically two ways to fix this:
>
> 1.
On Mon, Dec 12, 2016 at 9:19 AM, Robert Haas wrote:
> So, one of the problems in this patch as committed is that for any
> process that doesn't show up in pg_stat_activity, there's no way to
> see the wait event information. That sucks. I think there are
> basically two ways to fix this:
>
> 1.
On 2016-12-12 13:26:32 -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
>
> > So, one of the problems in this patch as committed is that for any
> > process that doesn't show up in pg_stat_activity, there's no way to
> > see the wait event information. That sucks. I think there are
> > basicall
Alvaro Herrera writes:
> Robert Haas wrote:
>> So, one of the problems in this patch as committed is that for any
>> process that doesn't show up in pg_stat_activity, there's no way to
>> see the wait event information. That sucks. I think there are
>> basically two ways to fix this:
>>
>> 1. S
Robert Haas wrote:
> So, one of the problems in this patch as committed is that for any
> process that doesn't show up in pg_stat_activity, there's no way to
> see the wait event information. That sucks. I think there are
> basically two ways to fix this:
>
> 1. Show all processes that have a P
On Tue, Oct 4, 2016 at 11:59 AM, Robert Haas wrote:
> On Mon, Oct 3, 2016 at 8:43 PM, Michael Paquier
> wrote:
>> The rest looks good to me. Thanks for the feedback and the time!
>
> Thanks for the fixes. I committed this with an additional compile
> fix, but the buildfarm turned up a few more p
42 matches
Mail list logo