|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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.|