Re: Proposal: PqSendBuffer removal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: PqSendBuffer removal
Date
Msg-id 9811.1583607297@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: PqSendBuffer removal  (Andres Freund <andres@anarazel.de>)
Responses Re: Proposal: PqSendBuffer removal  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> What I'm thinking is that we'd have pg_beginmessage() (potentially a
> different named version) initialize the relevant StringInfo basically as

> (StringInfoData){
>     .data = PqSendPointer,
>     .len = 0,
>     .alloc_offset = PqSendBuffer - PqSendBuffer
> }

This seems way overcomplicated compared to what I suggested (ie,
just let internal_putbytes bypass the buffer in cases where the
data would get flushed next time through its loop anyway).
What you're suggesting would be a lot more invasive and restrictive
--- for example, why is it a good idea to have a hard-wired
assumption that we can't build more than one message at once?

I'm also concerned that trying to do too much optimization here will
break one of the goals of the existing code, which is to not get into
a situation where an OOM failure causes a wire protocol violation
because we've already sent part of a message but are no longer able to
send the rest of it.  To ensure that doesn't happen, we must construct
the whole message before we start to send it, and we can't let
buffering of the last message be too entwined with construction of the
next one.  Between that and the (desirable) arms-length separation
between datatype I/O functions and the actual I/O, a certain amount of
data copying seems unavoidable.

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: More tests to stress directly checksum_impl.h
Next
From: Tom Lane
Date:
Subject: Re: range_agg