Re: [HACKERS] BRIN de-summarize ranges

On 2017-02-28 04:56:43 Alvaro Herrera wrote:
> Here's a small patch to make a BRIN page range unsummarized.  This is
> useful if data has been deleted, and the heap pages are now used for
> completely different data.

Hi,

I tried to apply your patch and use it. Applying and "make check" were successed.

However, I found that when calling brin_desummarize_range successively, an assertion is failed. It seems to me that it
occurswhen desummarizing a revmap page that is already desummarized.
 

The tried queries and their outputs are the followings:

$ CREATE SCHEMA test_sc;
CREATE SCHEMA
$ CREATE TABLE test_sc.test(a int);
CREATE TABLE
$ INSERT INTO test_sc.test SELECT s FROM generate_series(1, 10000) s;
INSERT 0 10000
$ CREATE INDEX idx_brin ON test_sc.test USING brin(a);
CREATE INDEX
$ SELECT brin_desummarize_range('test_sc.idx_brin', 1);brin_desummarize_range 
------------------------
(1 row)

$ SELECT brin_desummarize_range('test_sc.idx_brin', 1);
psql:check_brin_desum.sql:10: server closed the connection unexpectedly       This probably means the server terminated
abnormally      before or while processing the request.
 
psql:check_brin_desum.sql:10: connection to server was lost


Then, the server log is the following:

TRAP: FailedAssertion("!(!LWLockHeldByMe(((LWLock*) (&(buf)->content_lock))))", File: "bufmgr.c", Line: 1714)
2017-03-22 15:06:12.842 JST [23107] LOG:  server process (PID 23186) was terminated by signal 6: Aborted
2017-03-22 15:06:12.842 JST [23107] DETAIL:  Failed process was running: SELECT
brin_desummarize_range('test_sc.idx_brin',1);
 


When assertion is failed, the following brinRevmapTerminate function is called. Then, it tries to release
revmap->rm_currBufby ReleaseBuffer function and it is failed.
 

+bool
+brinRevmapDesummarizeRange(Relation idxrel, BlockNumber heapBlk)
+{
...
+    if (!ItemPointerIsValid(iptr))
+    {
+        /* no index tuple: range not summarized, we're done */
+        brinRevmapTerminate(revmap);
+        return true;
+    }

--
Regards,
Eiji Seki
Fujitsu