| 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: | Whole Thread | Raw Message | 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 |