Category: Error Handling

Chen Hirsh switches platforms and hits a nasty surprise:

Anyway, I altered some views and stored procedures in the development environment, and after getting approval from the testers, tried to make the same changes in the production environment.

And then something strange occurred, I run an alter view command, and DBeaver told me the command run successfully. But when I ran a select from that view, it still had the old logic before the change. Right clicking the view, and getting its code, showed that it really hasn’t change.

I solved that mystery quickly, though I’ve also worked with auto-commit platforms (SQL Server) and platforms where the default commit is manual (Oracle, Postgres) and have been burned the same way in the past.

Robert Haas points the finger:

If an error message shows up in the PostgreSQL log, what program is malfunctioning? It’s easy to conclude that the answer is PostgreSQL, but that’s too simplistic.

For example, suppose these messages show up in my log file:

ERROR:  new row for relation “orders” violates check constraint “orders_d_check”
DETAIL:  Failing row contains (1975-03-16, 42).
STATEMENT:  insert into orders values (‘1975-03-16’, 42);

Error logs are always a “reading is fundamental” scenario and an exercise in applied logic. Sometimes the exercise is harder than others, such as the notorious “String or binary data would be truncated” in SQL Server or “Object reference not set to an instance of an object” in .NET. But in many cases, there’s enough information at least to get an idea of culprit and cause.