Heikki Linnakangas writes:
> Joseph, any chance we could see a backtrace or some other details from
> those crashes?
+1
> 'drongo' just reported linker errors:
> postgres.def : error LNK2001: unresolved external symbol
> GetOldFunctionMessage
> [c:\\prog\\bf\\root\\HEAD\\pgsql.build\\postgres
On 3/4/21 3:55 PM, Heikki Linnakangas wrote:
>
>
>
>
> 'drongo' just reported linker errors:
>
> postgres.def : error LNK2001: unresolved external symbol
> GetOldFunctionMessage
> [c:\\prog\\bf\\root\\HEAD\\pgsql.build\\postgres.vcxproj]
> postgres.def : error LNK2001: unresolved external symbol
On 04/03/2021 22:04, Tom Lane wrote:
Heikki Linnakangas writes:
I concur that 0001 attached is committable. I have not looked at
your 0002, though.
Removed the entry from nls.mk, and pushed 0001. Thanks!
It seems that buildfarm member walleye doesn't like this.
Since nothing else is compl
Heikki Linnakangas writes:
>> I concur that 0001 attached is committable. I have not looked at
>> your 0002, though.
> Removed the entry from nls.mk, and pushed 0001. Thanks!
It seems that buildfarm member walleye doesn't like this.
Since nothing else is complaining, I confess bafflement
as to
Heikki Linnakangas writes:
> On 04/03/2021 01:32, Tom Lane wrote:
>> I'm not sure where the extra newlines are coming from, and it seems
>> unlikely to be worth worrying over. This behavior is good enough for me.
> fe-connect.c appends a newline for any errors in pre-3.0 format:
>>
On 04/03/2021 01:32, Tom Lane wrote:
Patched psql, trying to connect to a 7.3 server, reports this:
$ psql -h ...
psql: error: connection to server at "sss2" (192.168.1.3), port 5432 failed:
FATAL: unsupported frontend protocol
$
Conversely, 7.3 psql trying to connect to a patched server rep
I wrote:
> I concur that 0001 attached is committable. I have not looked at
> your 0002, though.
Oh ... grepping discovered one more loose end: mention of fe-protocol2.c
has to be removed from src/interfaces/libpq/nls.mk.
regards, tom lane
On Thu, Feb 4, 2021 at 11:47 AM Heikki Linnakangas wrote:
>
> On 04/02/2021 17:35, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Yeah, the changes I was thinking about are all in libpq-int.h so that's
> >> not really a problem. But one enum in libpq-fe.h renumbers values, and
> >> I think it's
On 04/02/2021 17:35, Tom Lane wrote:
Alvaro Herrera writes:
Yeah, the changes I was thinking about are all in libpq-int.h so that's
not really a problem. But one enum in libpq-fe.h renumbers values, and
I think it's better to keep the old value labelled as "unused" to avoid
any changes.
Oh,
Alvaro Herrera writes:
> Yeah, the changes I was thinking about are all in libpq-int.h so that's
> not really a problem. But one enum in libpq-fe.h renumbers values, and
> I think it's better to keep the old value labelled as "unused" to avoid
> any changes.
Oh, yeah, can't do that. libpq-fe.h
On 2021-Feb-04, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Feb-04, Heikki Linnakangas wrote:
> >> Ok, here we go.
>
> > Are you going to bump the .so version for this? I think that should be
> > done, since some functions disappear and there are struct changes. It
> > is curious, tho
Alvaro Herrera writes:
> On 2021-Feb-04, Heikki Linnakangas wrote:
>> Ok, here we go.
> Are you going to bump the .so version for this? I think that should be
> done, since some functions disappear and there are struct changes. It
> is curious, though, to see that exports.txt needs no changes.
On 2021-Feb-04, Heikki Linnakangas wrote:
> On 04/02/2021 08:54, Michael Paquier wrote:
> > On Wed, Feb 03, 2021 at 11:29:37AM -0500, Tom Lane wrote:
> > > Then let's kill it dead, server and libpq both.
> >
> > Yeah.
>
> Ok, here we go.
Are you going to bump the .so version for this? I think
On Wed, Feb 03, 2021 at 11:29:37AM -0500, Tom Lane wrote:
> Then let's kill it dead, server and libpq both.
Yeah.
--
Michael
signature.asc
Description: PGP signature
Heikki Linnakangas writes:
> Since we're on a removal-spree, it'd also be nice to get rid of the
> "fast-path" function call interface, PQfn(). However, libpq is using it
> internally in the lo_*() functions, so if we remove it from the server,
> lo_*() will stop working with old libpq versions
On 03/02/2021 18:29, Tom Lane wrote:
Alvaro Herrera writes:
On 2021-Feb-03, Tom Lane wrote:
I have a vague recollection that JDBC users still like to use
protocol 2 for some reason --- is that out of date?
[ yes, since 2016 ]
Then let's kill it dead, server and libpq both.
Ok, works for
Alvaro Herrera writes:
> On 2021-Feb-03, Tom Lane wrote:
>> I have a vague recollection that JDBC users still like to use
>> protocol 2 for some reason --- is that out of date?
> [ yes, since 2016 ]
Then let's kill it dead, server and libpq both.
regards, tom lane
On 2021-Feb-03, Tom Lane wrote:
> I have a vague recollection that JDBC users still like to use
> protocol 2 for some reason --- is that out of date?
2016:
commit c3d8571e53cc5b702dae2f832b02c872ad44c3b7
Author: Vladimir Sitnikov
AuthorDate: Sat Aug 6 12:22:17 2016 +0300
CommitDate: Sat Aug
Heikki Linnakangas writes:
> I propose that we remove server support for COPY FROM STDIN with
> protocol version 2, per attached patch. Even if we could still support
> it, it would be a very rarely used and tested codepath, prone to bugs.
> Perhaps we could remove support for the old protocol
Hi,
The server still supports the old protocol version 2. Protocol version 3
was introduced in PostgreSQL 7.4, so there shouldn't be many clients
around anymore that don't support it.
COPY FROM STDIN is particularly problematic with the old protocol,
because the end-of-copy can only be detec
20 matches
Mail list logo
