depst...@alliedtesting.com wrote:
BB> PostgreSQL 9.0 beta 2
> Windows XP Professional SP2
>
> While migrating the database from 8.4 to 9.0 using pg_upgrade (now part of
> the Postgres project), the following issues came up:
>
> 1. When using the --logfile option, pg_upgrade quits with an err
On 22/06/10 00:47, Heikki Linnakangas wrote:
Maybe it would be easier to somehow protect the portal then, and throw
an error if you try to close it. We could just mark the portal as
PORTAL_ACTIVE while we run the user statements, but that would also
forbid fetching or moving it. I'm thinking of a
On 22/06/10 00:59, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of lun jun 21 17:47:43 -0400 2010:
Maybe it would be easier to somehow protect the portal then, and throw
an error if you try to close it. We could just mark the portal as
PORTAL_ACTIVE while we run the user sta
Excerpts from Heikki Linnakangas's message of lun jun 21 17:47:43 -0400 2010:
> Maybe it would be easier to somehow protect the portal then, and throw
> an error if you try to close it. We could just mark the portal as
> PORTAL_ACTIVE while we run the user statements, but that would also
> forb
On 21/06/10 22:25, Tom Lane wrote:
prefetch_ok is not meant to be bulletproof,
only to ensure that in cases where the cursor is *meant* to be exposed
to the user its behavior is as he expects. If you're trying to stop a
crash you need to realize that people can get at any portal at all.
Oh, I
On Mon, Jun 21, 2010 at 1:26 PM, Ken Alverson
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5518
> Logged by: Ken Alverson
> Email address: ken.alver...@helpsystems.com
> PostgreSQL version: 8.4
> Operating system: Windows XP SP3
> Description:
Heikki Linnakangas writes:
> On 21/06/10 17:08, Tom Lane wrote:
>> Also, isn't exec_for_query() at just as much risk?
>> The latter's problem would only be exposed if the cursor was closed
>> at a batch boundary, but it's still a problem.
> Can you elaborate? I thought I fixed exec_for_query(). (
On Mon, 2010-06-21 at 17:38 +, Kelly McLaughlin wrote:
> Bug reference: 5519
> Logged by: Kelly McLaughlin
> Email address: mclaughli...@gmail.com
> PostgreSQL version: 8.4.4
> Operating system: Centos 5
> Description:uuid-ossp files missing from contrib rpm
> Detai
On 21/06/10 17:08, Tom Lane wrote:
I suspect you need to pstrdup() the portalname.
Yes, you're right. Thanks.
Also, isn't exec_for_query() at just as much risk?
The latter's problem would only be exposed if the cursor was closed
at a batch boundary, but it's still a problem.
Can you elabora
The following bug has been logged online:
Bug reference: 5519
Logged by: Kelly McLaughlin
Email address: mclaughli...@gmail.com
PostgreSQL version: 8.4.4
Operating system: Centos 5
Description:uuid-ossp files missing from contrib rpm
Details:
The uuid-ossp files are
The following bug has been logged online:
Bug reference: 5518
Logged by: Ken Alverson
Email address: ken.alver...@helpsystems.com
PostgreSQL version: 8.4
Operating system: Windows XP SP3
Description:MS crash - can duplicate every time
Details:
1. Install postgresplu
On Fri, Jun 18, 2010 at 7:09 AM, Praveen Upadhyaya (ZA)
wrote:
> I am getting the following error. Can you please help?
> odbc driver could not be loaded due to system error code 127
You may want to try this question on the pgsql-odbc mailing list.
http://archives.postgresql.org/pgsql-odbc/
--
On Fri, Jun 18, 2010 at 4:02 AM, Ravi wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5510
> Logged by: Ravi
> Email address: surabi...@gmail.com
> PostgreSQL version: 8
> Operating system: Windows 7
> Description: ODBC database 8.4.2 not working
Tatsuhito Kasahara writes:
> make_greater_string() does not return a string when some UTF8 strings
> set to str_const.
> # Especially UTF8 strings which contains 'BF' in last byte.
The patch you propose for this is really untenable: it will re-introduce
many corner cases that we got rid of years
Greg Stark writes:
> On Mon, Jun 21, 2010 at 12:41 PM, Yuhui wrote:
>> CREATE TABLE mem_leak(A INT, B char(50) default 'abcdefg');
>> INSERT INTO mem_leak(a) VALUES(generate_series(1,2));
>>
>> The memory which the execution process occupation will grows larger and
>> larger until all th
On Mon, Jun 21, 2010 at 12:41 PM, Yuhui wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5516
> Logged by: Yuhui
> Email address: xingyu...@gmail.com
> PostgreSQL version: 8.3,8.2,8.1
> Operating system: Linux,Windows
> Description: Memory grows u
Heikki Linnakangas writes:
> The problem is that exec_stmt_forc keeps using a pointer to the Portal,
> which becomes invalid if the cursor is closed in the middle. Patch
> attached, will apply..
Does that really fix anything? I suspect you need to pstrdup() the
portalname. Also, isn't exec_fo
The following bug has been logged online:
Bug reference: 5515
Logged by: Yuhui
Email address: thesecularb...@hotmail.com
PostgreSQL version: 8.3,8.2,8.1
Operating system: Linux,Windows
Description:Memory grows up problem
Details:
Do the follow setp to reproduce the
The following bug has been logged online:
Bug reference: 5516
Logged by: Yuhui
Email address: xingyu...@gmail.com
PostgreSQL version: 8.3,8.2,8.1
Operating system: Linux,Windows
Description:Memory grows up problem
Details:
Do the follow setp to reproduce the problem
Hi !
make_greater_string() does not return a string when some UTF8 strings
set to str_const.
# Especially UTF8 strings which contains 'BF' in last byte.
Because make_greater_string() only try incrementing the last byte of
the string, and not try same test for upper bytes.
Therefore, some queries
postgres=# CREATE FUNCTION func() RETURNS VOID AS $$
declare
cur CURSOR IS SELECT generate_series(1,10) AS a;
BEGIN
FOR erec IN cur LOOP
raise notice 'row %', erec.a ;
IF (erec.a = 5) THEN CLOSE cur; END IF;
END LOOP;
RETURN;
END;
$$ LA
21 matches
Mail list logo
