| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, hlinnaka <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: [HACKERS] WAL logging problem in 9.4.3? |
| Date: | 2019-11-25 20:58:14 |
| Message-ID: | CA+TgmoYzjPYCyU5o6XQ1B6JGhYM8MXGNGxhPpz=tFYdHEHGeGA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Nov 23, 2019 at 4:21 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> I noticed an additional defect:
>
> BEGIN;
> CREATE TABLE t (c) AS SELECT 1;
> CHECKPOINT; -- write and fsync the table's one page
> TRUNCATE t; -- no WAL
> COMMIT; -- no FPI, just the commit record
>
> If we crash after the COMMIT and before the next fsync or OS-elected sync of
> the table's file, the table will stay on disk with its pre-TRUNCATE content.
Shouldn't the TRUNCATE be triggering an fsync() to happen before
COMMIT is permitted to complete? You'd have the same problem if the
TRUNCATE were replaced by INSERT, unless fsync() happens in that case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2019-11-25 21:09:08 | Re: libpq sslpassword parameter and callback function |
| Previous Message | Alvaro Herrera | 2019-11-25 20:53:36 | Re: FETCH FIRST clause WITH TIES option |