The following bug has been logged on the website:
Bug reference: 6785
Logged by: Anderson Valadares
Email address: anderva...@gmail.com
PostgreSQL version: 9.1.4
Operating system: Linux CentOS 5.5
Description:
Hello,
we recently had a memory exhaustion in the Postgr
Hi,
hubert depesz lubaczewski schrieb/wrote:
generally - order by datname is understood as "order by *variable
datname*". - which is null.
It's clear that it's a shadowing problem. But it's not a "FOR IN EXECUTE"
where a variable makes sense. I mean why is a "ORDER BY variable" valid in
"FOR
Hi pgsql developers:
1 . Postgres 9.1, database server OS platform: Linux x86_64 and Windows
XP Professional Version 2002 SP3
Client OS platform: Linux x86_64 , Windows XP Professional Version
2002 SP3, Windows Server 2003 Standard Edition SP2
2. pgAdminIII: version 1.14.3, or the defaul
Hi,
On Monday, July 30, 2012 03:15:37 PM anderva...@gmail.com wrote:
> we recently had a memory exhaustion in the PostgreSQL server of the
> company, after a scan found a likely memory leak when using a plpgsql
> function.
> The problem occurred on an IBM x3400 server with 12G, CentOS 5.5 and
>
Hi,
2012/7/30 Andres Freund
> Hi,
>
> On Monday, July 30, 2012 03:15:37 PM anderva...@gmail.com wrote:
> > we recently had a memory exhaustion in the PostgreSQL server of the
> > company, after a scan found a likely memory leak when using a plpgsql
> > function.
> > The problem occurred on an
Hi,
On Monday, July 30, 2012 05:38:07 PM Anderson Valadares wrote:
> I understand, but the memory should not be returned after the execution of
> the function?
Well, that depends on how memory was allocated by the libc. When it used brk()
to allocate memory its rather likely that the memory canno
On Mon, Jul 30, 2012 at 05:56:22PM +0200, Andres Freund wrote:
> Hi,
>
> On Monday, July 30, 2012 05:38:07 PM Anderson Valadares wrote:
> > I understand, but the memory should not be returned after the execution of
> > the function?
> Well, that depends on how memory was allocated by the libc. Whe
On 7/30/2012 5:56 AM, Boris Folgmann wrote:
Hi,
hubert depesz lubaczewski schrieb/wrote:
generally - order by datname is understood as "order by *variable
datname*". - which is null.
It's clear that it's a shadowing problem. But it's not a "FOR IN EXECUTE"
where a variable makes sense. I mean
Jan Wieck writes:
> Note that PL/pgSQL replaces all local variables inside a query with
> $-parameters for the prepared SPI plan. The parser rejects ordering by
> non-integer constants, but it does not reject ordering by $-parameters
> or constant expressions. (maybe it should).
The only real
On 07/24/2012 08:45 PM, pilum...@uni-muenster.de wrote:
The following bug has been logged on the website:
Bug reference: 6751
Logged by: Arne Scheffer
Email address: pilum...@uni-muenster.de
PostgreSQL version: 9.1.4
Operating system: Unix (RHEL 6)
Description:
We've been u
On 07/30/2012 11:49 AM, Emcisc (JinWei) Zhao wrote:
5.Run the SQL query: "SELECT setting FROM pg_settings WHERE name =
'bytea_output'; " in pgAdmin3. It will show you the value 'escape'.
6.Run the client application 'psql' to connect to the same DB server
and database with the same user accou
Sorry, all right. It was my mistake.
2012/7/27 Craig Ringer
> On 07/27/2012 07:52 AM, fabio.lun...@gmail.com wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 6768
> Logged by: Fábio Hentz Lunkes
> Email address: fabio.lun...@gmail.com
> PostgreS
hi,
i've just upgraded to 9.1.4 on macosx-10.6.8 and psql crashes
whenever the -h option is used (either with "localhost" or any
other hostname). i only have hostssl connections.
attached is a macosx crash report in case it helps.
i think i'll downgrade now :-)
cheers,
raf
Process: psq
On 07/31/2012 07:31 AM, Fábio Hentz Lunkes wrote:
Sorry, all right. It was my mistake.
No worries - thanks for writing back to confirm. That way anyone else
having the issue later will have some idea where to look (or not look at
least).
--
Craig Ringer
On Tue, 2012-07-31 at 10:19 +0800, Craig Ringer wrote:
> On 07/30/2012 11:49 AM, Emcisc (JinWei) Zhao wrote:
> > 5.Run the SQL query: "SELECT setting FROM pg_settings WHERE name =
> > 'bytea_output'; " in pgAdmin3. It will show you the value 'escape'.
> >
> > 6.Run the client application 'psql' t
On 07/31/2012 01:50 PM, Guillaume Lelarge wrote:
Check the PgAdmin-III preferences; there may be an option to control its
preferred bytea format.
There's no option to control this.
Thanks for confirming that.
Is it really best for PgAdmin-III to have a different default than Pg
its self?
16 matches
Mail list logo
