Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

Andrei Zubkov <zubkov@moonset.ru>

From: Andrei Zubkov <zubkov@moonset.ru>

To: Michael Paquier <michael@paquier.xyz>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2023-03-16T11:02:51Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Improve quoting in some error messages
- 07e5e6674233 14.0 cited

Attachments

v20-0001-pg_stat_statements-tests-Add-NOT-NULL-checking-of-pg.patch (text/x-patch) patch v20-0001
v20-0002-pg_stat_statements-Track-statement-entry-timestamp.patch (text/x-patch) patch v20-0002

Hi Michael,

Thank you for your attention.

On Thu, 2023-03-16 at 16:13 +0900, Michael Paquier wrote:
> +/* First we have to remove them from the extension */
> +ALTER EXTENSION pg_stat_statements DROP VIEW pg_stat_statements;
> +ALTER EXTENSION pg_stat_statements DROP FUNCTION
> pg_stat_statements(boolean);
> +ALTER EXTENSION pg_stat_statements DROP FUNCTION
> +  pg_stat_statements_reset(Oid, Oid, bigint);
> 
> The upgrade script of an extension is launched by the backend in the
> context of an extension, so these three queries should not be needed,
> as far as I recall.

Agreed. I've done it as it was in previous versions. But I'm sure those
are unnecessary.

> Wouldn't it be better to do this kind of refactoring in its own patch
> to make the follow-up changes more readable?  This function is
> changed
> to return a timestamp rather than void, but IS NOT NULL applied on
> the
> existing queries would also return true.  This would clean up quite a
> few diffs in the main patch..
Splitting this commit seems reasonable to me.

New version is attached.