Postgresql with Npgsql "relation <tablename> does not exist." Only occurring on Win 7

Question

I'm running into a very strange bug when using Postgresql using the Npgsql (2.0.11 and 2.0.11.94) DLL in .NET 3.5.

I've created a program that will run these two queries (these are copied directly from the programs output):

INSERT INTO "db_events" VALUES ('2','1','2','1', to_timestamp('2012/08/27 10:22:43', 'YYYY/MM/DD HH24:MI:SS'),'2012', '8', '27', '10', '22', '43', '35' );

INSERT INTO "db_events_counts" VALUES ('1','2', '0', '1', '0', '1' );

This program will run perfectly fine on Windows XP x86 with both postgres 8.4.12 and 9.0.9, and will enter the data into the tables as it should.

However, when running the exact same program on Windows 7 with a database that has been set up in an identical way to the Windows XP data base, I run into the error:

ERROR: 42P01: relation "db_events" does not exist

I have read that this error is because postgres is forcing table names to lowercase, which is fine since they are already. Or that a table created with quotes has to be referenced with quotes, which is also fine since I am using quotes.

In the windows 7 database, if i copy and paste these two queries into pgadmin, they work fine, no errors, this leads me to believe it's something to do with the DLL?

What doesn't make sense is this program working bug free on my Windows XP system while throwing this error constantly on Windows 7.

I also try a simple delete statement:

DELETE FROM "db_events"; DELETE FROM "db_events_counts";

But that also ends in the same error.

Is there anything I am missing? Does Npgsql need to be compiled in the same windows environment as it's run in? or is there some subtle difference between windows 7 and windows XP with postgres that I am not getting.

Any help or information on the topic would be greatly appreciated.

---

Due to questions about the connection, here is what i have tried:

Server=localhost;Port=5433;User Id=databaseuser;Password=databaseuser_123;Database=db123;
Server=127.0.0.1;Port=5433;User Id=databaseuser;Password=databaseuser_123;Database=db123;
Server=10.223.132.123;Port=5433;User Id=databaseuser;Password=databaseuser_123;Database=db123;

The last being the local machines IP address.

---

Here is a short log of the program connecting and disconnecting from the server on Win 7:
// connecting

2012-08-27 11:26:00 EST ERROR:  relation "db_events" does not exist at character 13
2012-08-27 11:26:00 EST STATEMENT:  DELETE FROM "db_events"; DELETE FROM "db_events_counts";
2012-08-27 12:52:29 EST ERROR:  relation "db_events" does not exist at character 13
2012-08-27 12:52:29 EST STATEMENT:  INSERT INTO "db_events" VALUES ('114','1','2','1', to_timestamp('2012/08/27 12:52:29', 'YYYY/MM/DD HH24:MI:SS'),'2012', '8', '27', '12', '52', '29', '35' );

// disconnecting

2012-08-27 11:26:07 EST LOG:  could not receive data from client: No connection could be made because the target machine actively refused it.
2012-08-27 11:26:07 EST LOG:  unexpected EOF on client connection

Answer 1

The strange and erratic behaviour seen here, and discussion in the comments, suggests that the system catalogs (in the pg_catalog schema) may've been modified directly - perhaps an attempt to REVOKE some permissions.

That's not a good idea. The system catalogs should really only be modified by experts. That's one of the reasons only superuser accounts can modify them directly, and one of the many reasons you should not use superuser accounts in day-to-day operation.

Unless you know exactly what was done and can undo it, I'd recommend reverting to a working copy of the database like the one on your known-good XP machine. GRANTing access to public in pg_catalog sounds like it helped, but who knows what else has been done.

If this were my DB I'd take a pg_dump of each database and a pg_dumpall --globals-only and restore it to a spare DB to make sure it looked complete. I'd then stop Pg and re-initdb. That's a bit of a pain on Windows, though, so you might well be fine with just backing up the damaged database, DROPping it, re-creating it and restoring the data back into it.

Answer 2

Figured it out with the help of CraigRinger.

Even though the user I was logging in as was the owner of the database, he did not have permission to look into anything under the public schema.

This was discovered using:
select * from public.db_events

which, instead of throwing a relation not found error, threw an access is denied error.

After changing the user I was logging in as to a superuser and ticking all the check boxes under "role privileges", the relation not found error didn't occur any more.