| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_receivewal - couple of improvements |
| Date: | 2022-02-07 02:53:41 |
| Message-ID: | YgCJtRFUAw4ke25m@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Feb 06, 2022 at 01:01:41PM +0530, Bharath Rupireddy wrote:
> With the start position as an option, users can just provide the LSN
> from which they want to stream the WAL, in the above case, it can be
> from primary's latest checkpoint LSN.
This still strikes me as a dangerous thing to have, prone to errors
with a bunch of base backups wasted if one does a mistake as it would
be very easy to cause holes in the WAL stored, until one has to
redeploy from a base backup in urgency. This kind of control is
provided by replication slots for new locations, and the current
archive location if anything is stored, so I would leave it at that.
On top of that, this kind of control is prone to more race conditions
with the backend, as a concurrent checkpoint could make the LSN you
are looking for irrelevant.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2022-02-07 03:02:58 | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
| Previous Message | Michael Paquier | 2022-02-07 02:40:12 | Re: GUC flags |