| 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. |