使用Django時神祕的PostgreSQL日誌條目

我們正在優化Django支持的網站，因此我們正在開發PostgreSQL日誌 - 尋找可能以某種方式進行調整的長時間運行的查詢。使用Django時神祕的PostgreSQL日誌條目

我們偶然發現了某些類型的（有時非常長的）正在運行的查詢，我們無法找到其來源。他們看起來像這樣：

COPY public.my_table_name (id, field1, field2, field3, ...) TO stdout;

這些查詢的原因是什麼？他們很少見，但他們可以跑一分鐘！這是PostgreSQL內部的東西嗎？ Django本身觸發它們嗎？

這看起來像有人淋數據庫。 PG將你的表的內容發送到'stdout'，但是這個輸出可能被傳送到其他程序或某個網絡通道。你被黑客入侵了嗎？ – Patrick

黑客極不可能。一方面，這個系統的安全性非常嚴格，而另一方面，除了大約一百萬個電子郵件地址之外，幾乎沒有任何東西可以從黑客入侵這個數據庫中獲得。雖然電子郵件地址可能是一個有趣的目標，但是有可能比這個系統更容易獲得這種攻擊。另外，我們沒有看到任何暗示。至少一年前 - 這裏和那裏出現了這些條目。 –

我們定期創建數據庫轉儲並將它們存儲爲zip文件。那些是整個數據庫的完整轉儲。 pg_dump是否可能導致這些條目？使用pg_dump依次轉儲表（關於日誌文件）？ –

這些很可能是由pg_dump發佈的，正如您所說，您正在使用它來備份數據庫。

要確認這種情況，我建議您更改日誌記錄，以便顯示命令正在發出的連接的詳細信息，包括應用程序名稱。您可以在logging section of the manual中找到如何配置的詳細信息。

例如，您可以將log_line_prefix設置爲%a %r %p，其中包括應用程序名稱，遠程IP /端口和後端PID（我有時會覺得有用）。

2015-09-12 04:47:39 harmic

謝謝你支持我的懷疑。我可以在一週左右測試一下;目前，我已經接受了答案。如果這是導致日誌條目的其他內容，那麼我會讓你知道。 –

完美，就是這樣。我們只是測試並證實了它。 –

回答