Re: Adding hook in BufferSync for backup purposes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Андрей Бородин <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding hook in BufferSync for backup purposes
Date: 2017-08-07 13:37:30
Message-ID: 21401.1502113050@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I suppose your hook idea lets you implement the LSN fork in an
> extension, rather than having it be part of core. The idea of hooking
> onto BufferSync makes me uneasy, though -- like it's not the correct
> place to do it.

Yeah. Keep in mind that if the extension does anything at all that could
possibly throw an error, and if that error condition persists across
multiple tries, you will have broken the database completely: it will
be impossible to complete a checkpoint, and your WAL segment pool will
grow until it exhausts disk. So the idea of doing something that involves
unspecified extension behavior, especially possible interaction with
an external backup agent, right there is pretty terrifying.

Other problems with the proposed patch: it misses coverage of
BgBufferSync, and I don't like exposing an ad-hoc structure like
CkptTsStatus as part of an extension API. The algorithm used by
BufferSync to schedule buffer writes has changed multiple times
before and doubtless will again; if we're going to have a hook
here it should depend as little as possible on those details.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robins Tharakan 2017-08-07 13:43:37 Re: Patch: Add --no-comments to skip COMMENTs with pg_dump
Previous Message Peter Eisentraut 2017-08-07 13:22:20 Re: Subscription code improvements