Re: [HACKERS] Adding hook in BufferSync for backup purposes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Adding hook in BufferSync for backup purposes
Date
Msg-id 15211.1502173676@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Adding hook in BufferSync for backup purposes  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: [HACKERS] Adding hook in BufferSync for backup purposes  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
Andrey Borodin <x4mmm@yandex-team.ru> writes:
> 7 авг. 2017 г., в 18:37, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: [HACKERS] Adding hook in BufferSync for backup purposes
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization