| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Bernd Helmle <mailings(at)oopsware(dot)de>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
| Subject: | Re: Allowing REINDEX to have an optional name |
| Date: | 2022-07-15 14:03:24 |
| Message-ID: | 3370903.1657893804@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Ah, one theory is that the libpq_pipeline program is getting linked to
> an installed version of libpq that doesn't contain the fixes. Maybe you
> can do `ldd /path/to/libpq_pipeline` and see which copy of libpq.so it
> is picking up?
That's pronounced "otool -L" on macOS. But in any case, it's going
to point at the installation directory. One of the moving parts here
is that "make check" will try to override the rpath that otool tells
you about to make test programs use the libpq.dylib from the build tree.
I say "try" because if you've got SIP enabled (see what "csrutil status"
tells you), it will fail to do so and the installed libpq will be used.
Maybe that's old.
Standard recommendation on macOS with SIP on is to always do "make
install" before "make check".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhenghua Lyu | 2022-07-15 14:06:54 | Adjust ndistinct for eqjoinsel |
| Previous Message | Andrew Dunstan | 2022-07-15 13:51:29 | Re: SQL/JSON documentation JSON_TABLE |