On 29 October 2010 21:52, Rob Richardson <Rob.Richardson@xxxxxxxxxxx> wrote: > A customer was reviewing the database that supports the application we have > provided. One of the tables is very simple, but has over 16 million > records. Here is the table's definition: > > CREATE TABLE feedback > ( > charge integer, > elapsed_time integer, -- number of elapsed minutes since data began > recording > tag_type character varying(24), -- Description of tag being recorded > tag_value real, -- value of tag being recorded > status smallint, -- PLC Status, recorded with Control PV only > stack integer, -- Not used > heating smallint DEFAULT 0, -- 1 for heating, 0 for cooling > cooling smallint DEFAULT 0 -- not used > ) > > As you see, there is no primary key. There is a single index, as follows: > > CREATE INDEX feedback_charge_idx > ON feedback > USING btree > (charge); > In PGAdmin, the customer selected this table and clicked the grid on the > toolbar, asking for all of the records in the table. After twenty minutes, > a message box appeared saying that an unhandled exception had happened. > There was no explanation of what the exception was. The database log does > not contain any information about it. The PGAdmin display did show a number > of records, leading me to believe that the error happened in PGAdmin rather > than anywhere in PostGres. > > Can anyone explain what is happening? Does WxWidgets/PgAdmin provide an overload of global operator new() that follows the pre-standard C++ behaviour of returning a null ptr, ala malloc()? C++ application frameworks that eschew exceptions often do. This sounds like an unhandled std::bad_alloc exception. Why don't we have some hard limit on the number of rows viewable in a table? Would that really be so terrible? -- Regards, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
