Crash when selecting table

[dxtr0dsgnz]

After I'm connected to my Postgres 9.5 database, I select tables in the sidebar. The selection of one certain table leads to application crash.

MacOS 10.11.5, PSequel Version 1 (1.4.4)

-- Table: public.channel -- DROP TABLE public.channel; CREATE TABLE public.channel ( channel_id numeric(19,0) NOT NULL, name character varying(40) NOT NULL, type character varying(40), image bytea, CONSTRAINT channel_pkey PRIMARY KEY (channel_id) ) WITH ( OIDS=FALSE ); ALTER TABLE public.channel OWNER TO ddm; -- Index: public.channel_idx1 -- DROP INDEX public.channel_idx1; CREATE UNIQUE INDEX channel_idx1 ON public.channel USING btree (name COLLATE pg_catalog."default");

PSequel_2016-06-10-102703_tollwuts-iMac.crash.txt

[psequel]

I created a table using your query. PSequel v1.4.4 works fine for that table. From your crash logs, looks like your server reported a wrong datatype for a column. If possible, could you allow me to connect to your database? Or you could try to see if v1.5.0 works for you.

[dxtr0dsgnz]

I'm sorry, the database is located behind some firewalls of my company; so it's not possible. It crashes with 1.5.0 either. This is the content of the table, exported by Postico app:

"channel_id","name","type","image" 4,"Test","FestesFeld1", 6,"Email-SH","128436", 12,"WebAd-SH","96325", 19,"Channel1-JR-EDIT","Channel-Field1-EDIT",

If the crash is still not reproducible for you and you think the problem is caused by my data, you may close this issue. It's not critical for me as I'm working with several other database tools either ( e.g. Postico and pgAdmin; they don't crash when accessing the table ).

[psequel]

What if you create a table with same structure and data locally on your Mac? I wonder if the issue is related to your PostgreSQL server or your local machine. If another tool can load the table, it's definitely a bug of PSequel.

[dxtr0dsgnz]

• When I install pSequel on another Mac and try so select the table, it crashes either.
• When I create a new table "channel2" using the same instructions and select it afterwards, it doesn't crash.

CREATE TABLE channel2 ( channel_id NUMERIC(19, 0) NOT NULL PRIMARY KEY, name VARCHAR(40) NOT NULL, category VARCHAR(40) NOT NULL, image BYTEA
);
CREATE UNIQUE INDEX channel2_idx1 ON channel2 ( name );

• When I insert values into "channel2" using the following SQL and select the table afterwards, it crashes.

INSERT INTO channel2 VALUES (4,'Test','FestesFeld1','');

• When I insert a new table "channel3" using the same instructions, but without creating the last column image bytea, and insert values afterwards, it doesn't crash when selecting the table.

So it might be caused by the column "image" of type "bytea" which has no values in all cases.

I currently don't have a local postgres database to test this.

[psequel]

Thanks a lot for digging into this! I tried the steps you described but still cannot reproduce the crash. I also tried

INSERT INTO channel VALUES
(5,'Test2','FestesFeld1',NULL);

and PSequel is able to distinguish non-NULL values (including an empty string in your case) and NULL value.

Not being able to reproduce the crash on my side makes it very hard to figure out what's going on. Sorry about that.

[AntonTrapp]

Maybe it's the same error as I am getting it now. Added a binary column to a table. Selecting it -> crash. No problem with that table before!

template_file bytea, -- the new column

version is 1.5.0, pg 9.5.2, OS 10.11.5 - can dump the DB, it's a very simple development DB if it helps!

[psequel]

@AntonTrapp could you send the dump file to support(at)psequel(dot)com (or create a gist if you don't mind sharing it publicly)? Want to see if I can reproduce the crash on my machine.

[AntonTrapp]

Crash happens even if I just run a sql query (select * from ...). Dump is on the way, table is protocol_report_templates, the content is a BASE64 encoded .odt text file.

[dxtr0dsgnz]

Crash happens even if I just run a sql query (select * from ...).

I can reproduce this.

[psequel]

@AntonTrapp your dump file works fine as well 😕

[AntonTrapp]

dump.txt

OS X 10.11.5 / psql (PostgreSQL) 9.5.2? Postgres installed with homebrew? hstore extension added to psql, but this should not do any harm? Happens on all 3 of my Macs. Want to debug remote with Teamviewer, ...?

[psequel]

@AntonTrapp I'm also running PostgreSQL 9.5.2 from homebrew. Also have hstore extension added (actually your dump creates hstore extension too). I don't think Teamviewer is useful if I cannot attach my debugger while connecting to your database.

[AntonTrapp]

You start xcode (or whatever you need on my machine and work on it as if it is yours). Why shouldn't you be able to connect local to my database from my computer? ;)

[psequel]

@AntonTrapp Honestly I don't want to ship the source code to your computer. If you have a public IP address and expose the PostgreSQL port, I can connect to your database from my computer.

[AntonTrapp]

No problem, just wanted to help. Switched back to pgAdmin - ugly, a hell to operate but working. Tried to delete a timestamp in another table - not working with psequel because an empty timestamp has not the right format for a timestamp, ... will have a look at psequel again in the future, looks promising.

[psequel]

@AntonTrapp thanks for your help anyway! For the timestamp issue, if "an empty timestamp" means NULL, you should select the "NULL" radio button instead of typing an empty string in the timestamp field. PSequel distinguishes an empty string vs. NULL.

[rdp]

I think I just ran into this issue as well, how to repro (1.5.0)

CREATE TABLE eat_digital_work_test
(
  ctr_data bytea
)
WITH (
  OIDS=FALSE
);
insert into eat_digital_work_test values(decode('DEADBEEF', 'hex'))

then try and see it in psequel. crash debug log: https://gist.github.com/rdp/1726b8730db29b545355f25eb05ba00f

Let me know if I can be of further assistance.

[rdp]

That's odd, on a new computer (El Capitan instead of Yosemite, possibly related?) it seems to work fine [?]

[trbtm]

Same issue here.

I'm using Postgres 9.6.1.0 (Server), OS X 10.11.6 and PSequel 1.5.1.

The statement "SELECT * FROM staff;" works fine with PGAdmin4 but PSequel crashes. I also can't select the table "staff" in the tables section without PSequel crashing. I attached the database and some crash_reports. dvdrental.tar.zip crash_report_table_section.txt crash_resport_select_statement.txt

[dd-a]

Same crash for me.
I just duplicated a table but changed a column from character varying(255) to bytea, then inserted into the new one all the records from the old one. No problem with the other one, but psequel crashes whenever I try to view the table content (also with a SELECT * FROM table). No problem with pgadmin 4.

PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit, Psequel 1.5.3, Mac OS Sierra 10.12.5 .