| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pasi Eronen <pe(at)iki(dot)fi> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17362: Error "could not find block containing chunk" when using index with icu collation on CentOS 7 |
| Date: | 2022-02-02 17:49:27 |
| Message-ID: | 14517.1643824167@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Pasi Eronen <pe(at)iki(dot)fi> writes:
> In varlena.c, ssup_extra->buf1 and buf2 are initialized to 1024-byte
> buffers, allocated from the ssup->ssup_cxt memory context. That
> strange-looking test string in my bug report just happens to be 1044
> bytes, so a larger buffer is needed at some point.
> If growing the buffer happens in "varstrfastcmp_locale", it uses
> MemoryContextAlloc(ssup->ssup_cxt, ...). But if growing the buffer
> happens in "varstr_abbrev_convert", it just calls "palloc" - and
> apparently the current memory context is not ssup_cxt at this point
> (at least according to debugging printf's I added).
> Might this be causing the problem?
Indeed. The whole thing seems flat-out wrong to me: repalloc
would be shorter, safer, and more idiomatic.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pragati Agarwal | 2022-02-02 17:59:45 | Re: Postgresql error : PANIC: could not locate a valid checkpoint record |
| Previous Message | Pasi Eronen | 2022-02-02 15:46:25 | Re: BUG #17362: Error "could not find block containing chunk" when using index with icu collation on CentOS 7 |