On 2/07/2011 12:42 PM, Maksym Boguk wrote:
But I found I can not stop
COPY bill.changes (id, cdate, mdate, status, table_name, pk_id, old_row,
new_row) TO stdout;
with pg_terminate_backend(procpid) or kill (procpid).
Which FreeBSD are you on? Version and architecture.
Can you obtain a backtra
Hi and thanks for responding...
While i performing my tests I used pg_dump via local socket
(
pg_dump -F c -Z 0 -t changes -a db > /dev/null
)
Now:
billing=# SELECT * from db_activity ;
age | datname | procpid | usename | waiting |
query_start | client_addr | client_port |
Jeff Davis writes:
> On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
>> Interesting problem... the bug is in get_op_btree_interpretation() which
>> has code like this:
>> ...
>> However, that's a bogus test, because btree_gist puts <> into an
>> opfamily. Thus, catlist->n_members == 1 even th
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Quite honestly, I think that the bug is that btree_gist took it upon
> itself to invent <> as an indexable operator.
Well, it was following documentation that any extension could
potentially use. I think it's a stretch to call it a bug in anythi
After some experiments I found not only copy to stdout but simple
select count(*) from changes can not be stopped too.
However select count(*) finishes successfully and no long IO locks or
waits was found in ktrace results.
Because situation seems unusual I tried to find what not usual with
the ta
Maxim Boguk writes:
> However, and here is unusual part: first 135GB of the table is
> completely dead/empty space without single live tuple
Ouch.
> So, (and here going pure theory), while code perform seq scan over
> large empty space it is not perform check for interrupts while looping
> over
On Fri, Jul 1, 2011 at 3:27 PM, Tom Lane wrote:
> Jon Nelson writes:
>> With 8.4.7, I ran into an issue trying to explain a VIEW query.
>> After much effort, I distilled the query down and was able to
>> replicate the issue with a test script, included below.
>
> FWIW, I can't reproduce such a fa
Jon Nelson writes:
> On Fri, Jul 1, 2011 at 3:27 PM, Tom Lane wrote:
>> FWIW, I can't reproduce such a failure with current 8.4 branch (nor any
>> other).
> Try adding:
> set enable_mergejoin = false;
Thanks, that did it. I've repaired the symptom exposed here:
http://git.postgresql.org/gitweb
