On 5/20/25 21:28, Michael Paquier wrote:
The fix has been applied now on HEAD. I've also checked the state of
pgaudit on branch dev-pg18, with the regression getting fixed. Things
look clear now, at least from my side.
Just retested and it looks good from my side, too. Thanks again!
-David
On Tue, May 20, 2025 at 02:04:20PM +, David Steele wrote:
> I did a careful examination of the remaining diffs (there are quite a few)
> and in every case I consider them to be beneficial, i.e. they make the
> output more targeted and readable.
>
> I did not do a real code review, but I did no
On 5/20/25 07:34, Sami Imseih wrote:
Tested the patch and it looks good to me.
Not that I thought it would fail, but I also confirmed the pgaudit case
works as expected.
I also tested and everything looks good with the patch.
I did a careful examination of the remaining diffs (there are quite
Tested the patch and it looks good to me.
Not that I thought it would fail, but I also confirmed the pgaudit case
works as expected.
```
LOG: AUDIT: SESSION,10,2,DDL,CREATE TABLE,,,"CREATE TABLE do_table
(""weird name""
INT)",
LOG: AUDIT: SESSION,10,3,DDL,DROP TABLE,,,DROP table do_table,
DO
``
On Tue, May 20, 2025 at 09:58:04AM +0200, Anthonin Bonnefoy wrote:
> Looking at the tests, there are 2 additionals empty DO blocks:
> +DO $$
> +DECLARE BEGIN
> +END $$;
>
> What's the point of those? They won't be visible in the output since
> we have 'toplevel IS FALSE' in the pg_stat_statements
On Tue, May 20, 2025 at 5:59 AM Michael Paquier wrote:
> Once I have fixed that, I've been a bit puzzled by the difference in
> output in the tests of pg_overexplain, but I think that the new output
> is actually the correct one: the queries whose plan outputs have
> changed are passed as argument
On Tue, May 20, 2025 at 11:59 AM Michael Paquier wrote:
>
> On Tue, May 20, 2025 at 08:38:47AM +0900, Michael Paquier wrote:
> > With the semicolon in place, stmt_len gets set for the last query of
> > the string. Still digging more..
>
> And got it. The problem is that we are failing to update
On Tue, May 20, 2025 at 08:38:47AM +0900, Michael Paquier wrote:
> With the semicolon in place, stmt_len gets set for the last query of
> the string. Still digging more..
And got it. The problem is that we are failing to update the
statement location in a couple of cases with subqueries, and tha
On Mon, May 19, 2025 at 05:10:14PM -0500, Sami Imseih wrote:
> I am still not sure why this is the case, but wanted to share this
> for now.
Hmm. Something seems to not be compiling well for the final query of
a stmtmulti in gram.y with updateRawStmtEnd(), as we rely on the
position of the semico
> It is also possible that the regression is not coming from
> 499edb0 but I do not see another obvious candidate.
I used pg_stat_statements to repro the issue, and a bisect
resulted in 499edb0 being the source of the regression.
```
select pg_stat_statements_reset();
set pg_stat_statements.trac
On Mon, May 19, 2025 at 02:31:24PM +, David Steele wrote:
> But in PG18 we now get:
>
> NOTICE: AUDIT: SESSION,35,2,DDL,CREATE TABLE,TABLE,public.do_table,"CREATE
> TABLE do_table (""weird name"" INT)",
> NOTICE: AUDIT: SESSION,35,3,DDL,DROP TABLE,TABLE,public.do_table,"CREATE
> TABLE do_tab
Hackers,
499edb0 introduced more precise locations for nested statements. In
general it works quite well and has made the pgAudit output much more
readable -- so kudos for that.
However, I have noticed one regression in the pgAudit tests. We have
this somewhat odd statement intentionally cra
12 matches
Mail list logo
