Thread: pg_stat_activity
Hi, Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements? -- Angular momentum makes the world go 'round.
Hi,
It lists all statements including 'ALTER TABLE', 'VACUUM', 'CREATE INDEX', etcLe lun. 11 juin 2018 à 15:38, Ron <ronljohnsonjr@gmail.com> a écrit :
Hi,
Does pg_stat_activity only list SELECT statements, or does it also list
INSERT, DELETE and UPDATE statements?
--
Angular momentum makes the world go 'round.
Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements?
On Mon, Jun 11, 2018 at 9:37 AM, Ron <ronljohnsonjr@gmail.com> wrote:
Hi,
Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements?
--
Angular momentum makes the world go 'round.
Ron,
Yes, It can list the insert,delete and update statement as well..
Yes, It can list the insert,delete and update statement as well..
On Mon, Jun 11, 2018 at 7:07 PM, Ron <ronljohnsonjr@gmail.com> wrote:
Hi,
Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements?
--
Angular momentum makes the world go 'round.
Thanks.
How, then, do I get only long-running SELECT statements?
I've tried this (since I don't want to inadvertently get other DML & DDL statements which might have "select" in a field name), but CTEs and queries that start with a comment slip by this filter.
FROM pg_stat_activity
WHERE state <> 'idle'
AND SUBSTRING(UPPER(query) FROM 1 FOR 6) = 'SELECT';
Thanks
How, then, do I get only long-running SELECT statements?
I've tried this (since I don't want to inadvertently get other DML & DDL statements which might have "select" in a field name), but CTEs and queries that start with a comment slip by this filter.
FROM pg_stat_activity
WHERE state <> 'idle'
AND SUBSTRING(UPPER(query) FROM 1 FOR 6) = 'SELECT';
Thanks
On 06/11/2018 08:47 AM, Shreeyansh Dba wrote:
Ron,
Yes, It can list the insert,delete and update statement as well..On Mon, Jun 11, 2018 at 7:07 PM, Ron <ronljohnsonjr@gmail.com> wrote:Hi,
Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements?
--
Angular momentum makes the world go 'round.
Angular momentum makes the world go 'round.
On Mon, Jun 11, 2018 at 8:45 AM, Thomas Poty <thomas.poty@gmail.com> wrote:
It lists all statements including 'ALTER TABLE', 'VACUUM', 'CREATE INDEX', etcLe lun. 11 juin 2018 à 15:38, Ron <ronljohnsonjr@gmail.com> a écrit :Does pg_stat_activity only list SELECT statements, or does it also list
INSERT, DELETE and UPDATE statements?
Keep in mind that you can only see those statements if you are the same user or are a superuser. I'm not sure yet if users in the pg_monitor role have visibility.
Hi Don,
I think you cannot run pg_activity if role is not superuser.Le lun. 11 juin 2018 à 15:58, Don Seiler <don@seiler.us> a écrit :
On Mon, Jun 11, 2018 at 8:45 AM, Thomas Poty <thomas.poty@gmail.com> wrote:It lists all statements including 'ALTER TABLE', 'VACUUM', 'CREATE INDEX', etcLe lun. 11 juin 2018 à 15:38, Ron <ronljohnsonjr@gmail.com> a écrit :Does pg_stat_activity only list SELECT statements, or does it also list
INSERT, DELETE and UPDATE statements?Keep in mind that you can only see those statements if you are the same user or are a superuser. I'm not sure yet if users in the pg_monitor role have visibility.
Hi all,
Can you please delist me from this list?
I couldn’t find a way to unsubscribe.
Thanks
11 Haz 2018 Pzt, saat 17:15 tarihinde Thomas Poty <thomas.poty@gmail.com> şunu yazdı:
ThomasRegards,Hi Don,I think you cannot run pg_activity if role is not superuser.Le lun. 11 juin 2018 à 15:58, Don Seiler <don@seiler.us> a écrit :On Mon, Jun 11, 2018 at 8:45 AM, Thomas Poty <thomas.poty@gmail.com> wrote:It lists all statements including 'ALTER TABLE', 'VACUUM', 'CREATE INDEX', etcLe lun. 11 juin 2018 à 15:38, Ron <ronljohnsonjr@gmail.com> a écrit :Does pg_stat_activity only list SELECT statements, or does it also list
INSERT, DELETE and UPDATE statements?Keep in mind that you can only see those statements if you are the same user or are a superuser. I'm not sure yet if users in the pg_monitor role have visibility.
Hi Ron,
You can use LIKE operator to get only select query and specify LIMIT as per your requirement.
Hope this helps..
You can use LIKE operator to get only select query and specify LIMIT as per your requirement.
Hope this helps..
On Mon, Jun 11, 2018 at 7:26 PM, Ron <ronljohnsonjr@gmail.com> wrote:
Thanks.
How, then, do I get only long-running SELECT statements?I've tried this (since I don't want to inadvertently get other DML & DDL statementswhich might have "select" in a field name), but CTEs and queries that start with a comment slip by this filter.
FROM pg_stat_activity
WHERE state <> 'idle'
AND SUBSTRING(UPPER(query) FROM 1 FOR 6) = 'SELECT';
ThanksOn 06/11/2018 08:47 AM, Shreeyansh Dba wrote:Ron,
Yes, It can list the insert,delete and update statement as well..On Mon, Jun 11, 2018 at 7:07 PM, Ron <ronljohnsonjr@gmail.com> wrote:Hi,
Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements?--
Angular momentum makes the world go 'round.
That won't work, because that would catch any query on a table which happens to have the string "select" in a table, index or column name.
On 06/11/2018 09:53 AM, Shreeyansh Dba wrote:
Hi Ron,
You can use LIKE operator to get only select query and specify LIMIT as per your requirement.
Hope this helps..On Mon, Jun 11, 2018 at 7:26 PM, Ron <ronljohnsonjr@gmail.com> wrote:Thanks.
How, then, do I get only long-running SELECT statements?I've tried this (since I don't want to inadvertently get other DML & DDL statementswhich might have "select" in a field name), but CTEs and queries that start with a comment slip by this filter.
FROM pg_stat_activity
WHERE state <> 'idle'
AND SUBSTRING(UPPER(query) FROM 1 FOR 6) = 'SELECT';
ThanksOn 06/11/2018 08:47 AM, Shreeyansh Dba wrote:Ron,
Yes, It can list the insert,delete and update statement as well..On Mon, Jun 11, 2018 at 7:07 PM, Ron <ronljohnsonjr@gmail.com> wrote:Hi,
Does pg_stat_activity only list SELECT statements, or does it also list INSERT, DELETE and UPDATE statements?--
Angular momentum makes the world go 'round.
--
Angular momentum makes the world go 'round.
Angular momentum makes the world go 'round.
That won't work, because that would catch any query on a table which happens to have the string "select" in a table, index or column name.
I don't believe what you are asking is possible using only pg_stat_activity. One thought that comes to mind is to identify, via pg_locks, sessions that hold non-read-only locks and then exclude the rows in pg_stat_activity that match up with those sessions.
David J.
On 06/11/2018 10:21 AM, David G. Johnston wrote:
Thanks. I'll try that.
That won't work, because that would catch any query on a table which happens to have the string "select" in a table, index or column name.I don't believe what you are asking is possible using only pg_stat_activity. One thought that comes to mind is to identify, via pg_locks, sessions that hold non-read-only locks and then exclude the rows in pg_stat_activity that match up with those sessions.David J.
Thanks. I'll try that.
--
Angular momentum makes the world go 'round.
Angular momentum makes the world go 'round.
> On Jun 11, 2018, at 9:56 AM, Ron <ronljohnsonjr@gmail.com> wrote: > > How, then, do I get only long-running SELECT statements? > Why only select statements? What about select statements that are really updates? i.e. select …. for update; select do_some_work(); —In this case you will not see the actual executing SQL in the function which could be update, delete,select, etc. Or what about delete or update with returning?
On Mon, Jun 11, 2018, 9:58 PM Rui DeSousa <rui.desousa@icloud.com> wrote:
> On Jun 11, 2018, at 9:56 AM, Ron <ronljohnsonjr@gmail.com> wrote:
>
> How, then, do I get only long-running SELECT statements?
>
Why only select statements? What about select statements that are really updates?
i.e.
select …. for update;
select do_some_work(); —In this case you will not see the actual executing SQL in the function which could be update, delete, select, etc.
Or what about delete or update with returning?
Hi Ron,
You can use LIKE operator for getting updates and deletes and inserts like
You can use LIKE operator for getting updates and deletes and inserts like
" Select * from pg_stat_activity where query like '%UPDATE%' or '%update%' "
The same in case of updates and deletes. You can also configure table level audit with the help of triggers to capture DML's
Hope this helps.
Thanks & Regards,
Pavan.
You can use LIKE operator for getting updates and deletes and inserts like
I was pondering whether answering "show me everything that isn't (match non-select statements) would be more easily achievable...and in fact it is but...
" Select * from pg_stat_activity where query like '%UPDATE%' or '%update%' "The same in case of updates and deletes.
That would depend on how acceptable false positives are...generally speaking pattern matching the input string doesn't work reliably.
You can also configure table level audit with the help of triggers to capture DML's
How?
David J.
Ron,
This might get you closer to you goal. Select will not take out exclusive locks out so we can eliminate sessions that have locks out. Note that this will also remove long running queries that are part of a larger transaction that had issued some sort of DML/DDL prior to running.
p.s. careful with the smart quotes; autocorrect in email is not great for code.
select pg_stat_activity.pid
, pg_stat_activity.usename
, pg_stat_activity.client_addr
, pg_stat_activity.client_port
, pg_stat_activity.state
, pg_stat_activity.backend_xid
, pg_stat_activity.backend_xmin
, age(now(), pg_stat_activity.state_change) as state_time
, pg_stat_activity.wait_event_type
, pg_stat_activity.wait_event
, age(now(), pg_stat_activity.query_start) as query_time
, pg_stat_activity.query
from pg_stat_activity
where pg_stat_activity.state <> 'idle'::text
and pg_stat_activity.pid not in (
select pid
from pg_locks
where locktype = 'relation'
and mode in ('RowExclusiveLock', 'ExclusiveLock')
)
order by pg_stat_activity.query_start
;
Hi David, >>You can also configure table level audit with the help of triggers to capture DML's >How? Please find below procedure to configure table level audit with the help of triggers : Step1: CREATE EXTENSION IF NOT EXISTS hstore; Step2: CREATE SCHEMA audit; Step3: REVOKE ALL ON SCHEMA audit FROM public; Step4: COMMENT ON SCHEMA audit IS 'Out-of-table audit/history logging tables and trigger functions'; Step5: CREATE TABLE audit.logged_actions ( event_id bigserial primary key, schema_name text not null, table_name text not null, relid oid not null, session_user_name text, action_tstamp_tx TIMESTAMP WITH TIME ZONE NOT NULL, action_tstamp_stm TIMESTAMP WITH TIME ZONE NOT NULL, action_tstamp_clk TIMESTAMP WITH TIME ZONE NOT NULL, transaction_id bigint, application_name text, client_addr inet, client_port integer, client_query text, action TEXT NOT NULL CHECK (action IN ('I','D','U', 'T')), row_data hstore, changed_fields hstore, statement_only boolean not null ); Step6: REVOKE ALL ON audit.logged_actions FROM public; Step7: COMMENT ON TABLE audit.logged_actions IS 'History of auditable actions on audited tables, from audit.if_modified_func()'; COMMENT ON COLUMN audit.logged_actions.event_id IS 'Unique identifier for each auditable event'; COMMENT ON COLUMN audit.logged_actions.schema_name IS 'Database schema audited table for this event is in'; COMMENT ON COLUMN audit.logged_actions.table_name IS 'Non-schema-qualified table name of table event occured in'; COMMENT ON COLUMN audit.logged_actions.relid IS 'Table OID. Changes with drop/create. Get with ' ''tablename''::regclass'; COMMENT ON COLUMN audit.logged_actions.session_user_name IS 'Login / session user whose statement caused the audited event'; COMMENT ON COLUMN audit.logged_actions.action_tstamp_tx IS 'Transaction start timestamp for tx in which audited event occurred'; COMMENT ON COLUMN audit.logged_actions.action_tstamp_stm IS 'Statement start timestamp for tx in which audited event occurred'; COMMENT ON COLUMN audit.logged_actions.action_tstamp_clk IS 'Wall clock time at which audited event''s trigger call occurred'; COMMENT ON COLUMN audit.logged_actions.transaction_id IS 'Identifier of transaction that made the change. May wrap, but unique paired with action_tstamp_tx.'; COMMENT ON COLUMN audit.logged_actions.client_addr IS 'IP address of client that issued query. Null for unix domain socket.'; COMMENT ON COLUMN audit.logged_actions.client_port IS 'Remote peer IP port address of client that issued query. Undefined for unix socket.'; COMMENT ON COLUMN audit.logged_actions.client_query IS 'Top-level query that caused this auditable event. May be more than one statement.'; COMMENT ON COLUMN audit.logged_actions.application_name IS 'Application name set when this audit event occurred. Can be changed in-session by client.'; COMMENT ON COLUMN audit.logged_actions.action IS 'Action type; I = insert, D = delete, U = update, T = truncate'; COMMENT ON COLUMN audit.logged_actions.row_data IS 'Record value. Null for statement-level trigger. For INSERT this is the new tuple. For DELETE and UPDATE it is the old tuple.'; COMMENT ON COLUMN audit.logged_actions.changed_fields IS 'New values of fields changed by UPDATE. Null except for row-level UPDATE events.'; COMMENT ON COLUMN audit.logged_actions.statement_only IS '''t'' if audit event is from an FOR EACH STATEMENT trigger, ''f'' for FOR EACH ROW'; Step8: CREATE INDEX logged_actions_relid_idx ON audit.logged_actions(relid); CREATE INDEX logged_actions_action_tstamp_tx_stm_idx ON audit.logged_actions(action_tstamp_stm); CREATE INDEX logged_actions_action_idx ON audit.logged_actions(action); Step9: CREATE OR REPLACE FUNCTION audit.if_modified_func() RETURNS TRIGGER AS $body$ DECLARE audit_row audit.logged_actions; include_values boolean; log_diffs boolean; h_old hstore; h_new hstore; excluded_cols text[] = ARRAY[]::text[]; BEGIN IF TG_WHEN <> 'AFTER' THEN RAISE EXCEPTION 'audit.if_modified_func() may only run as an AFTER trigger'; END IF; audit_row = ROW( nextval('audit.logged_actions_event_id_seq'), -- event_id TG_TABLE_SCHEMA::text, -- schema_name TG_TABLE_NAME::text, -- table_name TG_RELID, -- relation OID for much quicker searches session_user::text, -- session_user_name current_timestamp, -- action_tstamp_tx statement_timestamp(), -- action_tstamp_stm clock_timestamp(), -- action_tstamp_clk txid_current(), -- transaction ID current_setting('application_name'), -- client application inet_client_addr(), -- client_addr inet_client_port(), -- client_port current_query(), -- top-level query or queries (if multistatement) from client substring(TG_OP,1,1), -- action NULL, NULL, -- row_data, changed_fields 'f' -- statement_only ); IF NOT TG_ARGV[0]::boolean IS DISTINCT FROM 'f'::boolean THEN audit_row.client_query = NULL; END IF; IF TG_ARGV[1] IS NOT NULL THEN excluded_cols = TG_ARGV[1]::text[]; END IF; IF (TG_OP = 'UPDATE' AND TG_LEVEL = 'ROW') THEN audit_row.row_data = hstore(OLD.*); audit_row.changed_fields = (hstore(NEW.*) - audit_row.row_data) - excluded_cols; IF audit_row.changed_fields = hstore('') THEN -- All changed fields are ignored. Skip this update. RETURN NULL; END IF; ELSIF (TG_OP = 'DELETE' AND TG_LEVEL = 'ROW') THEN audit_row.row_data = hstore(OLD.*) - excluded_cols; ELSIF (TG_OP = 'INSERT' AND TG_LEVEL = 'ROW') THEN audit_row.row_data = hstore(NEW.*) - excluded_cols; ELSIF (TG_LEVEL = 'STATEMENT' AND TG_OP IN ('INSERT','UPDATE','DELETE','TRUNCATE')) THEN audit_row.statement_only = 't'; ELSE RAISE EXCEPTION '[audit.if_modified_func] - Trigger func added as trigger for unhandled case: %, %',TG_OP, TG_LEVEL; RETURN NULL; END IF; INSERT INTO audit.logged_actions VALUES (audit_row.*); RETURN NULL; END; $body$ LANGUAGE plpgsql SECURITY DEFINER SET search_path = pg_catalog, public; Step10: COMMENT ON FUNCTION audit.if_modified_func() IS $body$ Track changes to a table at the statement and/or row level. Optional parameters to trigger in CREATE TRIGGER call: param 0: boolean, whether to log the query text. Default 't'. param 1: text[], columns to ignore in updates. Default []. Updates to ignored cols are omitted from changed_fields. Updates with only ignored cols changed are not inserted into the audit log. Almost all the processing work is still done for updates that ignored. If you need to save the load, you need to use WHEN clause on the trigger instead. No warning or error is issued if ignored_cols contains columns that do not exist in the target table. This lets you specify a standard set of ignored columns. There is no parameter to disable logging of values. Add this trigger as a 'FOR EACH STATEMENT' rather than 'FOR EACH ROW' trigger if you do not want to log row values. Note that the user name logged is the login role for the session. The audit trigger cannot obtain the active role because it is reset by the SECURITY DEFINER invocation of the audit trigger its self. $body$; Step11: CREATE OR REPLACE FUNCTION audit.audit_table(target_table regclass, audit_rows boolean, audit_query_text boolean, ignored_cols text[]) RETURNS void AS $body$ DECLARE stm_targets text = 'INSERT OR UPDATE OR DELETE OR TRUNCATE'; _q_txt text; _ignored_cols_snip text = ''; BEGIN EXECUTE 'DROP TRIGGER IF EXISTS audit_trigger_row ON ' || target_table; EXECUTE 'DROP TRIGGER IF EXISTS audit_trigger_stm ON ' || target_table; IF audit_rows THEN IF array_length(ignored_cols,1) > 0 THEN _ignored_cols_snip = ', ' || quote_literal(ignored_cols); END IF; _q_txt = 'CREATE TRIGGER audit_trigger_row AFTER INSERT OR UPDATE OR DELETE ON ' || target_table || ' FOR EACH ROW EXECUTE PROCEDURE audit.if_modified_func(' || quote_literal(audit_query_text) || _ignored_cols_snip || ');'; RAISE NOTICE '%',_q_txt; EXECUTE _q_txt; stm_targets = 'TRUNCATE'; ELSE END IF; _q_txt = 'CREATE TRIGGER audit_trigger_stm AFTER ' || stm_targets || ' ON ' || target_table || ' FOR EACH STATEMENT EXECUTE PROCEDURE audit.if_modified_func('|| quote_literal(audit_query_text) || ');'; RAISE NOTICE '%',_q_txt; EXECUTE _q_txt; END; $body$ language 'plpgsql'; Step12: COMMENT ON FUNCTION audit.audit_table(regclass, boolean, boolean, text[]) IS $body$ Add auditing support to a table. Arguments: target_table: Table name, schema qualified if not on search_path audit_rows: Record each row change, or only audit at a statement level audit_query_text: Record the text of the client query that triggered the audit event? ignored_cols: Columns to exclude from update diffs, ignore updates that change only ignored cols. $body$; Step13: CREATE OR REPLACE FUNCTION audit.audit_table(target_table regclass, audit_rows boolean, audit_query_text boolean) RETURNS void AS $body$ SELECT audit.audit_table($1, $2, $3, ARRAY[]::text[]); $body$ LANGUAGE SQL; Step 14: CREATE OR REPLACE FUNCTION audit.audit_table(target_table regclass) RETURNS void AS $$ SELECT audit.audit_table($1, BOOLEAN 't', BOOLEAN 't'); $$ LANGUAGE 'sql'; Step15: COMMENT ON FUNCTION audit.audit_table(regclass) IS $body$ Add auditing support to the given table. Row-level changes will be logged with full client query text. No cols are ignored. $body$; That's it and you are done. Just add the table you want to track the DML's in the below way: select * from audit.audit_table('<your_table_name>'); And now you can start checking by doing some DML's on the added table. It tracks Inserts, Updates, Deletes & Truncates with the help of triggers. Feel free to repost in case of any queries. Thanks. Note: Excuse me for the lack of proper indentation Regards, Pavan -- Sent from: http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html
On Monday, June 11, 2018, pavan95 <pavan.postgresdba@gmail.com> wrote:
Hi David,
>>You can also configure table level audit with the help of triggers to
capture DML's
>How?
Please find below procedure to configure table level audit with the help of
triggers :
[...]
That's it and you are done. Just add the table you want to track the DML's
in the below way:
I'm missing the part where any of that has to do with pg_stat_activity and the question that this thread is about...in particular the part about select statements.
David J.
Hi David, On Monday, June 11, 2018, pavan95 <[hidden email]> wrote: Hi David, >>You can also configure table level audit with the help of triggers to capture DML's >How? Please find below procedure to configure table level audit with the help of triggers : [...] That's it and you are done. Just add the table you want to track the DML's in the below way: >I'm missing the part where any of that has to do with pg_stat_activity and the question that this >thread is about...in particular the part about select statements. Yeah, this method is to track the execution times of the DML queries(long running), just said if Ron's intention was to identify the long running queries might be SELECT .. FOR UPDATES, he can use this method. And it is not related in any way with pg_stat_activity. Regards, Pavan -- Sent from: http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html