Skip site navigation (1) Skip section navigation (2)

Re: MemoryContextAlloc: invalid request size 1934906735

From: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MemoryContextAlloc: invalid request size 1934906735
Date: 2002-08-27 11:31:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On August 27, 2002 02:01 am, Tom Lane wrote:
> "D'Arcy J.M. Cain" <darcy(at)druid(dot)net> writes:
> > I have been getting the subject message ever since upgrading to 7.2.1.  I
> > tried 7.2.2 with the same thing.  It seems to be related to my chkpass
> > type (see contrib) as it only happens on tables with that type.
> FWIW, I couldn't see any problem in CVS tip.  Could you provide an exact
> sequence-to-reproduce?

Surely.  Create a database (chkpass_test) and, after loading the chkpass 
type, follow this bouncing ball.

1. CREATE TABLE x (c chkpass);
2. INSERT INTO x VALUES ('a'); [Repeat 20 times]
4. UPDATE x SET c = ':a';
6. UPDATE x SET c = 'a';
8. GOTO 4

Note that 3 and 7 should fail most (95%?) of the time.  When it does, convert 
the invalid size to hex and compare the bytes of the integer with the 
encrypted value in the table.

Note that the fact that 5 does not fail has nothing to do with the path 
through chkpass.c.  If you take a failing password and insert it raw with 
"UPDATE x SET c = ':2w3dhratDt7xo';" then you get the same failure (even the 
same number - 1952543340 in my case) as you did when chkpass encrypted with 
that salt.

D'Arcy J.M. Cain <darcy(at){druid|vex}.net>   |  Democracy is three wolves                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-08-27 13:06:52
Subject: Re: Think I see a btree vacuuming bug
Previous:From: Zeugswetter Andreas SB SDDate: 2002-08-27 07:34:11
Subject: Re: Default privileges for new databases (was Re: Can't

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group