From: | Jaka Jančar <jaka(at)kubje(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Sync vs Flush |
Date: | 2020-07-02 20:03:00 |
Message-ID: | CAMUPXmrU-yEJ1CpNweF7gFPcmeXtM8ezvrvNz+_Gg6GFREOwdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Makes sense, thanks!
On Thu, Jul 2, 2020 at 15:29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?UTF-8?B?SmFrYSBKYW7EjWFy?= <jaka(at)kubje(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2020-07-02 20:05:23 | Re: pg_read_file() with virtual files returns empty string |
Previous Message | Tom Lane | 2020-07-02 19:55:31 | Re: Use of "long" in incremental sort code |