7

.NET 3.5でNpgsql（2.0.11および2.0.11.94）DLLを使用してPostgresqlを使用すると、非常に奇妙なバグが発生します。

これらの2つのクエリを実行するプログラムを作成しました（これらはプログラム出力から直接コピーされます）。

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' );

このプログラムは、postgres8.4.12と9.0.9の両方を備えたWindowsXP x86で完全に正常に実行され、必要に応じてデータをテーブルに入力します。

ただし、WindowsXPデータベースと同じ方法でセットアップされたデータベースを使用してWindows7でまったく同じプログラムを実行すると、次のエラーが発生します。

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

このエラーは、postgresがテーブル名を小文字に強制しているためであると読みました。これはすでに存在しているので問題ありません。または、引用符で作成されたテーブルは引用符で参照する必要があります。これは、引用符を使用しているので問題ありません。

Windows 7データベースでは、これら2つのクエリをコピーしてpgadminに貼り付けると、エラーなしで正常に機能します。これにより、DLLと関係があると思いますか？

意味をなさないのは、このプログラムがWindows XPシステムでバグなしで動作し、Windows7ではこのエラーが絶えずスローされることです。

簡単なdeleteステートメントも試してみます。

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

しかし、それも同じエラーで終わります。

足りないものはありますか？Npgsqlは、実行されているのと同じWindows環境でコンパイルする必要がありますか？または、私が得ていないpostgresを使用したWindows7とWindowsXPの間に微妙な違いがありますか？

このトピックに関するヘルプや情報をいただければ幸いです。

接続に関する質問のため、これが私が試したことです：

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;

最後はローカルマシンのIPアドレスです。

これは、Win7でサーバーに接続およびサーバーから切断するプログラムの短いログです
。//接続

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' );

//切断

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
4

3 に答える 3

6

ここで見られる奇妙で不安定な動作、およびコメントでの議論は、（pg_catalogスキーマ内の）システムカタログが直接変更された可能性があることを示唆しています-おそらくREVOKEいくつかの権限の試みです。

それは良い考えではありません。システムカタログは、実際には専門家のみが変更する必要があります。これは、スーパーユーザーアカウントのみが直接変更できる理由の1つであり、日常業務でスーパーユーザーアカウントを使用してはならない多くの理由の1つです。

何が行われたかを正確に理解していて、それを元に戻すことができない場合は、正常なXPマシンにあるようなデータベースの作業コピーに戻すことをお勧めします。inへのGRANTアクセスは役に立ったように聞こえますが、他に何が行われたかは誰にもわかりません。publicpg_catalog

これが私のDBである場合pg_dump、各データベースのを取得し、pg_dumpall --globals-onlyそれを予備のDBに復元して、完全に見えることを確認します。次に、Pgを停止してinitdbを再起動します。ただし、これはWindowsでは少し面倒なので、破損したデータベースをバックアップし、DROPpingを実行し、再作成してデータを復元するだけで問題ない場合があります。

于 2012-08-27T05:55:32.933 に答える
1

CraigRingerの助けを借りてそれを理解しました。

私がログインしていたユーザーはデータベースの所有者でしたが、パブリックスキーマの下で何かを調べる権限がありませんでした。

これは、以下を使用して発見されました。
select * from public.db_events

relation not foundこれは、エラーをスローする代わりに、エラーをスローしましたaccess is denied。

ログインしていたユーザーを変更し、superuser「ロール権限」の下にあるすべてのチェックボックスをオンにした後、relation not foundエラーは発生しなくなりました。

于 2012-08-27T03:22:44.107 に答える
0

PostgreSQLはすべての識別子を小文字に折ります。これはPostgreSQLの動作であり、Npgsqlとは何の関係もありません。Npgsqlは、記述したとおりにSQLを渡すだけです。すべて小文字のテーブル名に切り替えることができます。その場合、引用符は不要になります。

于 2019-05-20T23:26:35.900 に答える