Re: Refactoring postmaster's code to cleanup after child exit - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Refactoring postmaster's code to cleanup after child exit
Date
Msg-id e2lvootbrfb35ufugjdwwk77sa7ff6vyhaygtbdxwcnhmpjdkk@ankqkqknlrx7
Whole thread Raw
In response to Re: Refactoring postmaster's code to cleanup after child exit  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2024-09-10 13:33:36 -0400, Robert Haas wrote:
> On Tue, Sep 10, 2024 at 12:59 PM Andres Freund <andres@anarazel.de> wrote:
> > I still think that we'd be better off to just return an error to the client in
> > postmaster, rather than deal with this dead-end children mess. That was
> > perhaps justified at some point, but now it seems to add way more complexity
> > than it's worth. And it's absurdly expensive to fork to return an error. Way
> > more expensive than just having postmaster send an error and close the socket.
> 
> The tricky case is the one where the client write() -- or SSL_write() -- blocks.

Yea, SSL definitely does make it harder. But it's not exactly rocket science
to do non-blocking SSL connection establishment. After all, we do manage to
do so in libpq...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Next
From: Noah Misch
Date:
Subject: Re: Use read streams in pg_visibility