Thread: Sync vs Flush

Sync vs Flush

From
Jaka Jančar
Date:
Hi,

For an extended query that needs to get parameter types before sending them, is there a difference in doing:

Parse, Describe statement, Flush, Bind, Execute, Sync
vs
Parse, Describe statement, Sync, Bind, Execute, Sync

Of course, there will be an additional ReadyForQuery in the latter case, but other than that.

Thanks!

Jaka

Re: Sync vs Flush

From
Tom Lane
Date:
=?UTF-8?B?SmFrYSBKYW7EjWFy?= <jaka@kubje.org> writes:
> For an extended query that needs to get parameter types before sending
> them, is there a difference in doing:

> Parse, Describe statement, Flush, Bind, Execute, Sync
> vs
> Parse, Describe statement, Sync, Bind, Execute, Sync

Sync is a resync point after an error, so the real question is what
you want to have happen if you get some kind of error during the Parse.
If you expect that the app wouldn't proceed with issuing Bind/Execute
then you want to do it the second way.

I suppose you could do

    Send Parse/Describe/Flush
    Read results
    If OK:
       Send Bind/Execute/Sync
    else:
       Send Sync    # needed to get back to normal state

but that doesn't sound all that convenient.

            regards, tom lane



Re: Sync vs Flush

From
Jaka Jančar
Date:
Hehe, that's exactly what I am doing, which is why I thought of just sending two Syncs. Good to hear it's OK.

From reading the Extended query protocol docs, I somehow got the impression that you need to do everything within one cycle, and send Sync only at the end of the cycle:

 - "The extended query protocol breaks down the above-described simple query protocol into multiple steps."
 - "[Only] At completion of each series of extended-query messages, the frontend should issue a Sync message."
 - "A Flush [and not Sync] must be sent [...] if the frontend wishes to examine the results of that command before issuing more commands."
 - "The simple Query message is approximately equivalent to the series Parse, Bind, portal Describe, Execute, Close, Sync."

What is a common situation for using Flush instead of Sync?
When would you need and wait for the output, get an error, yet still proceed to send further messages that you would want the server to ignore?

Jaka

On Thu, Jul 2, 2020 at 12:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jaka Jančar <jaka@kubje.org> writes:
> For an extended query that needs to get parameter types before sending
> them, is there a difference in doing:

> Parse, Describe statement, Flush, Bind, Execute, Sync
> vs
> Parse, Describe statement, Sync, Bind, Execute, Sync

Sync is a resync point after an error, so the real question is what
you want to have happen if you get some kind of error during the Parse.
If you expect that the app wouldn't proceed with issuing Bind/Execute
then you want to do it the second way.

I suppose you could do

        Send Parse/Describe/Flush
        Read results
        If OK:
           Send Bind/Execute/Sync
        else:
           Send Sync    # needed to get back to normal state

but that doesn't sound all that convenient.

                        regards, tom lane

Re: Sync vs Flush

From
Tom Lane
Date:
=?UTF-8?B?SmFrYSBKYW7EjWFy?= <jaka@kubje.org> writes:
> What is a common situation for using Flush instead of Sync?
> When would you need and wait for the output, get an error, yet still
> proceed to send further messages that you would want the server to ignore?

The only case I can think of offhand is bursting some time-consuming
queries to the server, that is sending this all at once:

   Execute, Flush, Execute, Flush, Execute, Flush, Execute, Sync

This presumes that, if an earlier query fails, you want the rest
to be abandoned; else you'd use Syncs instead.  But if you leave
out the Flushes then you won't see the tail end of (or indeed
maybe none of) the output of an earlier query until a later query
fills the server's output buffer.  So if you're hoping to overlap
the client's processing with the server's you want the extra flushes.

            regards, tom lane



Re: Sync vs Flush

From
Jaka Jančar
Date:
Makes sense, thanks!

On Thu, Jul 2, 2020 at 15:29 Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jaka Jančar <jaka@kubje.org> writes:
> What is a common situation for using Flush instead of Sync?
> When would you need and wait for the output, get an error, yet still
> proceed to send further messages that you would want the server to ignore?

The only case I can think of offhand is bursting some time-consuming
queries to the server, that is sending this all at once:

   Execute, Flush, Execute, Flush, Execute, Flush, Execute, Sync

This presumes that, if an earlier query fails, you want the rest
to be abandoned; else you'd use Syncs instead.  But if you leave
out the Flushes then you won't see the tail end of (or indeed
maybe none of) the output of an earlier query until a later query
fills the server's output buffer.  So if you're hoping to overlap
the client's processing with the server's you want the extra flushes.

                        regards, tom lane