Pgadmin - Bug: Missing tuples in results written to file

Author

Bug: Missing tuples in results written to file

Erwin Brandstetter

2006-10-25, 8:27 am

Hi developers!

I am testing pgAdmin III Beta 3 (Oct 12 2006, re: 5475) on Windows XP
(German, latest patch level).

When I try to use the feature "Execute Query, write result to file" in
the SQL dialogue window, the result is wrong half of the time.
Tried it many times. Sometimes the results are correct, sometimes not.
Seems to happen at random. This is what happens:
Leading column names are there (as requested). Then some of the first
tuples are missing. Instead, the same number of lines with only column
separators (empty tuples?) is appended at the end.
pgAdmin invariably reports a success "Data export completed successfully".
The results of the same query are never wrong in the output pane.

Maybe a timing issue? (I am accessing a remote database server via SSH
tunnel & port forwarding)
I would classify randomly missing data as serious.

The problem also exists in the latest build that Dave mailed me (rev:
5475:5496)
v1.4.2 is not affected, though.

Regards
Erwin Brandstetter

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Dave Page

2006-10-25, 8:27 am

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of
> Erwin Brandstetter
> Sent: 17 October 2006 02:05
> To: pgadmin-support@postgresql.org
> Subject: [pgadmin-support] Bug: Missing tuples in results
> written to file
>
> Hi developers!
>
> I am testing pgAdmin III Beta 3 (Oct 12 2006, re: 5475) on Windows XP
> (German, latest patch level).
>
> When I try to use the feature "Execute Query, write result to
> file" in
> the SQL dialogue window, the result is wrong half of the time.
> Tried it many times. Sometimes the results are correct,
> sometimes not.
> Seems to happen at random. This is what happens:
> Leading column names are there (as requested). Then some of the first
> tuples are missing. Instead, the same number of lines with
> only column
> separators (empty tuples?) is appended at the end.
> pgAdmin invariably reports a success "Data export completed
> successfully".
> The results of the same query are never wrong in the output pane.

I cannot reproduce this here, so if I can ask a few questions...

1) What encoding is your database in?

2) What encoding are you saving the data in? Have you tried both
options? (Local and UTF-8)

3) Can you provide a sample table with which you can reproduce the
problem that I can test with?

BTW, I'm away for a few days from tomorrow so may not answer
immediately.

Thanks, Dave.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Erwin Brandstetter

2006-10-25, 8:27 am

dpage@vale-housing.co.uk wrote:
>
> I cannot reproduce this here, so if I can ask a few questions...
>
It does not happen every time. In my case, it happens in like 10-50% of
the time.
My best guess is a timing issue. Maybe my sepcial setup adds to it again
(SSH connection with port forwarding to remote server).
However, I have run tests with almost saturated network connection and
it didn't make a noteable difference.

BTW, a little more space for the filename in the export dialogue
wouldn't hurt.

> 1) What encoding is your database in?
>
utf-8

> 2) What encoding are you saving the data in? Have you tried both
> options? (Local and UTF-8)
>
Happens either way.
It seems to happen less often with utf-8 (being my db encoding). But
the difference was not overwhelmingly significant.

> 3) Can you provide a sample table with which you can reproduce the
> problem that I can test with?
>
Tried it with a number of different sources. tables, views (simple and
complex). It randomly happens with each of them.
When I chose a _new_ output file, then it happens almost every time;
when I change the query or any setting, it happens often; when repeating
the same export it happens rarely (but still randomely).

> BTW, I'm away for a few days from tomorrow so may not answer
> immediately.
>

Have a nice trip / vacation / whatever! :)

Regards
Erwin

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Dave Page

2006-10-25, 8:27 am

> -----Original Message-----
> From: Erwin Brandstetter & #91;mailto:brandstet
ter@falter.at]
> Sent: 17 October 2006 16:06
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Bug: Missing tuples in results
> written to file
>
>
> It does not happen every time. In my case, it happens in like
> 10-50% of
> the time.

I've run at least 20-30 tests now.

> My best guess is a timing issue. Maybe my sepcial setup adds
> to it again
> (SSH connection with port forwarding to remote server).
> However, I have run tests with almost saturated network
> connection and
> it didn't make a noteable difference.

If it were timing then it would affect the grid as well as it's the same
loop around the query thread used for both options before displaying or
saving the data.

> Tried it with a number of different sources. tables, views
> (simple and
> complex). It randomly happens with each of them.
> When I chose a _new_ output file, then it happens almost every time;
> when I change the query or any setting, it happens often;
> when repeating
> the same export it happens rarely (but still randomely).

With a new file, will it fail on a system table such as pg_class, or
just your data?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Erwin Brandstetter

2006-10-25, 8:27 am

dpage@vale-housing.co.uk wrote:
>
> On 17/10/06 17:06, "Erwin Brandstetter" <brandstetter@falter.at> wrote:
>
>
> dpage@vale-housing.co.uk wrote:
>
> Could reproduce it with select * from pg_catalog.pg_class;
> .. overwriting an existing output file.
> .. creating a new output file.
>
> OK, so that pretty much rules out a data issue. Is this with
> PostgreSQL 8.1.something?

Database is v. 8.1.4. Debian Sarge with PostgreSQL from backports.org

select version();
PostgreSQL 8.1.4 on i386-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5
(Debian 1:3.3.5-13)

postgres@dbneu:~/dev$ uname -a
Linux dbneu 2.6.8.erwin20061004 #1 SMP Wed Oct 4 22:44:51 CEST 2006 i686
GNU/Linux

Local OS: Windows XP. Connection via puTTY SSH with port forwarding

>
> Interestingly, there are never more than 6 tuples missing. With small
> result sets fewer sometimes, but never more.
> I have appended a sample output file and a screenshot of SQL dialogue
> window with export dialogue
>
>
> Hmm – does File -> Export get it right?

Nope. First try with select * from pg_catalog.pg_class limit 40; yielded
6 empty tuple at the bottom.

Regards
Erwin

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Sponsored Links