On Wed, Jul 21, 2021 at 01:21:17PM +0900, Michael Paquier wrote:
> The authenticated ID could be a SSL DN longer than the default of
> 128kB that this patch is proposing. I think that it is a good idea to
> provide some way to the user to be able to control that without a
> recompilation.
I got t
On Mon, Jul 19, 2021 at 04:56:24PM +0300, Aleksander Alekseev wrote:
> Any reason why we shouldn't simply exclude internal processes from the
> view? Do they have a connection that the VIEW could show?
Yeah, they don't really have any useful information. Still, I kept
that mainly as a matter of c
Hi Michael,
> Just to make the discussion move on, attached is an updated version
> doing that.
The code seems OK, but I have mixed feelings about the way that the
VIEW currently works.
Here is what I get when a single user is connected via a UNIX socket:
43204 (master) =# select * from pg_stat
On Tue, May 18, 2021 at 11:20:49AM +0900, Michael Paquier wrote:
> So that would mean the addition of one new catalog view, called
> pg_stat_connection, with the following fields:
> - PID
> - all three client_*
> - authn ID
> I can live with this split. Thoughts from others?
Just to make the disc
On Mon, May 17, 2021 at 10:28:49AM +0200, Magnus Hagander wrote:
> On Mon, May 17, 2021 at 6:35 AM Michael Paquier wrote:
>> Not sure if we would be able to agree on something here, but the
>> barrier to what a session and a connection hold is thin when it comes
>> to roles and application_name.
On Mon, May 17, 2021 at 6:35 AM Michael Paquier wrote:
>
> On Thu, Apr 29, 2021 at 04:56:42PM +0200, Magnus Hagander wrote:
> > I definitely use it all the time to monitor autovacuum all the time.
> > The others as well regularly, but autovacuum continuously. I also see
> > a lot of people doing t
On Thu, Apr 29, 2021 at 04:56:42PM +0200, Magnus Hagander wrote:
> I definitely use it all the time to monitor autovacuum all the time.
> The others as well regularly, but autovacuum continuously. I also see
> a lot of people doing things like "from pg_stat_activity where query
> like '%mytablename
On Tue, Apr 27, 2021 at 8:25 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-04-27 12:40:29 -0400, Stephen Frost wrote:
> > So, what fields are people really looking at when querying
> > pg_stat_activity interactively? User, database, pid, last query,
> > transaction start, query start, state, wait e
Hi,
On 2021-04-27 12:40:29 -0400, Stephen Frost wrote:
> So, what fields are people really looking at when querying
> pg_stat_activity interactively? User, database, pid, last query,
> transaction start, query start, state, wait event info, maybe backend
> xmin/xid? I doubt most people looking a
On Tue, Apr 27, 2021 at 09:59:18AM +0900, Michael Paquier wrote:
> On Mon, Apr 26, 2021 at 03:21:46PM -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> >> I'm getting a bit worried about the incremental increase in
> >> pg_stat_activity width - it's probably by far the v
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Apr 26, 2021 at 03:21:46PM -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> >> I'm getting a bit worried about the incremental increase in
> >> pg_stat_activity width - it's probably by far the view th
On Tue, Apr 27, 2021 at 09:26:11AM +0800, Julien Rouhaud wrote:
> -1. It's already annoying enough to have to type "WHERE pid !=
> pg_backend_pid()" to exclude my own backend, and I usually need it quite
> often.
> Unless we add some new view which integrate that, something like
> pg_stat_activit
On Tue, Apr 27, 2021 at 09:59:18AM +0900, Michael Paquier wrote:
>
> I am wondering if we should take this as an occasion to move some data
> out of pg_stat_activity into a separate biew, dedicated to the data
> related to the connection that remains set to the same value for the
> duration of a b
On Mon, Apr 26, 2021 at 03:21:46PM -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
>> I'm getting a bit worried about the incremental increase in
>> pg_stat_activity width - it's probably by far the view that's most
>> viewed interactively. I think we need to be careful no
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-04-26 11:34:16 +0900, Michael Paquier wrote:
> > 9afffcb has added the concept of authenticated identity to the
> > information provided in log_connections for audit purposes, with this
> > data stored in each backend's port. One ex
Hi,
On 2021-04-26 11:34:16 +0900, Michael Paquier wrote:
> 9afffcb has added the concept of authenticated identity to the
> information provided in log_connections for audit purposes, with this
> data stored in each backend's port. One extra thing that can be
> really useful for monitoring is the
On Sun, Apr 25, 2021 at 10:14:43PM -0500, Justin Pryzby wrote:
> That part looks to be a copy+paste error.
Sorry about that. I have fixed that on my own branch.
>> +
>> pg_stat_activity.authenticated_id
>> field.
>> + If this value is specified without units, it is taken as bytes.
On Mon, Apr 26, 2021 at 11:34:16AM +0900, Michael Paquier wrote:
> +++ b/doc/src/sgml/config.sgml
> @@ -7596,6 +7596,24 @@ COPY postgres_log FROM '/full/path/to/logfile.csv'
> WITH csv;
>
>
>
> + xreflabel="track_activity_authn_size">
> + track_activity_authn_size
> (in
Hi all,
9afffcb has added the concept of authenticated identity to the
information provided in log_connections for audit purposes, with this
data stored in each backend's port. One extra thing that can be
really useful for monitoring is the capability to track this
information directly in pg_stat
19 matches
Mail list logo
