Re: Let's stop with the retail rebuilds of src/port/ files already
От | Andrew Dunstan |
---|---|
Тема | Re: Let's stop with the retail rebuilds of src/port/ files already |
Дата | |
Msg-id | 4d8022f7-5e25-e5b0-0926-4a99d60f3ffb@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Let's stop with the retail rebuilds of src/port/ files already (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 09/27/2018 03:48 PM, Tom Lane wrote: > I wrote: >> Here's a partial patch for that: it adds the third build variant >> to src/port/ and teaches libpq to use it. We'd want to likewise >> modify src/common/ and fix up other callers such as ecpg, but this >> seems to be enough to test whether the idea works or not. >> ... >> What I think would make sense is to push this and see what the >> buildfarm thinks of it. If there are unfixable problems then >> we won't have wasted time fleshing out the concept. Otherwise, >> I'll do the remaining pieces. > Well, the buildfarm did turn up one problem: on really old macOS > (cf prairiedog) the libpq link step fails with > > ld: symbols names listed in -exported_symbols_list: exports.list not in linked objects > _pqsignal > > Apparently, with that linker, the exported symbols list is resolved > against just what is found in the listed *.o files, not anything pulled > in from a library file. > > Now, the question that raises in my mind is why is libpq.so exporting > pqsignal() at all? Probably there was once a reason for it, but nowadays > I would think that any client program using pqsignal() should get it > from -lpgport, not from libpq. Having more than one place to get it from > seems more likely to create issues than solve them. And we certainly > do not document it as a function available from libpq. > > So my recommendation is to remove pqsignal from libpq's exports.txt. > I've verified that prairiedog builds happily with that change, > confirming my expectation that all consumers of the symbol can get it > from someplace else. > > Now, if we go forward with that solution, there will be issues with > some other things that libpq exports without having defined itself: > > src/backend/utils/mb/wchar.c: > pg_utf_mblen > src/backend/utils/mb/encnames.c: > pg_encoding_to_char > pg_char_to_encoding > pg_valid_server_encoding > pg_valid_server_encoding_id > > Now, I'd already had my eye on those two files, because after applying a > similar fix for src/common/, those two files would be the only ones that > libpq needs to symlink from somewhere else. > > What I was thinking of proposing was to move those two files out of the > backend and into src/common/, thereby normalizing their status as > modules available in both frontend and backend, and removing the need > for a special build rule for them in libpq. (initdb could be simplified > too.) Per this discovery, we'd need to also remove these symbols from > libpq's exports list, meaning that clients *must* get them from -lpgcommon > not from libpq. > > There's a small chance that this'd break third-party clients that > are using these symbols out of libpq. We've never documented them > as being available, but somebody might be using them anyway. > If that does happen, it could be repaired by linking against -lpgcommon > along with libpq, but it'd possibly still make people unhappy. > Seems a small enough price to pay. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления:
Следующее
От: Tomas VondraДата:
Сообщение: Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)