| From: | Kirk Wolak <wolakk(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Subject: | PoC: Simplify recovery after dropping a table by LOGGING the restore LSN |
| Date: | 2024-11-08 03:46:54 |
| Message-ID: | CACLU5mSr+t+6K_Ww6z1fk_=jP=5-U0CEqMsHjii8uG_6UWQo-g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hackers,
The concept was driven by an all too common support request. A user
accidentally dropped the wrong table. (this could also be applied to
dropping a database, etc).
If we had the LSN before the drop, this would be easier. So we actually
log the LSN when the lock is required so that we have an accurate LSN and
the recovery is much simpler.
All we are doing is inserting a simple LOG message:
Acquired drop table lock on table <relname>. Restore at <LSN>
This is a rough patch, very simple and effective. We are looking for
feedback.
Comments are appreciated!
Should we ALSO consider this for:
- DROP DATABASE
- TRUNCATE TABLE
- DELETE (only when it is without a WHERE clause?)
- UPDATE (only when it is without a WHERE clause?)
Regards
Andrey, Nikolay, Kirk
| Attachment | Content-Type | Size |
|---|---|---|
| vPoC-0001-Simplify-recovery-after-dropping-a-table-by-giv.patch | application/x-patch | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-11-08 04:08:48 | Re: Parallel workers stats in pg_stat_database |
| Previous Message | Andrei Lepikhov | 2024-11-08 03:25:29 | Re: Incremental Sort Cost Estimation Instability |