您如何處理一般數據庫中的“撤消”，特別是 PostgreSQL？
我有一個複雜的基於 PostgreSQL 的系統，我自己從頭開始製作。它包含大量（對我而言）無價的數據，我不想失去或損壞這些數據。
我總是對潛在的錯誤感到偏執，例如，可能
UPDATE是表中的每條記錄而不是特定的記錄，或其他類似的東西。基本上，我在做出它後不久就會注意到的任何錯誤。（更不用說那些我很久以後才注意到的……但這是一個不同的問題。）幸運的是，這還沒有真正發生，但這就是關鍵字：幸運。似乎它隨時可能發生，只要犯一個小錯誤，就一次。
如果真的發生了，我會首先恐慌。然後我會盡快關閉系統，這樣它就不再“活躍”並與 PostgreSQL 數據庫打交道，同時我會考慮下一步該做什麼。接下來，我可能會嘗試恢復最近的備份。我確實保留了這些。但是，不可避免地，我至少會失去大約一天的數據庫更新。恢復數據庫會非常可怕和乏味，我想盡可能少地這樣做。
我已經花費了無數個小時來嘗試實現更“強大”的備份機制，它會不斷對其進行小幅更新，但每次我嘗試實現這一目標時，我都會被文件和線上指南弄得不知所措和困惑以至於我可恥地回到我至少熟悉並且有效的“大約每天一次完全轉儲”方法的地步。
通常，我希望有某種方法可以在我犯了一個錯誤之後有一個“撤消”按鈕，它實際上可以將數據庫恢復到一分鐘前的狀態。如果合乎邏輯的話，甚至可以按表計算。
你會說一些關於“事務”的事情，但是，嗯……我不明白你是如何在“送出”更改之前註意到錯誤的。這就是主要問題。而且 PostgreSQL（我唯一使用並知道的數據庫）似乎沒有內置的“撤消”功能，也沒有在不擺弄備份的情況下恢復到最近狀態的能力。
有什麼重要的事情我錯過了嗎？
無法撤消 PostgreSQL 數據庫中的內容。
您確實需要製定備份策略。通過適當的線上文件系統備份，您可以將數據庫恢復到任何給定的時間點，因此您不會失去比使用撤消操作更多的數據。如果恢復備份對您來說似乎很可怕，這表明您沒有實施、測試和定期執行適當的恢復過程。這是你應該改進的。
當然，恢復備份是一件耗時的事情，並且可能會導致大量停機。如果您想要更快地從意外刪除的表中恢復，您可以使用具有流複製並
recovery_min_apply_delay啟用的備用伺服器。如果出現問題，您可以停止複制並讓備用伺服器趕上問題發生之前的某個時間點。但是，這僅適用於您很快注意到的問題，並且不能替代備份。
關閉系統…嘗試恢復最近的備份…我至少會失去大約一天的數據庫更新。
您的恢復點目標似乎是您希望最大程度地減少故障後的數據失去。這很好，但是您的一天一次的備份不符合該目標。
簡而言之，您需要更頻繁地進行備份，或者至少，確保您安全地歸檔 WAL 文件，以便您可以執行“一分鐘前”的時間點恢復。
恢復數據庫將是非常可怕和乏味的，我想盡可能少地這樣做。
絕對同意！如果我們能說服開發人員和高級管理人員這樣的人相信這種情況就好了。
您還應該在該列表中包含“破壞性”，因為您必須敲掉數據庫才能將其取回，並關閉所有使用它的應用程序！
我希望有某種方法可以有一個“撤消”按鈕，它實際上可以將數據庫恢復到一分鐘前的狀態……
更少的“按鈕”，更多的“工具包”。這稱為時間點恢復。
它仍然很可怕，而且必須這樣做仍然很乏味，但是你應該定期排練**這種事情，這樣當你必須“真正地”這樣做時，你就可以拿到一套久經考驗的程序，而不是對如何做事感到“恐慌”。
當您對整個表格進行吹噓時，沒有任何保護（在任何 DBMS 中）不受“哎呀”的影響*。*這就是為什麼沒有人應該在生產環境中執行裸 SQL - 永遠。
交易
你是絕對正確的。在這種情況下，這些對您沒有幫助。
他們只會確保所有損壞都已完成或不損壞。