On Fri, Jul 9, 2010 at 4:03 AM, Craig Ringer
wrote:
> On 8/07/2010 10:40 PM, Hemanth wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5547
>> Logged by: Hemanth
>> Email address: hxku...@qwest.com
>> PostgreSQL version: 8.4
>> Operating system: Linux
Dave Page writes:
> On Fri, Jul 9, 2010 at 4:03 AM, Craig Ringer
> wrote:
>> I wonder if there's any way to have the bug report form de-duplicate posts
>> based on similar/identical text in sequential submissions.
> Not without starting down the path of writing a full blown bug
> tracker. The cu
On Fri, Jul 9, 2010 at 15:26, Tom Lane wrote:
> Dave Page writes:
>> On Fri, Jul 9, 2010 at 4:03 AM, Craig Ringer
>> wrote:
>>> I wonder if there's any way to have the bug report form de-duplicate posts
>>> based on similar/identical text in sequential submissions.
>
>> Not without starting down
Encountered another problem with pg_upgrade on Windows XP Pro:
I was trying to migrate from 8.4 to 9.0beta2 without linking, and apparently
there was not enough space on the hard drive. However, pg_upgrade didn't report
any problems, and it looked for all the world as if everything went well. I
The following bug has been logged online:
Bug reference: 5549
Logged by: David Schmitt
Email address: da...@dasz.at
PostgreSQL version: 8 and 9
Operating system: n/a
Description:Feature: plpgsql should allow DECLARE cursor FOR EXECUTE
'...'
Details:
This is not impl
"David Schmitt" writes:
> This is not implemented:
> DECLARE
> working_cursor NO SCROLL CURSOR FOR EXECUTE $$SELECT something $$ || tbl
> || $$ ... $$;
What's wrong with OPEN FOR EXECUTE?
The proposed addition seems a bit weird anyway since it presumes
nontrivial calculation to be done duri
depst...@alliedtesting.com wrote:
> Encountered another problem with pg_upgrade on Windows XP Pro:
>
> I was trying to migrate from 8.4 to 9.0beta2 without linking, and
> apparently there was not enough space on the hard drive. However,
> pg_upgrade didn't report any problems, and it looked for al
On Fri, Jul 9, 2010 at 04:58, Craig Ringer wrote:
> On 8/07/2010 6:31 PM, Magnus Hagander wrote:
>>
>> On Thu, Jul 8, 2010 at 03:10, Craig Ringer
>> wrote:
>>>
>>> IIRC on Windows client certificates live in
>>>
>>> %APPDATA%\.postgresql\
>>
>> That's a typo, it should be %APPDATA%\postgresql\ (
On Thu, Jul 8, 2010 at 10:52 PM, Tom Lane wrote:
> "Daniel Grace" writes:
>> I apologize for not including detailed schema information. It took a lot to
>> get this to reduce to the point it did, and hopefully this is enough
>> information to find a bug.
>
> It is not. You haven't provided anyw
Daniel Grace writes:
> So I've spent the greater portion of the last two hours trying to slim
> down the schema and query enough to provide something that can
> reproduce this.
> While I can reproduce it 100% of the time with live data, I can't get
> it to reproduce at all with test data -- thoug
On Sat, Jul 3, 2010 at 8:47 PM, Maksym Boguk wrote:
> notable planner had correctly estimated amount of rows in one side of the
> join:
> (Append (cost=0.00..0.98 rows=2 width=4))
> and planner hard correctly estimated amount of rows in the another side of
> the join:
> Index Scan using t3_value_
Daniel Grace writes:
> Plan that fails on EXPLAIN VERBOSE:
> "Nested Loop (cost=0.00..132.35 rows=24 width=4)"
> " -> Subquery Scan on t (cost=0.00..131.00 rows=6 width=4)"
> "Filter: (t.foo IS NULL)"
> "-> WindowAgg (cost=0.00..119.50 rows=1150 width=4)"
> " ->
12 matches
Mail list logo
