Kevin Field wrote:
Section 9.2 in the docs say, 'The ordinary comparison operators yield null
(signifying "unknown") when either input is null.' This applies to other
operators too. For example, the result of tacking an unknown value onto a
known one is unknown, because you don't know what exac
The following bug has been logged online:
Bug reference: 4510
Logged by: MWendt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.x, 8.2.x
Operating system: windows xp (client), linux (postgres server)
Description:memory leak with libpg.dll
Details:
1) DB ser
On Nov 4, 2008, at 4:43 PM, Andrew Dunstan wrote:
OK, the first thing to note is that there is an easy workaround,
which is to use a sort routine that doesn't need $a/$b. Example:
create or replace function mysort() returns text language plperl
as $f$
my $sfunc = sub ($$) { $_[
Ok, agree. I will prepare it.
Then, I need carefully packaging.
- Original Message -
From: "Dave Page" <[EMAIL PROTECTED]>
2008/11/4 Hiroshi Saito <[EMAIL PROTECTED]>:
Furthermore, I think it good to use libpq by which 8.3.5 was released.
So, it is better to pack up 08.03.0310.?
t
MWendt wrote:
The following bug has been logged online:
Bug reference: 4510
Logged by: MWendt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.x, 8.2.x
Operating system: windows xp (client), linux (postgres server)
Description:memory leak with libpg.dll
Detai
Craig Ringer <[EMAIL PROTECTED]> writes:
> MWendt wrote:
>> 2) the client will connect to these DB server and is running correctly in a
>> timeout. the problem is: for each connection attempt that will fail the
>> memory usage is growing. that will result in massive memory allocation, if
>> the cli
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Kevin Field wrote:
>> select array_cat(null::integer[], '{3}'::integer[]);
>> ...doesn't return NULL, which it should, for consistency.
> Doesn't make sense to me either. I found that this was changed between
> 8.1 (where it returns null) and 8.2, b
The following bug has been logged online:
Bug reference: 4512
Logged by: Keven Guindon
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.5
Operating system: Windows XP sp3
Description:PostgreSQL crash on update command
Details:
SQl Update command:
UPDATE prod
"Keven Guindon" <[EMAIL PROTECTED]> writes:
> Description:PostgreSQL crash on update command
Please provide sufficient information to let us reproduce the crash
(the query alone is not sufficient). See
http://www.postgresql.org/docs/8.3/static/bug-reporting.html
if you need advice about h
> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes:
nathan> Completely untested speculation based on my knowledge of perl
nathan> and a bit of reading:
nathan> The reason you can't see $a and $b is that sort internally
nathan> sets these variables in the main package. That is, sort i
Andrew Gierth <[EMAIL PROTECTED]> writes:
> Nice theory, but completely wrong: sort creates $a and $b in the
> current package, not in main::.
Hmm ... so then why are we seeing a failure?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
T
On Wed, Nov 5, 2008 at 10:54, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes:
>
> nathan> Completely untested speculation based on my knowledge of perl
> nathan> and a bit of reading:
>
> nathan> The reason you can't see $a and $b is that sor
On Wed, Nov 5, 2008 at 11:14, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Gierth <[EMAIL PROTECTED]> writes:
>> Nice theory, but completely wrong: sort creates $a and $b in the
>> current package, not in main::.
>
> Hmm ... so then why are we seeing a failure?
Because Safe runs in a different nam
> I'm loath to change just this one thing though. If we're going to
> monkey with it, I think we should start by having a thought-through
> proposal about the behavior of all the array functions for corner
> cases like null arrays and empty arrays (cf recent discussion about
> zero-dimensional arr
The following bug has been logged online:
Bug reference: 4513
Logged by: Alexey Bashtanov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Red Hat Linux 2.6.20-1.2320.fc5smp i686
Description:VACUUM FULL fails with "out of memory" error
Det
"Alexey Bashtanov" <[EMAIL PROTECTED]> writes:
> The following bug has been logged online:
>
> Bug reference: 4513
> Logged by: Alexey Bashtanov
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.1
> Operating system: Red Hat Linux 2.6.20-1.2320.fc5smp i686
> Descri
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Alexey Bashtanov" <[EMAIL PROTECTED]> writes:
>> TopTransactionContext: 2986336304 total in 367 blocks; 192312 free (1088
>> chunks); 2986143992 used
> It does look like you have a memory leak in VACUUM FULL.
No, I think he's trying to fix a table that
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>> Hmm ... so then why are we seeing a failure?
[...]
Alex> This is not a Safe bug IMHO its our (ab)use of it that is
Alex> causing the problem.
Then explain why the problem goes away when you build perl with
threading turned off.
--
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Nice theory, but completely wrong: sort creates $a and $b in the
>> current package, not in main::.
Tom> Hmm ... so then why are we seeing a failure?
FWIW, I _don't_ see the failure. It seems to occur ONLY if perl was
built with threading
On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>
> >> Hmm ... so then why are we seeing a failure?
>
> [...]
> Alex> This is not a Safe bug IMHO its our (ab)use of it that is
> Alex> causing the problem.
>
> Then
20 matches
Mail list logo
