From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | legrand legrand <legrand_legrand(at)hotmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statements: duplicated external query texts with MSY2 |
Date: | 2020-06-11 11:16:48 |
Message-ID: | 198017.1591874208@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Mon, Jun 8, 2020 at 11:28 PM legrand legrand
> <legrand_legrand(at)hotmail(dot)com> wrote:
>> pgbench -i postgres
>> pgbench -c20 -t5 postgres
>> generates the attached pgss_query_texts.stat,
>> where "BEGIN" and "UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2"
>> appears 20 times ...
> Is the duplication only in the query text file? Looking at the code
> the query text part is stored holding a shared lwlock, so it seems
> like an expected behavior (less overhead but might store duplicated
> query text)
I agree, this looks like operating-as-designed: different processes can
store the same query text and only later discover that they were creating
duplicate hash table entries. It's a bit surprising that the duplication
would be reproducible, but it just depends on timing. Maybe this is
telling us something about how scheduling works under MSYS2.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-06-11 11:58:31 | Re: BUG #16476: pgp_sym_encrypt_bytea with compress-level=6 : Wrong key or corrupt data |
Previous Message | Thomas Munro | 2020-06-11 10:12:47 | Re: Potential G2-item cycles under serializable isolation |