From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pltcl crash on recent macOS |
Date: | 2022-06-13 16:01:08 |
Message-ID: | 3809545.1655136068@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Mon, Jun 13, 2022 at 6:53 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>> frame #1: 0x00007ff803a28751 libsystem_c.dylib`hash_search + 215
>> frame #2: 0x0000000110357700
>> pltcl.so`compile_pltcl_function(fn_oid=16418, tgreloid=0,
> Hmm, I can’t reproduce that….
I can't either, although I'm using the macOS-provided Tcl code,
which still works fine for me. (I grant that Apple might desupport
that someday, but they haven't yet.) sifaka and longfin aren't
unhappy either; although sifaka is close to identical to my laptop.
Having said that, I wonder whether the position of the -bundle_loader
switch in the command line is relevant to which way the hash_search
reference is resolved. Seems like we could put it in front of the
various -l options if that'd help.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-06-13 16:05:38 | Re: pgcon unconference / impact of block size on performance |
Previous Message | Merlin Moncure | 2022-06-13 15:42:31 | Re: pgcon unconference / impact of block size on performance |