On Mon, Oct 16, 2017 at 10:08 PM, Andres Freund wrote:
> On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote:
>> On 9/20/17 04:32, Andres Freund wrote:
>> > Here's what I roughly was thinking of. I don't quite like the name, and
>> > the way the version is specified for libpq (basically just the
On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote:
> On 9/20/17 04:32, Andres Freund wrote:
> > Here's what I roughly was thinking of. I don't quite like the name, and
> > the way the version is specified for libpq (basically just the "raw"
> > integer).
>
> "forced_protocol_version" reads wro
On 9/20/17 04:32, Andres Freund wrote:
> Here's what I roughly was thinking of. I don't quite like the name, and
> the way the version is specified for libpq (basically just the "raw"
> integer).
"forced_protocol_version" reads wrong to me. I think
"force_protocol_version" might be better. Othe
On Wed, Oct 11, 2017 at 10:28 PM, Robert Haas wrote:
> On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund wrote:
>> I'm actually inclined not to, and keep this as a undocumented debugging
>> option. Limiting the use of this option to people willing to read the
>> code seems like a good idea to me.
>
On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund wrote:
> I'm actually inclined not to, and keep this as a undocumented debugging
> option. Limiting the use of this option to people willing to read the
> code seems like a good idea to me.
-1. I use the documentation to find things, even though I a
On Wed, Oct 11, 2017 at 10:46 AM, Andres Freund wrote:
> I'm not following. The "D" is in the 'dispchar' field, not the value
> field, no? The default value is NULL?
Oops, yes. I misread the code. Other debug options are not documented,
so fine for me to not provide any documentation then.
--
Mi
Hi,
On 2017-10-11 10:40:11 +0900, Michael Paquier wrote:
> >> + if (conn->forced_protocol_version != NULL)
> >> + {
> >> + conn->pversion = atoi(conn->forced_protocol_version);
> >> + }
> >> This should check for strlen > 0 as well.
> >
> > Why? Note that we don't do elsehwere in fe-co
On Wed, Oct 11, 2017 at 10:14 AM, Andres Freund wrote:
> Hi,
>
> On 2017-10-11 10:09:34 +0900, Michael Paquier wrote:
>> On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund wrote:
>> > On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> >> Coverage of the relevant files is a good bit higher afterwar
Hi,
On 2017-10-11 10:09:34 +0900, Michael Paquier wrote:
> On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund wrote:
> > On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
> >> Coverage of the relevant files is a good bit higher afterwards. Although
> >> our libpq coverage is generally pretty damn aw
On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund wrote:
> On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> Coverage of the relevant files is a good bit higher afterwards. Although
>> our libpq coverage is generally pretty damn awful.
>
> Any opinions on this? Obviously this needs some cleanup,
On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
> On 2017-09-18 02:53:03 -0700, Andres Freund wrote:
> > On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> > > The real problem in this area, to my mind, is that we're not testing that
> > > code --- either end of it --- in any systematic way. If it
On 2017-09-18 02:53:03 -0700, Andres Freund wrote:
> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> > The real problem in this area, to my mind, is that we're not testing that
> > code --- either end of it --- in any systematic way. If it's broken it
> > could take us quite a while to notice.
>
>
On 09/18/2017 04:54 AM, Robert Haas wrote:
On Mon, Sep 18, 2017 at 7:17 AM, Andres Freund wrote:
Private:
Not so much.
Well, as much as the Internet is actually private:
https://ilccyberreport.files.wordpress.com/2013/06/nsa11.jpg
JD
;)
--
Command Prompt, Inc. || http://the.postgres.c
On Mon, Sep 18, 2017 at 7:17 AM, Andres Freund wrote:
> Private:
Not so much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On Mon, Sep 18, 2017 at 8:17 PM, Andres Freund wrote:
> And now you missed the "same infrastructure" part.
I am sort of aware of that per the list of parameters at the top
fe-connect.c, thanks for the reminer :)
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On September 18, 2017 4:15:31 AM PDT, Michael Paquier
wrote:
>On Mon, Sep 18, 2017 at 8:09 PM, Andres Freund
>wrote:
>>
>>
>> On September 18, 2017 4:08:21 AM PDT, Michael Paquier
> wrote:
>>>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund
>>>wrote:
>It seems to me that you are looking mor
On Mon, Sep 18, 2017 at 8:09 PM, Andres Freund wrote:
>
>
> On September 18, 2017 4:08:21 AM PDT, Michael Paquier
> wrote:
>>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund
>>wrote:
It seems to me that you are looking more for a connection parameter
here.
>>>
>>> I'm not seeing a meaning
On September 18, 2017 4:08:21 AM PDT, Michael Paquier
wrote:
>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund
>wrote:
>>>It seems to me that you are looking more for a connection parameter
>>>here.
>>
>> I'm not seeing a meaningful distinction here? Env vars and connection
>parameters are handl
On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund wrote:
>>It seems to me that you are looking more for a connection parameter
>>here.
>
> I'm not seeing a meaningful distinction here? Env vars and connection
> parameters are handled using the same framework in libpq. And using the env
> var in th
On September 18, 2017 3:50:17 AM PDT, Michael Paquier
wrote:
>On Mon, Sep 18, 2017 at 6:53 PM, Andres Freund
>wrote:
>> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
>>> The real problem in this area, to my mind, is that we're not testing
>that
>>> code --- either end of it --- in any systemat
On Mon, Sep 18, 2017 at 6:53 PM, Andres Freund wrote:
> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
>> The real problem in this area, to my mind, is that we're not testing that
>> code --- either end of it --- in any systematic way. If it's broken it
>> could take us quite a while to notice.
>
On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> The real problem in this area, to my mind, is that we're not testing that
> code --- either end of it --- in any systematic way. If it's broken it
> could take us quite a while to notice.
Independent of the thrust of my question - why aren't we addi
On Wed, Sep 13, 2017 at 11:39 PM, Tom Lane wrote:
>>> One small problem with cutting libpq's V2 support is that the server's
>>> report_fork_failure_to_client() function still sends a V2-style message.
>
>> We should really fix that so it reports the error as a v3 message,
>> independent of rippin
Hi,
On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Re-upping this topic.
>
> > On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
> >> In the same line, maybe we should kill libpq's support for V2 protocol
> >> (which would make the cutoff 7.4). And maybe the server's supp
Andres Freund writes:
> Re-upping this topic.
> On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
>> In the same line, maybe we should kill libpq's support for V2 protocol
>> (which would make the cutoff 7.4). And maybe the server's support too,
>> though that wouldn't save very much code. The argu
Hi,
Re-upping this topic.
On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
> In the same line, maybe we should kill libpq's support for V2 protocol
> (which would make the cutoff 7.4). And maybe the server's support too,
> though that wouldn't save very much code. The argument for cutting this
> i
On Tue, Oct 11, 2016 at 11:34 AM, Heikki Linnakangas wrote:
> On 10/11/2016 08:23 PM, Tom Lane wrote:
>> Not sure where to go from here, but the idea of dropping V2 support
>> is seeming attractive again. Or we could just continue the policy
>> of benign neglect.
>
> Let's drop it.
I agree. The
I wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f26f9). My initial thought is to cut supp
On 10/11/2016 08:23 PM, Tom Lane wrote:
Not sure where to go from here, but the idea of dropping V2 support
is seeming attractive again. Or we could just continue the policy
of benign neglect.
Let's drop it.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Robert Haas writes:
> On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane wrote:
>> The problem with letting it just sit there is that we're not, in fact,
>> testing it. If we take the above argument seriously then we should
>> provide some way to configure libpq to prefer V2 and run regression
>> tests i
On 10 October 2016 at 10:45, Jim Nasby wrote:
> On 10/7/16 1:08 PM, Steve Crawford wrote:
>>
>> This is effectively a 5-year upgrade "grace period" *after* the EOL date
>> of a given version which seems plenty generous.
>
>
> IMHO we need to be careful here. It's not at all unusual to see servers
On 10/7/16 1:08 PM, Steve Crawford wrote:
This is effectively a 5-year upgrade "grace period" *after* the EOL date
of a given version which seems plenty generous.
IMHO we need to be careful here. It's not at all unusual to see servers
running versions that are *far* older than that. It's certa
This thread gets me thinking about the definition of "support." While
support in practice seems to primarily relate to fixes/updates to the
supported version itself it could just as well apply to interoperability
support by newer versions.
Given that the standard PostgreSQL upgrade process involve
Robert Haas writes:
> On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane wrote:
>> Greg Stark writes:
>>> For another there may be binary-only applications or drivers out there
>>> that are using V2 for whatever reason.
>> The problem with letting it just sit there is that we're not, in fact,
>> testing
On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane wrote:
>>> In the same line, maybe we should kill libpq's support for V2 protocol
>>> (which would make the cutoff 7.4). And maybe the server's support too,
>>> though that wouldn't
Greg Stark writes:
> On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane wrote:
>> In the same line, maybe we should kill libpq's support for V2 protocol
>> (which would make the cutoff 7.4). And maybe the server's support too,
>> though that wouldn't save very much code. The argument for cutting this
>>
On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f2
On Fri, Oct 7, 2016 at 10:06 AM, Tom Lane wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f
On Fri, Oct 7, 2016 at 4:06 PM, Tom Lane wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f
pg_dump alleges support for dumping from servers back to 7.0. Would v10
be a good time to remove some of that code? It's getting harder and
harder to even compile those ancient branches, let alone get people to
test against them (cf. 4806f26f9). My initial thought is to cut support
for pre-7.3 o
40 matches
Mail list logo