From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Jeremy Evans <code(at)jeremyevans(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
Date: | 2018-09-09 19:29:35 |
Message-ID: | 22025.1536521375@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> Is this potentially also a problem for libpqwalreceiver, which also
> loads libpq?
As far as I can see, only libpq and the ECPG libraries build their
own copies of any src/port or src/common files, and all of them already
have version scripts. If libpqwalreceiver tried to incorporate any
such files and compile them under FRONTEND rules, it'd need a version
script as well. But I think that code is probably content to operate
under backend rules, so it'll just use the functions from the core
backend and be happy. Hence, no clear need for a version script there.
I think the patches I committed today are sufficient to close this bug,
unless further testing reveals that the problem occurs on additional
platforms. The buildfarm results so far don't suggest that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-09-09 20:05:04 | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
Previous Message | PG Bug reporting form | 2018-09-09 16:14:45 | BUG #15376: Postgres sql 9.4.19 pg_upgrade stops with error The source cluster was not shut down cleanly. |