| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Ashwin Agrawal <ashwinstar(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_basebackup --create-slot-if-not-exists? |
| Date: | 2022-09-22 01:12:04 |
| Message-ID: | 1314449.1663809124@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Wed, Sep 21, 2022 at 05:34:20PM -0700, David G. Johnston wrote:
>> What’s the use case for automating pg_basebackup with a named replication
>> slot created by the pg_basebackup command? Why can you not leverage a
>> temporary replication slot (i.e., omit —slot). ISTM the create option is
>> basically obsolete now.
> +1.
ISTM there'd also be some security concerns, ie what if there's a
pre-existing slot (created by a hostile user, perhaps) that has
properties different from what you expect? I realize that slot
creation is a pretty high-privilege operation, but it's not
superuser-only.
In any case I agree with the point that --create-slot seems
rather obsolete. If you are trying to resume in a previous
replication stream (which seems like the point of persistent
slots) then the slot had better already exist. If you are
satisfied with just starting replication from the current
instant, then a temp slot seems like what you want.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-09-22 01:25:11 | Re: pg_basebackup's --gzip switch misbehaves |
| Previous Message | Michael Paquier | 2022-09-22 00:52:57 | Re: make additional use of optimized linear search routines |