Re: [HACKERS] SIGSEGV in BRIN autosummarize - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: [HACKERS] SIGSEGV in BRIN autosummarize
Date
Msg-id 20171017124924.GA4398@telsasoft.com
Whole thread Raw
In response to Re: [HACKERS] SIGSEGV in BRIN autosummarize  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] SIGSEGV in BRIN autosummarize
List pgsql-hackers
On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote:
> Justin Pryzby wrote:
> 
> > #1  0x00000000006a52e9 in perform_work_item (workitem=0x7f8ad1f94824) at autovacuum.c:2676
> >         cur_datname = 0x298c740 "no 1 :vartype 1184 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1
:varoattno1 :location 146} {CONST :consttype 1184 :consttypmod -1 :constcollid 0 :constlen 8 :constbyval true
:constisnullfal"...
 
> >         cur_nspname = 0x298c728 "s ({VAR :varno 1 :varattno 1 :vartype 1184 :vartypmod -1 :varcollid 0 :varlevelsup
0:varnoold 1 :varoattno 1 :location 146} {CONST :consttype 1184 :consttypmod -1 :constcollid 0 :constlen 8
:constbyv"...
> >         cur_relname = 0x298cd68 "cdrs_eric_msc_sms_2017_10_14_startofcharge_idx"
> >         __func__ = "perform_work_item"
> 
> cur_datname here seems corrupted -- it points halfway into cur_nspname,
> which is also a corrupt value.  And I think that's because we're not
> checking that the namespace OID is a valid value before calling
> get_namespace_name on it.  And I'm betting that these values are all not
> what we expect, because we're not checking that we're in the correct
> database before trying to execute the work item.  I don't quite
> understand how this results in an invalid string rather than just a
> NULL, as I would have expected.

I'm happy to try the patch, but in case it makes any difference, we have few
DBs/schemas:

postgres=# \dn List of schemas Name  |  Owner   
--------+----------public | postgres
(1 row)

postgres=# \l+                                                                   List of databases  Name    |  Owner
|Encoding |   Collate   |    Ctype    |   Access privileges   |  Size   | Tablespace |                Description
         
 

-----------+----------+----------+-------------+-------------+-----------------------+---------+------------+--------------------------------------------gtt
     | pryzbyj  | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                       | 2215 GB | pg_default | postgres  |
postgres| UTF8     | en_US.UTF-8 | en_US.UTF-8 |                       | 76 GB   | pg_default | default administrative
connectiondatabasetemplate0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +| 7625 kB |
pg_default| unmodifiable empty database          |          |          |             |             |
postgres=CTc/postgres|         |            | template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
postgres=CTc/postgres+|7485 kB | pg_default | default template for new databases          |          |          |
     |             | =c/postgres           |         |            | 
 
(4 rows)

Note that db:postgres is of substantial size since I set log_statement=all and
log_destination=stderr,csv, and import all CSVs into a table heirarchy in
db:postgres.  There are 3 BRIN indices per (daily child) table in db:gtt (and
none in postgres, although that's probably a good idea for the timestamp column
once all our customers are upgraded to PG10).

Justin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: [HACKERS] SIGSEGV in BRIN autosummarize
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] SIGSEGV in BRIN autosummarize