Обсуждение: PgAdmin III 1.12 crazy memory usage
I can't recreate this, so it may not be much help, but I left PgAdmin running with no query windows open at all, and eventually I noticed my PC slowing right down as memory started to swap. I've attached a screenshot to show its memory usage. Actions I had performed earlier are attempting to select all rows from a massive table, and closed that result window a few seconds into it attempting to fetch results. I had issued a few queries in other query windows which were quite minor ones which got counts. I doubled the tablespace's random page cost for one of the connected clusters, and updated the statistics target for a column on a table, then performed a VACUUM ANALYZE. And I also attempted to restore a ~20GB custom format database into a new database, but killed the process some minutes into it as the cancel button on the restore window wasn't responding. The window then showed a status of restore failed. I then deleted that database. After all this, no more query windows, result windows, or any other PgAdmin-related windows were open except for the main application. It was presumably idle as I had no other running processes, and was left focused on a cluster node. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Вложения
On Fri, Oct 1, 2010 at 2:00 PM, Thom Brown <thom@linux.com> wrote: > I can't recreate this, so it may not be much help, but I left PgAdmin > running with no query windows open at all, and eventually I noticed my > PC slowing right down as memory started to swap. I've attached a > screenshot to show its memory usage. VM size of a gig? Thats small for Windows isn't it? :-p > Actions I had performed earlier are attempting to select all rows from > a massive table, and closed that result window a few seconds into it > attempting to fetch results. That's where my suspicions lie. Can you try to reproduce it by doing that again? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On 1 October 2010 14:12, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Oct 1, 2010 at 2:00 PM, Thom Brown <thom@linux.com> wrote: >> I can't recreate this, so it may not be much help, but I left PgAdmin >> running with no query windows open at all, and eventually I noticed my >> PC slowing right down as memory started to swap. I've attached a >> screenshot to show its memory usage. > > VM size of a gig? Thats small for Windows isn't it? :-p > >> Actions I had performed earlier are attempting to select all rows from >> a massive table, and closed that result window a few seconds into it >> attempting to fetch results. > > That's where my suspicions lie. Can you try to reproduce it by doing that again? No, I've attempted that with several large tables, but it doesn't make any noticeable difference. Where it's actually started fetching results and displaying them, closing the window causes pgAdmin to correctly returns the memory. I've also checked what's happening server-side when closing the window, and the query is cancelled. Is it theorically possible for pgAdmin to fail to cancel the query when closing the results window? Note: Whenever I say results window, I actually mean the view/edit data window. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 1 October 2010 14:21, Thom Brown <thom@linux.com> wrote: > On 1 October 2010 14:12, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Oct 1, 2010 at 2:00 PM, Thom Brown <thom@linux.com> wrote: >>> I can't recreate this, so it may not be much help, but I left PgAdmin >>> running with no query windows open at all, and eventually I noticed my >>> PC slowing right down as memory started to swap. I've attached a >>> screenshot to show its memory usage. >> >> VM size of a gig? Thats small for Windows isn't it? :-p >> >>> Actions I had performed earlier are attempting to select all rows from >>> a massive table, and closed that result window a few seconds into it >>> attempting to fetch results. >> >> That's where my suspicions lie. Can you try to reproduce it by doing that again? > > No, I've attempted that with several large tables, but it doesn't make > any noticeable difference. Where it's actually started fetching > results and displaying them, closing the window causes pgAdmin to > correctly returns the memory. I've also checked what's happening > server-side when closing the window, and the query is cancelled. Is > it theorically possible for pgAdmin to fail to cancel the query when > closing the results window? > > Note: Whenever I say results window, I actually mean the view/edit data window. Got this in the logs if it's relevant at all. Note that bookingbaskets is the massive table: 2010-10-01 13:37:09 BST STATEMENT SELECT * FROM public.bookingbaskets ORDER BY bookingbasketid ASC 2010-10-01 13:37:11 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. 2010-10-01 13:37:12 BST LOG unexpected EOF on client connection 2010-10-01 13:37:11 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection 2010-10-01 13:37:11 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection 2010-10-01 13:37:12 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection 2010-10-01 13:37:12 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection 2010-10-01 13:37:12 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection 2010-10-01 13:37:12 BST LOG could not receive data from client: No connection could be made because the target machine actively refused it. This was just before I noticed the massive memory usage. I took the screenshot at 13:42. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Fri, Oct 1, 2010 at 2:21 PM, Thom Brown <thom@linux.com> wrote: > On 1 October 2010 14:12, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Oct 1, 2010 at 2:00 PM, Thom Brown <thom@linux.com> wrote: >>> I can't recreate this, so it may not be much help, but I left PgAdmin >>> running with no query windows open at all, and eventually I noticed my >>> PC slowing right down as memory started to swap. I've attached a >>> screenshot to show its memory usage. >> >> VM size of a gig? Thats small for Windows isn't it? :-p >> >>> Actions I had performed earlier are attempting to select all rows from >>> a massive table, and closed that result window a few seconds into it >>> attempting to fetch results. >> >> That's where my suspicions lie. Can you try to reproduce it by doing that again? > > No, I've attempted that with several large tables, but it doesn't make > any noticeable difference. Where it's actually started fetching > results and displaying them, closing the window causes pgAdmin to > correctly returns the memory. I've also checked what's happening > server-side when closing the window, and the query is cancelled. Is > it theorically possible for pgAdmin to fail to cancel the query when > closing the results window? Well it shouldn't be, but it's always possible we missed something. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Hi all,I've noticed a strange behaviour in editing a field of type text using the data grid: a double quotes is added at the beginning and at the end of the text. Using Windows Xp SP 3 PgAdmin 1.12.0 Postgres 8.3.8 on i486-pc-linux ubuntu 4.2.4 Thnak you and best regards, Mauro
Le 02/10/2010 11:05, Mauro Bertoli a écrit : > [...] > I've noticed a strange behaviour in editing a field of type text using the data > grid: a double quotes is added at the beginning and at the end of the text. > I don't have that. Can you give us the specific steps you follow to reproduce your bug? Thanks. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
Sorry, I cannot. I've update from 1.10 to 1.12 today, and that strange behaviour succeded. Now, with the same table and same data is all ok... but I'm not crazy :) When I can reproduce it I'll be more precise. Thanks. ----- Messaggio originale ----- > Da: Guillaume Lelarge <guillaume@lelarge.info> > A: Mauro Bertoli <bertoli.mauro@yahoo.it> > Cc: pgadmin-support <pgadmin-support@postgresql.org> > Inviato: Sab 2 ottobre 2010, 23:38:54 > Oggetto: Re: [pgadmin-support] pgAdmin III 1.12 strange behaviour in text >editing > > Le 02/10/2010 11:05, Mauro Bertoli a écrit : > > [...] > > I've noticed a strange behaviour in editing a field of type text using the >data > > > grid: a double quotes is added at the beginning and at the end of the text. > > > > I don't have that. Can you give us the specific steps you follow to > reproduce your bug? Thanks. > > > -- > Guillaume > http://www.postgresql.fr > http://dalibo.com >
Hi, the steps to reproduced the problem (that I think it is a dis-liked behaviour): If I select a portion of text and then press CTRL+C (copy) and then press CTRL+V (paste) it will paste full cell text wrapped around a double quotes, but I expect that paste the text I selected. If I right-click "copy" then "paste" it work fine. Thanks for your great support in this great tool, Mauro ----- Messaggio originale ----- > Da: Mauro Bertoli <bertoli.mauro@yahoo.it> > A: Guillaume Lelarge <guillaume@lelarge.info> > Cc: pgadmin-support <pgadmin-support@postgresql.org> > Inviato: Sab 2 ottobre 2010, 23:53:19 > Oggetto: Re: [pgadmin-support] pgAdmin III 1.12 strange behaviour in text >editing > > Sorry, I cannot. I've update from 1.10 to 1.12 today, and that strange >behaviour > > succeded. > Now, with the same table and same data is all ok... but I'm not crazy :) > When I can reproduce it I'll be more precise. > Thanks. > > > ----- Messaggio originale ----- > > Da: Guillaume Lelarge <guillaume@lelarge.info> > > A: Mauro Bertoli <bertoli.mauro@yahoo.it> > > Cc: pgadmin-support <pgadmin-support@postgresql.org> > > Inviato: Sab 2 ottobre 2010, 23:38:54 > > Oggetto: Re: [pgadmin-support] pgAdmin III 1.12 strange behaviour in text > >editing > > > > Le 02/10/2010 11:05, Mauro Bertoli a écrit : > > > [...] > > > I've noticed a strange behaviour in editing a field of type text using >the > > >data > > > > > grid: a double quotes is added at the beginning and at the end of the >text. > > > > > > > I don't have that. Can you give us the specific steps you follow to > > reproduce your bug? Thanks. > > > > > > -- > > Guillaume > > http://www.postgresql.fr > > http://dalibo.com > > > > > > > -- > Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-support >
Le 03/10/2010 19:16, Mauro Bertoli a écrit :
> Hi, the steps to reproduced the problem (that I think it is a dis-liked
> behaviour):
> If I select a portion of text and then press CTRL+C (copy) and then press CTRL+V
> (paste) it will paste full cell text wrapped around a double quotes, but I
> expect that paste the text I selected. If I right-click "copy" then "paste" it
> work fine.
There is a reason for that. Not sure everyone will see that as a good
reason, and I'm open to suggestion for enhancing it.
When you click on a cell and do Ctrl-C, you're in row copy mode. So you
get something like the CSV copy mode with double quotes for text values
and semi-colon between each cells (if you selected more than one cell).
You can change the double quotes and semi-colons with the options dialog
("Query Tool" tab, "Result copy quote character" and "Result copy field
separator" fields).
When you edit a cell and do Ctrl-C, you're in text copy mode, so you get
the precise text (I mean, without quotes)... but you can't copy multiple
cells this way.
--
Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Fri, Oct 1, 2010 at 2:32 PM, Thom Brown <thom@linux.com> wrote: > 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection > 2010-10-01 13:37:12 BST LOG could not receive data from client: No > connection could be made because the target machine actively refused > it. > > This was just before I noticed the massive memory usage. I took the > screenshot at 13:42. I chatted with Guillaume about this, and we don't currently see how it could happen (clearly it did, but...). If you can figure out a way to reproduce, that would be a huge help. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
> Da: Guillaume Lelarge <guillaume@lelarge.info>
> A: Mauro Bertoli <bertoli.mauro@yahoo.it>
> Cc: pgadmin-support <pgadmin-support@postgresql.org>
> Inviato: Mar 5 ottobre 2010, 09:50:19
> Oggetto: Re: [pgadmin-support] pgAdmin III 1.12 strange behaviour in text
>editing
>
> Le 03/10/2010 19:16, Mauro Bertoli a écrit :
> > Hi, the steps to reproduced the problem (that I think it is a dis-liked
> > behaviour):
> > If I select a portion of text and then press CTRL+C (copy) and then press
>CTRL+V
>
> > (paste) it will paste full cell text wrapped around a double quotes, but I
> > expect that paste the text I selected. If I right-click "copy" then "paste"
>it
>
> > work fine.
>
> There is a reason for that. Not sure everyone will see that as a good
> reason, and I'm open to suggestion for enhancing it.
>
> When you click on a cell and do Ctrl-C, you're in row copy mode. So you
> get something like the CSV copy mode with double quotes for text values
> and semi-colon between each cells (if you selected more than one cell).
> You can change the double quotes and semi-colons with the options dialog
> ("Query Tool" tab, "Result copy quote character" and "Result copy field
> separator" fields).
>
> When you edit a cell and do Ctrl-C, you're in text copy mode, so you get
> the precise text (I mean, without quotes)... but you can't copy multiple
> cells this way.
I think that there is a bug, because if I edit a cell (inside the cell, not in
row copy mode) and press CTRL+C it wrap with double quotes.
I think that if I select a cell (but I'm non inside the cell editing it) and
press CTRL+C is usefull that wrap with double quotes, like csv. But if I select
a portion of text and press CTRL+C, I expect that it copy the real text I
selected.
Hope this help,
Mauro
On 5 October 2010 10:20, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Oct 1, 2010 at 2:32 PM, Thom Brown <thom@linux.com> wrote: >> 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection >> 2010-10-01 13:37:12 BST LOG could not receive data from client: No >> connection could be made because the target machine actively refused >> it. >> >> This was just before I noticed the massive memory usage. I took the >> screenshot at 13:42. > > I chatted with Guillaume about this, and we don't currently see how it > could happen (clearly it did, but...). If you can figure out a way to > reproduce, that would be a huge help. Okay, I've tried reproducing it by asking it to show the edit view without restricting the number of results, but seems to be fine. But if I open with limited to 100, then change it to "no limit", refresh and close, the query still appears to be running on the server. It shows "pgAdmin III - Edit Grid" as the process running the query too, and there's still lots of I/O on the machine. I definitely don't still have that window open. At this point it hasn't received any results back, so the memory usage hasn't peaked yet. A postgres process has, however, has over 2GB of read I/O, bearing in mind I've only used it very little today. ... and has now reached 3GB as I'm writing this. I've had to kill of pgAdmin III now since it stopped responding, even though the memory usage hadn't gone up. Postgres still appears to be busy collecting the results. Tried it again, and exactly the same problem. Only happens when initially opening the edit view with 100 rows and updating it to have no limit, then closing it before results come back. And now another table which can't return results back straight away, but would still return them after a short wait... same problem, and pgAdmin III is bloating. It's reached 200MB and rising. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 5 October 2010 11:03, Thom Brown <thom@linux.com> wrote: > On 5 October 2010 10:20, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Oct 1, 2010 at 2:32 PM, Thom Brown <thom@linux.com> wrote: >>> 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection >>> 2010-10-01 13:37:12 BST LOG could not receive data from client: No >>> connection could be made because the target machine actively refused >>> it. >>> >>> This was just before I noticed the massive memory usage. I took the >>> screenshot at 13:42. >> >> I chatted with Guillaume about this, and we don't currently see how it >> could happen (clearly it did, but...). If you can figure out a way to >> reproduce, that would be a huge help. > > Okay, I've tried reproducing it by asking it to show the edit view > without restricting the number of results, but seems to be fine. But > if I open with limited to 100, then change it to "no limit", refresh > and close, the query still appears to be running on the server. It > shows "pgAdmin III - Edit Grid" as the process running the query too, > and there's still lots of I/O on the machine. I definitely don't > still have that window open. > > At this point it hasn't received any results back, so the memory usage > hasn't peaked yet. A postgres process has, however, has over 2GB of > read I/O, bearing in mind I've only used it very little today. ... > and has now reached 3GB as I'm writing this. > > I've had to kill of pgAdmin III now since it stopped responding, even > though the memory usage hadn't gone up. Postgres still appears to be > busy collecting the results. > > Tried it again, and exactly the same problem. Only happens when > initially opening the edit view with 100 rows and updating it to have > no limit, then closing it before results come back. > > And now another table which can't return results back straight away, > but would still return them after a short wait... same problem, and > pgAdmin III is bloating. It's reached 200MB and rising. Another note, pgAdmin III returns to normal memory usage once all results have been "received". But if you're selecting from a 100GB table by accident, that's not really a consolation. ;) -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Tue, Oct 5, 2010 at 11:03 AM, Thom Brown <thom@linux.com> wrote: > Okay, I've tried reproducing it by asking it to show the edit view > without restricting the number of results, but seems to be fine. But > if I open with limited to 100, then change it to "no limit", refresh > and close, the query still appears to be running on the server. It > shows "pgAdmin III - Edit Grid" as the process running the query too, > and there's still lots of I/O on the machine. I definitely don't > still have that window open. OK, so I believe the attached patch fixes this, though I'm slightly nervous about unintended side-effects. I'll provide Thom with a binary for testing, but would appreciate it if someone else (Guillaume?) could also review the patch. Thanks! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Вложения
On 7 October 2010 12:56, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Oct 5, 2010 at 11:03 AM, Thom Brown <thom@linux.com> wrote: >> Okay, I've tried reproducing it by asking it to show the edit view >> without restricting the number of results, but seems to be fine. But >> if I open with limited to 100, then change it to "no limit", refresh >> and close, the query still appears to be running on the server. It >> shows "pgAdmin III - Edit Grid" as the process running the query too, >> and there's still lots of I/O on the machine. I definitely don't >> still have that window open. > > OK, so I believe the attached patch fixes this, though I'm slightly > nervous about unintended side-effects. I'll provide Thom with a binary > for testing, but would appreciate it if someone else (Guillaume?) > could also review the patch. Yes, that appears to have fixed the problem. :) -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Le 07/10/2010 13:56, Dave Page a écrit : > On Tue, Oct 5, 2010 at 11:03 AM, Thom Brown <thom@linux.com> wrote: >> Okay, I've tried reproducing it by asking it to show the edit view >> without restricting the number of results, but seems to be fine. But >> if I open with limited to 100, then change it to "no limit", refresh >> and close, the query still appears to be running on the server. It >> shows "pgAdmin III - Edit Grid" as the process running the query too, >> and there's still lots of I/O on the machine. I definitely don't >> still have that window open. > > OK, so I believe the attached patch fixes this, though I'm slightly > nervous about unintended side-effects. I'll provide Thom with a binary > for testing, but would appreciate it if someone else (Guillaume?) > could also review the patch. > Seems good to me. I don't find any side-effects on this patch. So +1 to commit it. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Thu, Oct 7, 2010 at 4:59 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 07/10/2010 13:56, Dave Page a écrit : >> On Tue, Oct 5, 2010 at 11:03 AM, Thom Brown <thom@linux.com> wrote: >>> Okay, I've tried reproducing it by asking it to show the edit view >>> without restricting the number of results, but seems to be fine. But >>> if I open with limited to 100, then change it to "no limit", refresh >>> and close, the query still appears to be running on the server. It >>> shows "pgAdmin III - Edit Grid" as the process running the query too, >>> and there's still lots of I/O on the machine. I definitely don't >>> still have that window open. >> >> OK, so I believe the attached patch fixes this, though I'm slightly >> nervous about unintended side-effects. I'll provide Thom with a binary >> for testing, but would appreciate it if someone else (Guillaume?) >> could also review the patch. >> > > Seems good to me. I don't find any side-effects on this patch. So +1 to > commit it. Thanks! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Thu, Oct 7, 2010 at 4:59 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 07/10/2010 13:56, Dave Page a écrit : >> On Tue, Oct 5, 2010 at 11:03 AM, Thom Brown <thom@linux.com> wrote: >>> Okay, I've tried reproducing it by asking it to show the edit view >>> without restricting the number of results, but seems to be fine. But >>> if I open with limited to 100, then change it to "no limit", refresh >>> and close, the query still appears to be running on the server. It >>> shows "pgAdmin III - Edit Grid" as the process running the query too, >>> and there's still lots of I/O on the machine. I definitely don't >>> still have that window open. >> >> OK, so I believe the attached patch fixes this, though I'm slightly >> nervous about unintended side-effects. I'll provide Thom with a binary >> for testing, but would appreciate it if someone else (Guillaume?) >> could also review the patch. >> > > Seems good to me. I don't find any side-effects on this patch. So +1 to > commit it. Done. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12 October 2010 10:41, Dave Page <dpage@pgadmin.org> wrote: > On Thu, Oct 7, 2010 at 4:59 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 07/10/2010 13:56, Dave Page a écrit : >>> On Tue, Oct 5, 2010 at 11:03 AM, Thom Brown <thom@linux.com> wrote: >>>> Okay, I've tried reproducing it by asking it to show the edit view >>>> without restricting the number of results, but seems to be fine. But >>>> if I open with limited to 100, then change it to "no limit", refresh >>>> and close, the query still appears to be running on the server. It >>>> shows "pgAdmin III - Edit Grid" as the process running the query too, >>>> and there's still lots of I/O on the machine. I definitely don't >>>> still have that window open. >>> >>> OK, so I believe the attached patch fixes this, though I'm slightly >>> nervous about unintended side-effects. I'll provide Thom with a binary >>> for testing, but would appreciate it if someone else (Guillaume?) >>> could also review the patch. >>> >> >> Seems good to me. I don't find any side-effects on this patch. So +1 to >> commit it. > > Done. Thanks Dave. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Le 05/10/2010 11:32, Mauro Bertoli a écrit :
>> Da: Guillaume Lelarge <guillaume@lelarge.info>
>> A: Mauro Bertoli <bertoli.mauro@yahoo.it>
>> Cc: pgadmin-support <pgadmin-support@postgresql.org>
>> Inviato: Mar 5 ottobre 2010, 09:50:19
>> Oggetto: Re: [pgadmin-support] pgAdmin III 1.12 strange behaviour in text
>> editing
>>
>> Le 03/10/2010 19:16, Mauro Bertoli a écrit :
>>> Hi, the steps to reproduced the problem (that I think it is a dis-liked
>>> behaviour):
>>> If I select a portion of text and then press CTRL+C (copy) and then press
>> CTRL+V
>>
>>> (paste) it will paste full cell text wrapped around a double quotes, but I
>>> expect that paste the text I selected. If I right-click "copy" then "paste"
>> it
>>
>>> work fine.
>>
>> There is a reason for that. Not sure everyone will see that as a good
>> reason, and I'm open to suggestion for enhancing it.
>>
>> When you click on a cell and do Ctrl-C, you're in row copy mode. So you
>> get something like the CSV copy mode with double quotes for text values
>> and semi-colon between each cells (if you selected more than one cell).
>> You can change the double quotes and semi-colons with the options dialog
>> ("Query Tool" tab, "Result copy quote character" and "Result copy field
>> separator" fields).
>>
>> When you edit a cell and do Ctrl-C, you're in text copy mode, so you get
>> the precise text (I mean, without quotes)... but you can't copy multiple
>> cells this way.
>
>
> I think that there is a bug, because if I edit a cell (inside the cell, not in
> row copy mode) and press CTRL+C it wrap with double quotes.
> I think that if I select a cell (but I'm non inside the cell editing it) and
> press CTRL+C is usefull that wrap with double quotes, like csv. But if I select
> a portion of text and press CTRL+C, I expect that it copy the real text I
> selected.
>
Finally I found some time (and motivation) to work on this. So, it's
fixed. Should be available in 1.12.3.
Thanks for your report.
--
Guillaumehttp://www.postgresql.frhttp://dalibo.com