> On 3 Nov 2021, at 12:14, Daniel Gustafsson wrote:
>
> The commitfest CI times out on all platforms and never finishes when running
> make check with this patch, so unless the patch is dropped due to concerns
> already raised then that seems like a good thing to fix.
As the thread has stalled,
The commitfest CI times out on all platforms and never finishes when running
make check with this patch, so unless the patch is dropped due to concerns
already raised then that seems like a good thing to fix.
--
Daniel Gustafsson https://vmware.com/
Hi,
On 2021-06-17 16:37:51 -0700, Jeff Davis wrote:
> In theory, it could break a client that issues Parse+Bind+Execute for a
> CopyIn/CopyBoth command without a Sync, but I'm not sure there are any
> clients that do that, and it's arguable whether the documentation
> permitted that or not
On Fri, 2021-07-02 at 08:44 -0400, Robert Haas wrote:
> Right, that seems like a good goal. Thinking about this a little
> more,
> it's only holding off *cancel* interrupts, not *all* interrupts, so
> presumably you can still terminate the backend in this state. That's
> not so bad, and it's not
On Fri, Jul 2, 2021 at 1:55 AM Jeff Davis wrote:
> On Wed, 2021-06-30 at 12:25 -0400, Robert Haas wrote:
> > I am not sure whether this works or not. Holding off cancel
> > interrupts
> > across possible network I/O seems like a non-starter. We have to be
> > able to kill off connections that
On Wed, 2021-06-30 at 12:25 -0400, Robert Haas wrote:
> I am not sure whether this works or not. Holding off cancel
> interrupts
> across possible network I/O seems like a non-starter. We have to be
> able to kill off connections that have wedged.
I was following a pattern that I saw in
On Thu, Jun 17, 2021 at 7:37 PM Jeff Davis wrote:
> What if we simply mandate that a Sync must be sent before the server
> will respond with CopyInResponse/CopyBothResponse, and the client must
> send another Sync after CopyDone/CopyFail (or after receiving an
> ErrorResponse, if the client isn't
On Thu, 2021-06-17 at 12:42 -0400, Robert Haas wrote:
> On a casual read-through this seems pretty reasonable, but it
> essentially documents that libpq is doing the wrong thing by sending
> Sync unconditionally. As I say above, I disagree with that from a
> philosophical perspective. Then again,
On Wed, Jun 16, 2021 at 5:15 PM Jeff Davis wrote:
> * A normal command, where you know that you've sent everything that you
> will send. In this case, the client needs to send the Sync message in
> order to get the ReadyForQuery message.
>
> * A command that initiates CopyIn/CopyBoth, where you
Jeff Davis writes:
> One thing I don't fully understand is what would happen if the client
> issued the Sync as the *first* message in an extended-protocol series.
That'd cause the backend to send ReadyForQuery, which'd likely
confuse the client.
> But I think you're correct in saying that the
On Mon, 2021-06-14 at 10:51 -0400, Robert Haas wrote:
> but if
> > > you use the extended query protocol, then the result is a
> > > hopeless
> > > mess, because the protocol is badly designed:
> > >
After looking in more detail, I think I understand a bit better.
Clients don't differentiate
On Fri, Jun 11, 2021 at 6:12 PM Jeff Davis wrote:
> On Fri, 2021-06-11 at 16:57 -0400, Robert Haas wrote:
> > My impression was that CopyBoth can be initiated either way,
>
> The docs say: "In either physical replication or logical replication
> walsender mode, only the simple query protocol can
On Fri, 2021-06-11 at 16:57 -0400, Robert Haas wrote:
> My impression was that CopyBoth can be initiated either way,
The docs say: "In either physical replication or logical replication
walsender mode, only the simple query protocol can be used." Is there
some way to initiate CopyBoth outside of
On Thu, Jun 10, 2021 at 9:26 PM Jeff Davis wrote:
> The docs currently say (introduced in commit 91fa853):
>
> "In the event of a backend-detected error during copy-both mode, the
> backend will issue an ErrorResponse message, discard frontend messages
> until a Sync message is received, and then
The docs currently say (introduced in commit 91fa853):
"In the event of a backend-detected error during copy-both mode, the
backend will issue an ErrorResponse message, discard frontend messages
until a Sync message is received, and then issue ReadyForQuery and
return to normal processing."
But
15 matches
Mail list logo
