From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Danger of automatic connection reset in psql |
Date: | 2016-10-28 12:47:52 |
Message-ID: | CAFjFpRdi0Jmx2qiRHNbYDMpWBo50-Kvt9fkd3ZqDmAj0988mfA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 20, 2016 at 5:25 PM, Oleksandr Shulgin
<oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
> On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin
> <oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
>>
>>
>> Since this is already an improvement, I'm attaching a patch.
>>
>> If on the other hand, someone is pasting into psql's terminal a block of
>> commands enclosed in BEGIN/COMMIT, the same bug is triggered: BEGIN doesn't
>> have effect and the rest of commands run outside of transaction.
>>
>> Is it possible at all to protect against the latter case? How?
>
>
> One idea I was just suggested is to make interactive psql sessions buffer in
> all available input, before it's going to block. This way it doesn't matter
> if the multiple statements are appearing on one line or are being pasted.
>
> Feasible?
psql seems to be reading one line (or upto EOF) at a time. If it finds
a ';' in the fetched input, it sends the query to the server and
fetches the result. That's when it will notice a server crash. The
next time it will try to fetch the line, I doubt if psql has any way
to tell, whether the block of commands was pasted all at a time or
entered one at a time.y It's same thing for psql and really I guess
it's the same thing for any interactive program. I guess, all the
pasted result is not in psql's buffers if it spans multiple lines and
has ';' in-between. So, I don't think, it's feasible to protect
against that one.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2016-10-28 12:49:51 | Re: Streaming basebackups vs pg_stat_tmp |
Previous Message | Robert Haas | 2016-10-28 12:46:02 | Re: Fast Default WIP patch for discussion |