Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding' - Mailing list pgsql-hackers
| From | Mikael Sand |
|---|---|
| Subject | Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding' |
| Date | |
| Msg-id | CAAwAxZdcEmQKU6POTjBXbVO3_fkbHpit3fvKXF-OhAZg53jT=Q@mail.gmail.com Whole thread Raw |
| In response to | Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding' (Mikael Sand <msand@seaber.io>) |
| Responses |
Re: Build issue with postgresql 17 undefined reference to `pg_encoding_to_char' and `pg_char_to_encoding'
|
| List | pgsql-hackers |
Btw Aleksander
Br Mikael
On Thu, Oct 10, 2024 at 10:22 PM Mikael Sand <msand@seaber.io> wrote:
Hi AleksanderOk. So no actual benefit from using dynamic?Well, it seems postgresql and all dependencies already support it, no?Doesn't go do static linking by default / prefer it? Unless you use some part that uses CGO, in which case many go developers appear to disable CGO anyway and use the plain go implementation instead.Similarly, the rust community seems to have a preference / strong support for static, some with alpine, musl, etc.We're still developing this part of our system, and do intend to measure the difference, for this we need to be able to build the static version as well. I can post results once we have them. Have you measured the difference?Br MikaelOn Thu, Oct 10, 2024 at 10:08 PM Aleksander Alekseev <aleksander@timescale.com> wrote:Hi Mikael,
> We use static linking and link time optimization to squeeze the last bits of performance out of the code in our most performance-critical queries, and it simplifies our security audits to have a static binary running inside chainguard/static as the data we handle is sensitive/business critical.
No comments about the security aspect. I'm not a security expert so I
leave this topic for somebody for whom this is an area of expertise.
I don't buy the optimization part. The performance gain you get is
next to nothing compared to the time spent transferring SQL queries
over the network / UDP sockets, parsing and planning them, accessing
the disk, waiting for the locks, etc. Unless you actually measured it
in order to show the opposite which I seriously doubt you did. A
better time investment would be finding actual bottlenecks in the
given system in order to be able to eliminate them.
> Aleksander, do you have something against static linking or am I reading you wrong? I've seen this sentiment in several places but never understood why anyone would hold this position. Could you elaborate?
The question is whether it's practical for the PostgreSQL community to
put effort into supporting / testing static linking of libpq.
Personally I'm not convinced that demanding from every open-source
project in existence to support static linking is a sustainable idea
in the long run, given the fact that there are technologies like
Docker and programming languages like Go (with pgx client).
--
Best regards,
Aleksander Alekseev
pgsql-hackers by date: