On Wednesday, December 5, 2018 4:59:18 PM CET Stephen Frost wrote:
> This change doesn't seem to make any sense to me..? If anything, seems
> like we'd end up overallocating memory *after* this change, where we
> don't today (though an analyzer tool might complain because we don't
> free the memor
Among other reports (IMO clearly non-issues), I'm sending patch which
fixes/points to a few resource leaks detected by Coverity that might be
worth fixing. If they are not, feel free to ignore this mail.
Pavel
diff --git a/src/bin/pg_dump/dumputils.c b/src/bin/pg_dump/dumputils.c
index 8a93ace9f
On Thursday, July 12, 2018 5:53:18 PM CET Teodor Sigaev wrote:
> > It would be easier to figure this out if the btree_gist code weren't
> > so desperately undocumented. Teodor, do you remember why it's like
> > this?
>
> Will look.
Ping on this issue. I guess the patch I proposed isn't wrong in
On Wednesday, November 7, 2018 4:55:13 PM CET Tom Lane wrote:
> Pavel Raiskup writes:
> > On Wednesday, November 7, 2018 3:25:31 PM CET Tom Lane wrote:
> >> Yeah, I'm now mighty confused about this as well. PL/Ruby is pretty old
> >> too, so how come nob
On Wednesday, November 7, 2018 3:25:31 PM CET Tom Lane wrote:
> Pavel Raiskup writes:
> > On Tuesday, November 6, 2018 7:28:21 PM CET Tom Lane wrote:
> >> Done. I realized that the immediate problem, rb_iterate(), was only
> >> added as of PG v10, which may explain why
On Tuesday, November 6, 2018 7:28:21 PM CET Tom Lane wrote:
> I wrote:
> > Yeah. The long and short of this is that we're trampling on namespace
> > that reasonably belongs to Ruby --- if they had some functions named
> > "pg_something" and complained about a collision with libpq, would we
> > cha
On Tuesday, November 6, 2018 3:49:46 PM CET Tom Lane wrote:
> Pavel Raiskup writes:
> > On Monday, November 5, 2018 9:06:41 PM CET Robert Haas wrote:
> >> On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote:
> >>>> Is it realistic we could rename red-black tree m
On Monday, November 5, 2018 9:06:41 PM CET Robert Haas wrote:
> On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote:
> > > Is it realistic we could rename red-black tree methods from 'rb_*' to e.g.
> > > 'rbt_*' to avoid this clash?
> >
> > That's not terribly appetizing, because it essentially means we
Hi, I'm curious how it worked before (seems like the function is defined
in both PostgreSQL and Ruby projects for quite some time) - but I recently
came across this situation:
- /bin/postgres is build-time linked with 'ld -E'
- /bin/postgres dlopen()s plruby.so
- plruby.so calls rb_ite
Hi hackers,
I'm trying to look how to trigger code paths under PGP_PUB_DSA_SIGN constant,
and it seems like it is a dead code in the current implementation.
Can anyone confirm this, or help me with creating a correct DSA sign-only key
with RSA encryption subkey that would trigger the code paths?
On Wednesday, July 11, 2018 7:26:40 PM CEST Tom Lane wrote:
> Pavel Raiskup writes:
> > On Monday, July 9, 2018 7:41:59 PM CEST Tom Lane wrote:
> >> Hi Pavel! For patches that purport to resolve bugs, we usually like to
> >> add a regression test case that demonstrate
Hi Tom,
On Monday, July 9, 2018 7:41:59 PM CEST Tom Lane wrote:
> Pavel Raiskup writes:
> > while I tried to debug 'gcc -fstack-protector -O3' problems in [1], I
> > noticed
> > that gbt_var_union() mistreats the first vector element. Patch is attached.
>
>
p 17 00:00:00 2001
From: Pavel Raiskup
Date: Wed, 4 Jul 2018 11:39:38 +0200
Subject: [PATCH] Fix btree_gist "union" for variable length types
The gbt_var_union() did not expect that first key in the entryvec
could represent leaf node, while it many times is. So try call
f_l2n() even for
Hi Christoph,
On Thursday, May 24, 2018 12:08:16 PM CEST Christoph Berg wrote:
> Re: Pavel Raiskup 2018-05-24 <101829257.nn0xsvv...@nb.usersys.redhat.com>
> > > Interesting, thanks. How this is implemented? What you mean by "newer
> > > library" -- new
On Wednesday, May 23, 2018 2:23:24 PM CEST Pavel Raiskup wrote:
> Thanks Stephen,
>
> On Wednesday, May 23, 2018 1:13:08 PM CEST Stephen Frost wrote:
> > Greetings,
> >
> > * Pavel Raiskup (prais...@redhat.com) wrote:
> > > On Thursday, May 10, 2018
Thanks Stephen,
On Wednesday, May 23, 2018 1:13:08 PM CEST Stephen Frost wrote:
> Greetings,
>
> * Pavel Raiskup (prais...@redhat.com) wrote:
> > On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote:
> > > On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrot
On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote:
> On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote:
> > Stephen Frost writes:
> > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > >> On 4/5/18 02:04, Pavel Raiskup wrote:
On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote:
> Stephen Frost writes:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> On 4/5/18 02:04, Pavel Raiskup wrote:
> >>> As a followup thought; there are probably two major obstacles ATM
>
On Friday, April 27, 2018 5:51:57 PM CEST Tom Lane wrote:
> Note that there's a specific timeline there: they expect PEP 394 to get
> changed not more than 2 years from now. I am not sure if Red Hat has
> enough pull in the Python community to guarantee that will happen, but
> do you want to bet a
Thanks Peter,
On Wednesday, April 25, 2018 12:17:05 AM CEST Peter Eisentraut wrote:
> On 4/24/18 07:13, Pavel Raiskup wrote:
> > .. the status quo seems to be bit optimistic with the "distant future",
> > and we should start thinking about dropping plpython2 support, sa
Forwarding to hackers. Hope that's OK after few days.
Pavel
-- Forwarded Message --
Subject: obsoleting plpython2u and defaulting plpythonu to plpython3u
Date: Thursday, April 19, 2018, 11:56:40 AM CEST
From: Pavel Raiskup
To: pgsql-general
Per current plpython
Hello, for the support of multiple versions of PostgreSQL RPM packages on
one system, we are thinking about having only one libpq.so.5
(libecpg.so.6, libpgtype.so.3 respectively) supported and about building
(linking) all the PostgreSQL package versions against that. The pattern
would mean that we
22 matches
Mail list logo