From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashwin Agrawal <ashwinstar(at)gmail(dot)com> |
Subject: | Re: brininsert optimization opportunity |
Date: | 2023-12-11 15:41:45 |
Message-ID: | dda974ae-f1d4-22ff-f189-cca340c4583c@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/11/23 16:00, Alexander Lakhin wrote:
> Hello Tomas and Soumyadeep,
>
> 25.11.2023 23:06, Tomas Vondra wrote:
>> I've done a bit more cleanup on the last version of the patch (renamed
>> the fields to start with bis_ as agreed, rephrased the comments / docs /
>> commit message a bit) and pushed.
>
> Please look at a query, which produces warnings similar to the ones
> observed upthread:
> CREATE TABLE t(a INT);
> INSERT INTO t SELECT x FROM generate_series(1,10000) x;
> CREATE INDEX idx ON t USING brin (a);
> REINDEX index CONCURRENTLY idx;
>
> WARNING: resource was not closed: [1863] (rel=base/16384/16389,
> blockNum=1, flags=0x93800000, refcount=1 1)
> WARNING: resource was not closed: [1862] (rel=base/16384/16389,
> blockNum=0, flags=0x93800000, refcount=1 1)
>
> The first bad commit for this anomaly is c1ec02be1.
>
Thanks for the report. I haven't investigated what the issue is, but it
seems we fail to release the buffers in some situations - I'd bet we
fail to call the cleanup callback in some place, or something like that.
I'll take a look tomorrow.
> May be you would also want to fix in passing some typos/inconsistencies
> introduced with recent brin-related commits:
> s/bs_blkno/bt_blkno/
> s/emptry/empty/
> s/firt/first/
> s/indexinsertcleanup/aminsertcleanup/
> s/ maxRange/ nextRange/
> s/paga /page /
>
Definitely. Thanks for noticing those!
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2023-12-11 15:56:13 | Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans) |
Previous Message | Tomas Vondra | 2023-12-11 15:36:08 | Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION |