From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kris Jurka <books(at)ejurka(dot)com>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, eg(at)cybertec(dot)at, List pgsql-patches <pgsql-patches(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementing RESET CONNECTION ... |
Date: | 2005-06-05 04:00:31 |
Message-ID: | 42A278DF.5050709@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
Chris
Bruce Momjian wrote:
> What did we decide on RESET CONNECTION. Do we want an SQL command or
> something only the protocol can do?
>
> ---------------------------------------------------------------------------
>
> Oliver Jowett wrote:
>
>>(cc'ing -hackers)
>>
>>Karel Zak wrote:
>>
>>
>>>I think command status is common and nice feedback for client. I think
>>>it's more simple change something in JDBC than change protocol that is
>>>shared between more tools.
>>
>>There is a bit of a queue of changes that would be nice to have but
>>require a protocol version change. If we're going to change the protocol
>>for any of those we might as well handle RESET CONNECTION cleanly too.
>>
>>
>>>We need some common way how detect on client what's happen on server --
>>>a way that doesn't mean change protocol always when we add some
>>>feature/command to backend. The command status is possible use for this.
>>
>>Command status only works if commands are directly executed. If you can
>>execute the command indirectly, e.g. via a PL, then you'll miss the
>>notification. Making RESET a top-level-only command isn't unreasonable,
>>but using command status won't work as a general approach for notifying
>>clients.
>>
>>We have a mechanism for GUC changes that uses a separate message
>>(ParameterStatus). Perhaps that should be generalized to report
>>different sorts of connection-related changes.
>>
>>-O
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 7: don't forget to increase your free space map settings
>>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2005-06-05 04:02:07 | Re: pgsql: Fix NUMERIC modulus to properly truncate |
Previous Message | Christopher Kings-Lynne | 2005-06-05 03:53:41 | Re: Precedence of % |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2005-06-05 04:05:19 | Re: (8.1) to_timestamp correction (epoch to timestamptz) |
Previous Message | Bruce Momjian | 2005-06-05 03:42:51 | Re: [HACKERS] WAL: O_DIRECT and multipage-writer (+ |