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?
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 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
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
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
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
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
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 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
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
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
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 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 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,
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
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
16 matches
Mail list logo
