> On 28 Sep 2017, at 14:55, Yugo Nagata wrote:
>
> On Sun, 3 Sep 2017 22:47:10 +0200
> Daniel Gustafsson wrote:
>
> I have reviewed your latest patch.
>
> I can apply this to the master branch and build this successfully,
> and the behavior is as expected.
>
> However, here are some commen
On Sun, 3 Sep 2017 22:47:10 +0200
Daniel Gustafsson wrote:
I have reviewed your latest patch.
I can apply this to the master branch and build this successfully,
and the behavior is as expected.
However, here are some comments and suggestions.
> 135 + char *buffer = palloc0(MA
> On 02 Sep 2017, at 02:21, Thomas Munro wrote:
>
> On Fri, Jun 23, 2017 at 1:48 AM, Daniel Gustafsson wrote:
>> Good point. I’ve attached a new version which issues a NOTICE on truncation
>> and also addresses all other comments so far in this thread. Thanks a lot
>> for
>> the early patch r
On Fri, Jun 23, 2017 at 1:48 AM, Daniel Gustafsson wrote:
> Good point. I’ve attached a new version which issues a NOTICE on truncation
> and also addresses all other comments so far in this thread. Thanks a lot for
> the early patch reviews!
FYI this no longer builds because commit 81c5e46c490
On 06/26/2017 07:15 AM, Joel Jacobson wrote:
+1
On Tue, Jun 20, 2017 at 8:54 PM, Alvaro Herrera
wrote:
Unless you have a lot of users running psql manually, I don't see how
this is actually very useful or actionable. What would the user do with
the information? Hopefully your users already t
+1
On Tue, Jun 20, 2017 at 8:54 PM, Alvaro Herrera
wrote:
> Unless you have a lot of users running psql manually, I don't see how
> this is actually very useful or actionable. What would the user do with
> the information? Hopefully your users already trust that you'd keep the
> downtime to the
> On 22 Jun 2017, at 17:52, Dilip Kumar wrote:
>
> On Thu, Jun 22, 2017 at 7:18 PM, Daniel Gustafsson wrote:
>> Good point. I’ve attached a new version which issues a NOTICE on truncation
>> and also addresses all other comments so far in this thread. Thanks a lot
>> for
>> the early patch re
On Thu, Jun 22, 2017 at 7:18 PM, Daniel Gustafsson wrote:
> Good point. I’ve attached a new version which issues a NOTICE on truncation
> and also addresses all other comments so far in this thread. Thanks a lot for
> the early patch reviews!
>
> cheers ./daniel
I have done an initial review of
> On 22 Jun 2017, at 10:24, Yugo Nagata wrote:
>
> On Thu, 22 Jun 2017 09:24:54 +0900
> Michael Paquier wrote:
>
>> On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote:
>>> The message is truncated in SetBackendCancelMessage() for safety, but
>>> pg_{cancel|terminate}_backend() could thr
On Thu, 22 Jun 2017 09:24:54 +0900
Michael Paquier wrote:
> On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote:
> > The message is truncated in SetBackendCancelMessage() for safety, but
> > pg_{cancel|terminate}_backend() could throw an error on too long message, or
> > warning truncation
On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote:
> The message is truncated in SetBackendCancelMessage() for safety, but
> pg_{cancel|terminate}_backend() could throw an error on too long message, or
> warning truncation, to the caller as well. Personally I think a warning is
> the
> a
> On 21 Jun 2017, at 16:30, Yugo Nagata wrote:
>
> On Wed, 21 Jun 2017 12:06:33 +0900
> Michael Paquier wrote:
>
>> On Tue, Jun 20, 2017 at 3:24 AM, Daniel Gustafsson wrote:
>>> The message is stored in a new shmem area which is checked when the session
>>> is
>>> aborted. To keep things sim
On Wed, 21 Jun 2017 12:06:33 +0900
Michael Paquier wrote:
> On Tue, Jun 20, 2017 at 3:24 AM, Daniel Gustafsson wrote:
> > The message is stored in a new shmem area which is checked when the session
> > is
> > aborted. To keep things simple a small buffer is kept per backend for the
> > message
Hi,
Here are some comments for the patch.
+Datum
+pg_cancel_backend(PG_FUNCTION_ARGS)
+{
+ PG_RETURN_BOOL(pg_cancel_backend_internal(PG_GETARG_INT32(0), NULL));
+}
+Datum
+pg_cancel_backend_msg(PG_FUNCTION_ARGS)
+{
+ pid_t pid = PG_GETARG_INT32(0);
+ char *msg = text_to_cstring(
On Tue, Jun 20, 2017 at 3:24 AM, Daniel Gustafsson wrote:
> The message is stored in a new shmem area which is checked when the session is
> aborted. To keep things simple a small buffer is kept per backend for the
> message. If deemed too costly, keeping a central buffer from which slabs are
>
: Tuesday, June 20, 2017 12:44 PM
To: Alvaro Herrera
Cc: Satyanarayana Narlapuram ; Pavel
Stehule ; Daniel Gustafsson ;
PostgreSQL mailing lists
Subject: Re: [HACKERS] Optional message to user when terminating/cancelling
backend
On Tue, Jun 20, 2017 at 11:54 AM, Alvaro Herrera
wrote
Hi,
On 2017-06-19 20:24:43 +0200, Daniel Gustafsson wrote:
> When terminating, or cancelling, a backend it’s currently not possible to let
> the signalled session know *why* it was dropped. This has nagged me in the
> past and now it happened to come up again, so I took a stab at this. The
> att
On Tue, Jun 20, 2017 at 11:54 AM, Alvaro Herrera
wrote:
> Satyanarayana Narlapuram wrote:
> Unless you have a lot of users running psql manually, I don't see how
> this is actually very useful or actionable. What would the user do with
> the information? Hopefully your users already trust that
Satyanarayana Narlapuram wrote:
> +1.
>
> This really helps PostgreSQL Azure service as well. When we are doing
> the upgrades to the service, instead of abruptly terminating the
> sessions we can provide this message.
I think you mean "in addition to" rather than "instead of".
Unless you have a
Pavel Stehule
Sent: Monday, June 19, 2017 11:41 AM
To: Daniel Gustafsson
Cc: PostgreSQL mailing lists
Subject: Re: [HACKERS] Optional message to user when terminating/cancelling
backend
2017-06-19 20:24 GMT+02:00 Daniel Gustafsson
mailto:dan...@yesql.se>>:
When terminating, or cancell
2017-06-19 20:24 GMT+02:00 Daniel Gustafsson :
> When terminating, or cancelling, a backend it’s currently not possible to
> let
> the signalled session know *why* it was dropped. This has nagged me in the
> past and now it happened to come up again, so I took a stab at this. The
> attached patc
When terminating, or cancelling, a backend it’s currently not possible to let
the signalled session know *why* it was dropped. This has nagged me in the
past and now it happened to come up again, so I took a stab at this. The
attached patch implements the ability to pass an optional text message
22 matches
Mail list logo
