From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Server crash with certain encodings |
Date: | 2016-02-29 03:31:27 |
Message-ID: | 20894.1456716687@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thom Brown <thom(at)linux(dot)com> writes:
> I can crash the server in 9.4, 9.5 and 9.6 when doing the following on
> Linux:
Hm, would you confirm that you get a stack trace like this:
#0 0x000000397ee32625 in raise () from /lib64/libc.so.6
#1 0x000000397ee33e05 in abort () from /lib64/libc.so.6
#2 0x000000397ee70537 in __libc_message () from /lib64/libc.so.6
#3 0x000000397ee75f4e in malloc_printerr () from /lib64/libc.so.6
#4 0x000000397ee78cad in _int_free () from /lib64/libc.so.6
#5 0x000000000076ce70 in free_struct_lconv () at pg_locale.c:394
#6 PGLC_localeconv () at pg_locale.c:460
#7 0x0000000000717cd5 in cash_in (fcinfo=<value optimized out>) at cash.c:112
Looks like we're getting confused about allocation/freeing of lconv
data --- I've not dug into it more closely than to reproduce the crash.
Aside from that, though, it's not really clear to me that it's sensible to
allow an lc_monetary (or lc_anything) setting that specifies an encoding
different from the database encoding. Should your example have failed at
the SET lc_monetary step? If not, what would you expect that to mean?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-02-29 06:43:03 | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
Previous Message | Thom Brown | 2016-02-29 02:15:54 | Server crash with certain encodings |