On Sat, Jul 30, 2022 at 2:54 AM mahendrakar s
wrote:
> There might be security concerns if the backup started by one user can be
> stopped by another user.
> This is because the user who stops the backup will get the backup_label or
> table space map file contents of other user.
> Isn't this a c
On Sat, Jul 30, 2022 at 12:23 PM mahendrakar s
wrote:
>
> On Mon, 25 Jul 2022 at 12:00, Bharath Rupireddy
> wrote:
>>
>> On Mon, Jul 25, 2022 at 10:03 AM mahendrakar s
>> wrote:
>> >
>> > Hi Bharath,
>>
>> Thanks Mahendrakar for taking a look at the design.
>>
>> > "Typically, step (3) takes a
Hi Bharath,
There might be security concerns if the backup started by one user can be
stopped by another user.
This is because the user who stops the backup will get the backup_label or
table space map file contents of other user.
Isn't this a concern for non-exclusive backup?
I think there shoul
On Mon, Jul 25, 2022 at 10:03 AM mahendrakar s
wrote:
>
> Hi Bharath,
Thanks Mahendrakar for taking a look at the design.
> "Typically, step (3) takes a good amount of time in production
> environments with terabytes or petabytes scale of data and keeping the
> session alive from step (1) to (4)
Hi Bharath,
*"Typically, step (3) takes a good amount of time in productionenvironments
with terabytes or petabytes scale of data and keeping thesession alive from
step (1) to (4) has overhead and it wastes theresources. And the session
can get closed for various reasons - idlein session tim
Hi,
Right now, the session that starts the backup with pg_backup_start()
has to end it with pg_backup_stop() which returns the backup_label and
tablespace_map contents (commit 39969e2a1). If the backups were to be
taken using custom disk snapshot tools on production servers,
following are the high
