Re: Adding hook in BufferSync for backup purposes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding hook in BufferSync for backup purposes
Date: 2017-08-08 06:27:56
Message-ID: 15211.1502173676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrey Borodin <x4mmm(at)yandex-team(dot)ru> writes:
> 7 авг. 2017 г., в 18:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал(а):
>> 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.

> I think that API for extensions should tend to protect developer from
> breaking everything, but may allow it with precaution warnings in docs
> and comments. Please let me know if this assumption is incorrect.

My point is not to claim that we mustn't put a hook there. It's that what
such a hook could safely do is tightly constrained, and you've not offered
clear evidence that there's something useful to be done within those
constraints. Alvaro seems to think that the result might be better
reached by hooking in at other places, and my gut reaction is similar.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-08-08 06:43:48 Re: pgbench: Skipping the creating primary keys after initialization
Previous Message Andrey Borodin 2017-08-08 05:18:59 Re: Adding hook in BufferSync for backup purposes