| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Old small commitfest items |
| Date: | 2018-07-05 01:54:05 |
| Message-ID: | CAH2-WzkT+ZJfTDzJ8f2c5Twq4h-JaUMOs3mp1jWOe+GM6UVrUA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 2, 2018 at 6:30 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Mon, Jul 02, 2018 at 10:30:11AM -0400, Andrew Dunstan wrote:
>> 528 1146 Fix the optimization to skip WAL-logging on table created in
>> same transaction
>
> This has been around for an astonishing amount of time... I don't
> recall all the details but rewriting most of the relation sync handling
> around heapam for a corner optimization is no fun. There is no way that
> we could go down to elimitate wal_level = minimal, so I am wondering if
> we should not silently ignore the optimization if possible instead of
> throwing an error. Perhaps logging a WARNING could make sense.
I don't know about any of that, but something has to give. How much
more time has to pass before we admit defeat? At a certain point, that
is the responsible thing to do.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-07-05 02:09:46 | Re: Invisible Indexes |
| Previous Message | Michael Paquier | 2018-07-05 01:50:04 | Re: PANIC during crash recovery of a recently promoted standby |