The following bug has been logged online:
Bug reference: 5366
Logged by: Helena Biander
Email address: helena.bian...@nordea.com
PostgreSQL version: 8.4
Operating system: Windows
Description:Stackbuilder doesn't work
Details:
When I run stackbuilder it says that
htt
Any chance you have a firewall or such intercepting the request? And
either rejecting it or showing a captive portal or something? Can you
download that URL in a webbrowser on the same machine?
/Magnus
On Tuesday, March 9, 2010, Helena Biander wrote:
>
> The following bug has been logged online
Hi all,
I'm running Postgresql 8.3.9 on debian lenny amd64
the box has 8GB of ram, the db runs on a separate
software raid-1 device, that's the output of select version();
# SELECT version () ;
version
---
2010/3/9 Tom Lane :
> Robert Haas writes:
>> What seems odd to me is that NEW is apparently some other kind of
>> thing that is not the same kind of thing as the row variable.
>
> NEW is a record variable, not a row variable. In this context that's
> sensible because its actual rowtype is unspeci
Andrea Suisani writes:
> I'm experiencing something weird. here the session's log
> that involves the prob I mentioned
> 2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates
> unique constraint "pg_type_typname_nsp_index"
> 2010-03-08 12:59:41 CET p...@c[3189]statement: crea
On Tue, Mar 9, 2010 at 7:31 AM, Pavel Stehule wrote:
> 2010/3/9 Tom Lane :
>> Robert Haas writes:
>>> What seems odd to me is that NEW is apparently some other kind of
>>> thing that is not the same kind of thing as the row variable.
>>
>> NEW is a record variable, not a row variable. In this co
Robert Haas writes:
> What seems odd to me is that NEW is apparently some other kind of
> thing that is not the same kind of thing as the row variable.
NEW is a record variable, not a row variable. In this context that's
sensible because its actual rowtype is unspecified by the function text.
Th
Chris Travers writes:
> I think this behavior is unexpected, but not a bug. The best fix is
> documenting the datatype better. Something like adding a paragraph to
> chapter 38.9 just above the examples (going off the 8.4 docs):
> Please note, NEW and OLD records are not guaranteed to follow th
On 09/03/2010 16:51, Tom Lane wrote:
Andrea Suisani writes:
I'm experiencing something weird. here the session's log
that involves the prob I mentioned
2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates unique
constraint "pg_type_typname_nsp_index"
2010-03-08 12:59:41
The following bug has been logged online:
Bug reference: 5367
Logged by: Boguk Maxim
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.2
Operating system: Linux 2.6.18-164
Description:TEMP TABLES with ON COMMIT DELETE ROWS and different
pg_stat features
Det
On 09/03/2010 17:12, Andrea Suisani wrote:
On 09/03/2010 16:51, Tom Lane wrote:
Andrea Suisani writes:
I'm experiencing something weird. here the session's log
that involves the prob I mentioned
2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates
unique constraint "pg_typ
"Boguk Maxim" writes:
> When transaction which used TEMP table with ON COMMIT DELETE ROWS commit or
> rollback pg_stats and pg_stat_all_tables about that temporary table doesn't
> reset.
> It's no problem with common applications but with pgbouncer + transaction
> pooling mode postgresql backends
I wrote:
> I think that the real issue here doesn't have anything to do
> with NEW/OLD as such, but is related to the representational difference
> between record and row variables.
BTW, just to reinforce that it's not NEW/OLD that's the issue, here's
a simplified version of Oleg's non-trigger exa
On Sun, Mar 7, 2010 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 5, 2010 at 5:32 PM, Tom Lane wrote:
>>> It's arguably a bug, but since we lack consensus on whether NULL and
>>> ROW(NULL,NULL,...) are the same thing, it's difficult to make a
>>> bulletproof case either way.
The following bug has been logged online:
Bug reference: 5369
Logged by: Bassem Fennani
Email address: bassem.fenn...@uqtr.ca
PostgreSQL version: 8.4
Operating system: Win XP
Description:can't install it
Details:
Hello,
I could not install postgresql on the desktop
"Bassem Fennani" wrote:
> Description:can't install it
> I could not install postgresql on the desktops in the office : IBM
> IntelliStation Z Pro with Xeon processors.
That's not enough information for us to have much chance of guessing
your problem. Please read this page:
http:/
All,
What I did:
1. Set up 9.0a4 doing SR replication with a 2nd 9.0a4
2. Ran pgbench for a while.
3. Aborted pgbench with Ctl-C
4. Changed vacuum_defer_cleanup_age in postgresql.conf and reloaded
5. Ran pgbench again, and got:
Sidney-Stratton:pg90 josh$ pgbench -c 2 -T 300 bench
starting vacuum
17 matches
Mail list logo
