po 29. 1. 2024 v 10:26 odesílatel Pavel Stehule
napsal:
>
>
> ne 28. 1. 2024 v 22:52 odesílatel Jelte Fennema-Nio
> napsal:
>
>> On Sun, 28 Jan 2024 at 20:01, Pavel Stehule
>> wrote:
>> > There is another reason - compatibility with other drivers. We
>> maintain just libpq, but there are
ne 28. 1. 2024 v 22:52 odesílatel Jelte Fennema-Nio
napsal:
> On Sun, 28 Jan 2024 at 20:01, Pavel Stehule
> wrote:
> > There is another reason - compatibility with other drivers. We maintain
> just libpq, but there are JDBC, Npgsql, and some native Python drivers. I
> didn't checked, but maybe
On Sun, 28 Jan 2024 at 20:01, Pavel Stehule wrote:
> There is another reason - compatibility with other drivers. We maintain just
> libpq, but there are JDBC, Npgsql, and some native Python drivers. I didn't
> checked, but maybe they expect GUC with GUC_REPORT flag.
This doesn't matter,
ne 28. 1. 2024 v 10:42 odesílatel Jelte Fennema-Nio
napsal:
> On Sat, 27 Jan 2024 at 20:44, Pavel Stehule
> wrote:
> > client_encoding, standard_conforming_strings, server_version,
> default_transaction_read_only, in_hot_standby and scram_iterations
> > are used by libpq directly, so it can be
On Sat, 27 Jan 2024 at 20:44, Pavel Stehule wrote:
> client_encoding, standard_conforming_strings, server_version,
> default_transaction_read_only, in_hot_standby and scram_iterations
> are used by libpq directly, so it can be wrong to introduce the possibility
> to break it.
libpq could add
so 27. 1. 2024 v 10:24 odesílatel Jelte Fennema-Nio
napsal:
> On Sat, 27 Jan 2024 at 08:35, Pavel Stehule
> wrote:
> > Until now, it is not possible to disable reporting. So clients can
> expect so reporting is workable.
>
> Sure, so if we leave the default as is that's fine. It's not as if
>
On Sat, 27 Jan 2024 at 08:35, Pavel Stehule wrote:
> Until now, it is not possible to disable reporting. So clients can expect so
> reporting is workable.
Sure, so if we leave the default as is that's fine. It's not as if
this GUC would be changed without the client knowing, the client would
be
so 27. 1. 2024 v 0:04 odesílatel Jelte Fennema-Nio
napsal:
> On Fri, 26 Jan 2024 at 21:35, Pavel Stehule
> wrote:
> > I see a possibility of disabling reporting as possibly dangerous.
> Without reporting encoding you can break psql. So it should be limited just
> to few values where is known
On Fri, 26 Jan 2024 at 21:35, Pavel Stehule wrote:
> I see a possibility of disabling reporting as possibly dangerous. Without
> reporting encoding you can break psql. So it should be limited just to few
> values where is known behave.
I agree that client_encoding is a GUC that likely all
pá 26. 1. 2024 v 11:40 odesílatel Jelte Fennema-Nio
napsal:
> On Thu, 25 Jan 2024 at 21:43, Pavel Stehule
> wrote:
> > 2. using GUC for all reported GUC looks not too readable. Maybe it
> should be used just for customized reporting, not for default
>
> I thought about this too, because indeed
On Thu, 25 Jan 2024 at 21:43, Pavel Stehule wrote:
> 2. using GUC for all reported GUC looks not too readable. Maybe it should be
> used just for customized reporting, not for default
I thought about this too, because indeed the default list is quite
long. But I decided against it because it
po 8. 1. 2024 v 6:08 odesílatel vignesh C napsal:
> On Tue, 12 Sept 2023 at 14:39, Peter Eisentraut
> wrote:
> >
> > On 11.09.23 13:59, Jelte Fennema wrote:
> > > @Tom and @Robert, since you originally suggested extending the
> > > protocol for this, I think some input from you on the protocol
út 12. 9. 2023 v 9:46 odesílatel Peter Eisentraut
napsal:
> On 11.09.23 13:59, Jelte Fennema wrote:
> > @Tom and @Robert, since you originally suggested extending the
> > protocol for this, I think some input from you on the protocol design
> > would be quite helpful. BTW, this protocol
Hi
čt 11. 1. 2024 v 12:12 odesílatel Jelte Fennema-Nio
napsal:
> On Tue, 12 Sept 2023 at 09:46, Peter Eisentraut
> wrote:
> > ISTM that for a purpose like pgbouncer, it would be simpler to add a new
> > GUC "report these variables" and send that in the startup message? That
> > might not help
Hi
I starting work on this patch - start with rebase
Regards
Pavel
From c7bbdd67898b397143fa314152f32d5ca935c082 Mon Sep 17 00:00:00 2001
From: "ok...@github.com"
Date: Sun, 21 Jan 2024 14:23:06 +0100
Subject: [PATCH 1/4] Protocol ReportGUC message
This patch implements dynamic reporting
On Tue, 12 Sept 2023 at 09:46, Peter Eisentraut wrote:
> ISTM that for a purpose like pgbouncer, it would be simpler to add a new
> GUC "report these variables" and send that in the startup message? That
> might not help with the psql use case, but it would be much simpler.
FYI I implemented it
On Tue, 12 Sept 2023 at 14:39, Peter Eisentraut wrote:
>
> On 11.09.23 13:59, Jelte Fennema wrote:
> > @Tom and @Robert, since you originally suggested extending the
> > protocol for this, I think some input from you on the protocol design
> > would be quite helpful. BTW, this protocol extension
On 11.09.23 13:59, Jelte Fennema wrote:
@Tom and @Robert, since you originally suggested extending the
protocol for this, I think some input from you on the protocol design
would be quite helpful. BTW, this protocol extension is the main
reason I personally care for this patch, because it would
po 11. 9. 2023 v 13:24 odesílatel Jelte Fennema napsal:
> On Fri, 8 Sept 2023 at 21:08, Pavel Stehule
> wrote:
> > ok changed - there is minor problem - almost all PQ functions are of int
> type, but ProtocolVersion is uint
>
> Your current implementation requires using the PG_PROTOCOL macros
On Mon, 11 Sept 2023 at 13:59, Jelte Fennema wrote:
> I think that would make the client code even simpler than it is now.
To be clear, I'm not saying we should do this. There's benefits to
using a dedicated new message type too (e.g. clearer errors if a proxy
like pgbouncer does not understand
@Tom and @Robert, since you originally suggested extending the
protocol for this, I think some input from you on the protocol design
would be quite helpful. BTW, this protocol extension is the main
reason I personally care for this patch, because it would allow
PgBouncer to ask for updates on
On Fri, 8 Sept 2023 at 21:08, Pavel Stehule wrote:
> ok changed - there is minor problem - almost all PQ functions are of int
> type, but ProtocolVersion is uint
Your current implementation requires using the PG_PROTOCOL macros to
compare versions. But clients cannot currently use those macros
pá 8. 9. 2023 v 21:07 odesílatel Pavel Stehule
napsal:
> Hi
>
> Another thing that should be described there is that this falls
>> outside of the transaction flow, i.e. it's changes are not reverted on
>> ROLLBACK. But that leaves an important consideration: What happens
>> when an error occurs
Hi
Another thing that should be described there is that this falls
> outside of the transaction flow, i.e. it's changes are not reverted on
> ROLLBACK. But that leaves an important consideration: What happens
> when an error occurs on the server during handling of this message
> (e.g. the GUC
út 5. 9. 2023 v 13:29 odesílatel Jelte Fennema napsal:
> On Tue, 5 Sept 2023 at 05:50, Pavel Stehule
> wrote:
>
> > I prefer to introduce a new function - it is ten lines of code. The form
> is not important - it can be a full number or minor number. It doesn't
> matter I think. But my opinion
On Tue, 5 Sept 2023 at 05:50, Pavel Stehule wrote:
> I prefer to introduce a new function - it is ten lines of code. The form is
> not important - it can be a full number or minor number. It doesn't matter I
> think. But my opinion in this area is not strong, and I like to see feedback
> from
po 4. 9. 2023 v 14:24 odesílatel Jelte Fennema napsal:
> On Sun, 3 Sept 2023 at 20:58, Pavel Stehule
> wrote:
> > here is an try
>
> Overall it does what I had in mind. Below a few suggestions:
>
> +int
> +PQprotocolSubversion(const PGconn *conn)
>
> Ugh, it's quite annoying that the original
po 4. 9. 2023 v 14:24 odesílatel Jelte Fennema napsal:
> On Sun, 3 Sept 2023 at 20:58, Pavel Stehule
> wrote:
> > here is an try
>
> Overall it does what I had in mind. Below a few suggestions:
>
> +int
> +PQprotocolSubversion(const PGconn *conn)
>
> Ugh, it's quite annoying that the original
On Sun, 3 Sept 2023 at 20:58, Pavel Stehule wrote:
> here is an try
Overall it does what I had in mind. Below a few suggestions:
+int
+PQprotocolSubversion(const PGconn *conn)
Ugh, it's quite annoying that the original PQprotocolVersion only
returns the major version and thus we need this new
Hi
ne 3. 9. 2023 v 9:59 odesílatel Jelte Fennema napsal:
> On Sun, 3 Sept 2023 at 08:24, Pavel Stehule
> wrote:
> > My personal feeling from this area is that the protocol design is done,
> but it is not implemented on libpq level. My feelings can be wrong. The
> protocol number is hardcoded
On Sun, 3 Sept 2023 at 08:24, Pavel Stehule wrote:
> My personal feeling from this area is that the protocol design is done, but
> it is not implemented on libpq level. My feelings can be wrong. The protocol
> number is hardcoded in libpq, so I cannot change it from the client side.
No, I
út 29. 8. 2023 v 14:11 odesílatel Jelte Fennema napsal:
> On Mon, 28 Aug 2023 at 15:00, Pavel Stehule
> wrote:
> + minServerMajor = 1600;
> + serverMajor = PQserverVersion(pset.db) / 100;
>
> Instead of using the server version, we should instead use
On Mon, 28 Aug 2023 at 15:00, Pavel Stehule wrote:
+ minServerMajor = 1600;
+ serverMajor = PQserverVersion(pset.db) / 100;
Instead of using the server version, we should instead use the
protocol version negotiation that's provided by the
po 28. 8. 2023 v 13:58 odesílatel Pavel Stehule
napsal:
> Hi
>
>
>>>
>>>
>>> But afaict there's no problem with using pqParseInput3() and
>>> PQexecFinish() even if the message isn't handled as part of the
>>> transaction. Some other messages that pqParseInput3 handles which are
>>> not part of
Hi
>>
>>
>> But afaict there's no problem with using pqParseInput3() and
>> PQexecFinish() even if the message isn't handled as part of the
>> transaction. Some other messages that pqParseInput3 handles which are
>> not part of the transaction are 'N' (Notice) and 'K' (secret key).
>>
>
> I have
čt 10. 8. 2023 v 16:31 odesílatel Jelte Fennema napsal:
> On Thu, 10 Aug 2023 at 14:44, Pavel Stehule
> wrote:
> > čt 10. 8. 2023 v 14:05 odesílatel Jelte Fennema
> napsal:
> >> That it is not rolled-back
> >> in a case like this?
> >>
> >> BEGIN;
> >> \set PROMPT '%N'
> >> ROLLBACK;
> >
> >
>
On Thu, 10 Aug 2023 at 14:44, Pavel Stehule wrote:
> čt 10. 8. 2023 v 14:05 odesílatel Jelte Fennema napsal:
>> That it is not rolled-back
>> in a case like this?
>>
>> BEGIN;
>> \set PROMPT '%N'
>> ROLLBACK;
>
>
> surely not.
>
> \set is client side setting, and it is not transactional.
čt 10. 8. 2023 v 14:05 odesílatel Jelte Fennema napsal:
> On Tue, 8 Aug 2023 at 07:20, Pavel Stehule
> wrote:
> > The reason why I implemented separate flow is usage from psql and
> independence of transaction state. It is used for the \set command, that
> is non-transactional, not SQL. If I
On Tue, 8 Aug 2023 at 07:20, Pavel Stehule wrote:
> The reason why I implemented separate flow is usage from psql and
> independence of transaction state. It is used for the \set command, that is
> non-transactional, not SQL. If I inject this message to some other flow, I
> lose this
po 31. 7. 2023 v 17:46 odesílatel Jelte Fennema napsal:
> On Mon, 24 Jul 2023 at 21:16, Pavel Stehule
> wrote:
> > I don't understand how it can be possible to do it without. I need to
> process possible errors, and then I need to read and synchronize protocol.
> I didn't inject
> > this
On Mon, 24 Jul 2023 at 21:16, Pavel Stehule wrote:
> I don't understand how it can be possible to do it without. I need to
> process possible errors, and then I need to read and synchronize protocol. I
> didn't inject
> this feature to some oher flow, so I need to implement a complete process.
Hi
po 8. 5. 2023 v 14:22 odesílatel Jelte Fennema napsal:
> I'm very much in favor of adding a way to support reporting other GUC
> variables than the current hardcoded list. This can be quite useful to
> support some amount of session state in connection poolers.
>
> Some general feedback on
Hi
pá 28. 4. 2023 v 7:00 odesílatel Pavel Stehule
napsal:
>
>
> čt 27. 4. 2023 v 7:39 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> rebased version + fix warning possibly uninitialized variable
>>
>
> fix not unique function id
>
> Regards
>
> Pavel
>
only rebase
>
>
>> Regards
>>
>>
Hi
po 8. 5. 2023 v 14:22 odesílatel Jelte Fennema napsal:
> I'm very much in favor of adding a way to support reporting other GUC
> variables than the current hardcoded list. This can be quite useful to
> support some amount of session state in connection poolers.
>
> Some general feedback on
I'm very much in favor of adding a way to support reporting other GUC
variables than the current hardcoded list. This can be quite useful to
support some amount of session state in connection poolers.
Some general feedback on the patch:
1. I don't think the synchronization mechanism that you
čt 27. 4. 2023 v 7:39 odesílatel Pavel Stehule
napsal:
> Hi
>
> rebased version + fix warning possibly uninitialized variable
>
fix not unique function id
Regards
Pavel
> Regards
>
> Pavel
>
>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index b11d9a6ba3..f774ffa310
Hi
rebased version + fix warning possibly uninitialized variable
Regards
Pavel
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index b11d9a6ba3..f774ffa310 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -5401,6 +5401,43 @@ psql "dbname=postgres
st 5. 4. 2023 v 18:40 odesílatel Pavel Stehule
napsal:
>
>
> st 5. 4. 2023 v 17:47 odesílatel Robert Haas
> napsal:
>
>> On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule
>> wrote:
>> > If the GUC_REPORT should not be used, then only one possibility is
>> enhancing the protocol, about the
st 5. 4. 2023 v 17:47 odesílatel Robert Haas napsal:
> On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule
> wrote:
> > If the GUC_REPORT should not be used, then only one possibility is
> enhancing the protocol, about the possibility to read some predefined
> server's features from the client.
> >
On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule wrote:
> If the GUC_REPORT should not be used, then only one possibility is enhancing
> the protocol, about the possibility to read some predefined server's features
> from the client.
> It can be much cheaper than SQL query, and it can be used
st 5. 4. 2023 v 16:02 odesílatel Robert Haas napsal:
> On Wed, Apr 5, 2023 at 9:56 AM Tom Lane wrote:
> > Robert Haas writes:
> > > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
> > >> Basically, I want to reject this on the grounds that it's not
> > >> useful enough to justify the overhead
st 5. 4. 2023 v 15:56 odesílatel Tom Lane napsal:
> Robert Haas writes:
> > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
> >> Basically, I want to reject this on the grounds that it's not
> >> useful enough to justify the overhead of marking the "role" GUC
> >> as GUC_REPORT.
>
> > I agree
On Wed, Apr 5, 2023 at 9:56 AM Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
> >> Basically, I want to reject this on the grounds that it's not
> >> useful enough to justify the overhead of marking the "role" GUC
> >> as GUC_REPORT.
>
> > I agree with
Robert Haas writes:
> On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
>> Basically, I want to reject this on the grounds that it's not
>> useful enough to justify the overhead of marking the "role" GUC
>> as GUC_REPORT.
> I agree with that. I think we need some method for optionally
> reporting
On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
> Basically, I want to reject this on the grounds that it's not
> useful enough to justify the overhead of marking the "role" GUC
> as GUC_REPORT.
I agree with that. I think we need some method for optionally
reporting values, so that stuff like
út 4. 4. 2023 v 21:11 odesílatel Pavel Stehule
napsal:
>
>
> út 4. 4. 2023 v 20:50 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> út 4. 4. 2023 v 19:55 odesílatel Tom Lane napsal:
>>
>>> Pavel Stehule writes:
>>> > út 4. 4. 2023 v 18:42 odesílatel Tom Lane napsal:
>>> >> Basically, I want to
út 4. 4. 2023 v 20:50 odesílatel Pavel Stehule
napsal:
>
>
> út 4. 4. 2023 v 19:55 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > út 4. 4. 2023 v 18:42 odesílatel Tom Lane napsal:
>> >> Basically, I want to reject this on the grounds that it's not
>> >> useful enough to justify
út 4. 4. 2023 v 19:55 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > út 4. 4. 2023 v 18:42 odesílatel Tom Lane napsal:
> >> Basically, I want to reject this on the grounds that it's not
> >> useful enough to justify the overhead of marking the "role" GUC
> >> as GUC_REPORT. The
Pavel Stehule writes:
> út 4. 4. 2023 v 18:42 odesílatel Tom Lane napsal:
>> Basically, I want to reject this on the grounds that it's not
>> useful enough to justify the overhead of marking the "role" GUC
>> as GUC_REPORT. The problems with it not going to work properly
>> with old servers are
út 4. 4. 2023 v 18:42 odesílatel Tom Lane napsal:
> Kirk Wolak writes:
> > Changed status to Ready for Committer. (100% Guessing here...)
>
> Basically, I want to reject this on the grounds that it's not
> useful enough to justify the overhead of marking the "role" GUC
> as GUC_REPORT. The
Kirk Wolak writes:
> Changed status to Ready for Committer. (100% Guessing here...)
Basically, I want to reject this on the grounds that it's not
useful enough to justify the overhead of marking the "role" GUC
as GUC_REPORT. The problems with it not going to work properly
with old servers are
On Sat, Feb 4, 2023 at 3:33 PM Pavel Stehule
wrote:
> Hi
>
> pá 3. 2. 2023 v 21:43 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> pá 3. 2. 2023 v 21:21 odesílatel Tom Lane napsal:
>>
>>> Pavel Stehule writes:
>>> > Both patches are very simple - and they use almost already prepared
>>> >
Hi
pá 3. 2. 2023 v 21:43 odesílatel Pavel Stehule
napsal:
>
>
> pá 3. 2. 2023 v 21:21 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > Both patches are very simple - and they use almost already prepared
>> > infrastructure.
>>
>> It's not simple at all to make the psql feature
pá 3. 2. 2023 v 21:21 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Both patches are very simple - and they use almost already prepared
> > infrastructure.
>
> It's not simple at all to make the psql feature depend on marking
> "role" as GUC_REPORT when it never has been before. That
Pavel Stehule writes:
> Both patches are very simple - and they use almost already prepared
> infrastructure.
It's not simple at all to make the psql feature depend on marking
"role" as GUC_REPORT when it never has been before. That will
cause the feature to misbehave when using older servers.
pá 3. 2. 2023 v 20:42 odesílatel Corey Huinker
napsal:
>
>
> On Fri, Feb 3, 2023 at 9:56 AM Pavel Stehule
> wrote:
>
>> Hi
>>
>> one visitor of p2d2 (Prague PostgreSQL Developer Day) asked if it is
>> possible to show the current role in psql's prompt. I think it is not
>> possible, but
On Fri, Feb 3, 2023 at 9:56 AM Pavel Stehule
wrote:
> Hi
>
> one visitor of p2d2 (Prague PostgreSQL Developer Day) asked if it is
> possible to show the current role in psql's prompt. I think it is not
> possible, but fortunately (with some limits) almost all necessary work is
> done, and the
67 matches
Mail list logo
