Re: Online enabling of checksums

Magnus Hagander <magnus@hagander.net>

From: Magnus Hagander <magnus@hagander.net>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2018-02-22T20:16:02Z
Lists: pgsql-hackers
On Thu, Feb 22, 2018 at 8:52 PM, Andres Freund <andres@anarazel.de> wrote:

>
>
> On February 22, 2018 11:44:17 AM PST, Magnus Hagander <magnus@hagander.net>
> wrote:
> >On Thu, Feb 22, 2018 at 8:41 PM, Andres Freund <andres@anarazel.de>
> >wrote:
> >In this particular case that would at least phase 1 simplify it because
> >we'd only need one process instead of worker/launcher. However, if we'd
> >ever want to parallellize it -- or any other process of the style, like
> >autovacuum -- you'd still need a launcher+worker combo. So making that
> >particular scenario simpler might be worthwhile on it's own.
>
> Why is that needed? You can just start two bgworkers and process a list of
> items stored in shared memory. Or even just check, I assume there'd be a
> catalog flag somewhere, whether a database / table / object of granularity
> has already been processed and use locking to prevent concurrent access.
>

You could do that, but then you've moving the complexity to managing that
list in shared memory instead. I'm not  sure that's any easier... And
certainly adding a catalog flag for a usecase like this one is not making
it easier.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Commits

  1. Online enabling and disabling of data checksums

  2. Deactive flapping checksum isolation tests.

  3. Add support for coordinating record typmods among parallel workers.