.postgresql.org/docs/9.3/static/libpq-misc.html.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ery beginning of the file seem
possible? Maybe even only if it's to the same database?
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 9/14/12 4:26 PM, Tom Lane wrote:
So that explains why including perl.h is relevant. Would you like to
try modifying your copy of pthread.h to confirm it's the same situation
on Ubuntu?
Yup, that fixes it.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql
, I think back-patching that change is less ugly than making the
variable non-static.
It does, indeed. I can't reproduce the bug on my end with that patch
applied.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscri
On 13/09/2012 19:48, Tom Lane wrote:
Marko Tiikkaja writes:
On 9/12/12 1:50 AM, Tom Lane wrote:
Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly?
We've reproduced it on both 5.14.2 and 5.16.1.
What happens is that free_plperl_function() for some reason g
On 9/12/12 1:50 AM, Tom Lane wrote:
Marko Tiikkaja writes:
Joel Jacobson managed to narrow it down to this test case, which crashes
consistently on Ubuntu 12.04 both with and without your patch. I,
however, wasn't able to reproduce the problem on my OS X Mountain Lion.
Doesn't rep
tomorrow, but in the
mean time if you can reproduce the problem or think of something, I'll
post the test case.
Regards,
Marko Tiikkaja
DROP DATABASE plperlbug;
CREATE DATABASE plperlbug;
\c plperlbug
CREATE LANGUAGE plperlu;
CREATE TABLE t1 (
fooid serial not null,
foo character
em to have debug symbols for that
core dump --- can you tell which of the dereferences in line 3373
caused the crash?
The current_call_data->prodesc->fn_readonly one.
Please let me know if I can be of more assistance.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list
The following bug has been logged on the website:
Bug reference: 6511
Logged by: Mark Murawski
Email address: ma...@kobaz.net
PostgreSQL version: 9.1.3
Operating system: Linux - Debian Squeeze postgres 9.1 from backports
Description:
create table mytable ( id integer
On Fri, Jan 27, 2012 at 8:10 PM, Stefan Kaltenbrunner
wrote:
> On 01/27/2012 07:06 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander wrote:
>>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
>>>> On Fri, Jan 27, 2012 at 7:34 PM, St
On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander wrote:
> On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>> wrote:
>>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>>>> On Fri, Jan 27, 2012 at 01:37:1
On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
wrote:
> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Yeah, it should be fixed. But note that "random data" is part of
>> decrypt() spec - the
On Fri, Jan 27, 2012 at 12:13:21PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > pgcrypto.c is easily fixable and internal.c has proper checks.
> > But openssl.c does not. And I have a bigger openssl.c cleanup
> > pending. So I would prefer to add missing checks to cle
ck size
>
> but the module's regression tests all still pass, indicating that this
> sort of case isn't tested.
>
> pg_encrypt_iv() has the identical usage error with respect to
> px_combo_encrypt.
>
> Marko, does this look right to you?
Yeah, it should be fixed.
The following bug has been logged online:
Bug reference: 5989
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@2ndquadrant.com
PostgreSQL version: git master
Operating system: Linux
Description:Assertion failure on UPDATE of big value
Details:
Test case
The following bug has been logged online:
Bug reference: 5988
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@2ndquadrant.com
PostgreSQL version: git master
Operating system: Linux
Description:CTINE duplicates constraints
Details:
CREATE TABLE IF NOT EXISTS
d get
different behaviour for the same command.
We're not going to change the behavior like that in stable branches...
How about documenting it?
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
The following bug has been logged online:
Bug reference: 5018
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@cs.helsinki.fi
PostgreSQL version: 8.4.0
Operating system: Linux
Description:Window function alias
Details:
I came across this:
=> SELECT lead(
On 7/15/09, David Wilson wrote:
> On Wed, Jul 15, 2009 at 11:10 AM, Marko Kreen wrote:
> > From security standpoint, wasting more cycles on bad passwords is good,
> > as it decreases the rate bruteforce password scanning can happen.
> >
> > And I cannot imagine a sc
good,
as it decreases the rate bruteforce password scanning can happen.
And I cannot imagine a scenario where performance on invalid logins
can be relevant..
--
marko
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4902
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@cs.helsinki.fi
PostgreSQL version: 8.4.0
Operating system: Linux
Description:Subquery in VALUES referencing a CTE
Details:
While playing around
PGP_S2K_ISALTED = 3
> };
>
> because what the first one is doing is defining a global variable
> that is of an anonymous enum type.
Eh, it's silly mistake indeed.
> Marko, am I right that this is just a syntax mistake, and not
> intentional creation of a variable?
other pgcrypto routines might have similar bugs?
Well, PGP code accesses anything thru wrappers, so should be OK.
Rest of the code does not try to parse user data, just passes
it thru.
Except armor()/dearmor(), which does lot of pointer-juggling.
I can do a review of that, j
gt; EVP_DigestFinal(ctx, dst, NULL);
>
> /*
> * Some builds of 0.9.7x clear all of ctx in EVP_DigestFinal. Fix it by
> * reinitializing ctx.
> */
> EVP_DigestInit(ctx, md);
> }
>
> It looks like this results in a leak of the entire OpenSSL conte
er file into every C file and I
modified
Makefile to link libpq with libdmallocth.so. Even though libdmalloc crashes
often (at least dlclose() incompatibility), it seems to be a good tool
for searching memory
leaks even inside an ODBC driver: it tells the C file and the line of
the code, where the
mem
Tom Lane wrote:
> Marko Mikulicic <[EMAIL PROTECTED]> writes:
>
>> The code in cash.c should be cleaned up completely
>
>
> Such criticism is best expressed in the form of a patch ;-)
No problem, I will send you a patch. However I want to do things
right, bec
POSTGRESQL BUG REPORT TEMPLATE
Your name : Marko Mikulicic
Your email address : [EMAIL PROTECTED
27 matches
Mail list logo
