On 03.09.2015 05:40, Michael Paquier wrote:
Ah, OK. I thought that you were referring to a protocol where caller
sends a single LSN from which it gets a differential backup that needs
to scan all the relation files of the source cluster to get the data
blocks with an LSN newer than the one sent,
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 09/04/2015 08:14 AM, Michael Paquier wrote:
> >Of course, that's not mandatory to fetch them. It is as well not worth
> >the complication to apply a filter to not fetch a portion of the
> >files, and I think that's why Heikki took the appr
On 09/04/2015 08:14 AM, Michael Paquier wrote:
On Thu, Sep 3, 2015 at 9:53 PM, Stephen Frost wrote:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote:
Not only, +clog, configuration files, etc.
Configuration files? Perhaps you could e
On Thu, Sep 3, 2015 at 9:53 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote:
>> >> Not only, +clog, configuration files, etc.
>> >
>> > Configuration files? Perhaps you could elaborate?
>>
>> Sure. Sorry for b
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote:
> >> Not only, +clog, configuration files, etc.
> >
> > Configuration files? Perhaps you could elaborate?
>
> Sure. Sorry for being unclear. It copies everything that is not a
> relation f
On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote:
> * Michael Paquier wrote:
>> 1) Use a differential backup to me, or the possibility to fetch a set
>> of data block diffs from a source node using an LSN and then re-apply
>> them on the target node. The major disadvantage of this approach is
>
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Sep 3, 2015 at 10:05 AM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera wrote:
> > The replication role already has read-only access to everything
> > (n
On Thu, Sep 3, 2015 at 10:05 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera wrote:
> The replication role already has read-only access to everything
> (nearly?) in the PGDATA directory. The specific issue in this ca
Micahel,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> As of now, file access functions in genfile.c can only be used by
> >> superusers. This proposal is to relax those functions so as
> >> replicat
On Thu, Sep 3, 2015 at 8:59 AM, Andres Freund wrote:
> On 2015-09-02 19:48:15 -0400, Tom Lane wrote:
>> Just on general principles, this seems like a pretty horrid idea.
>> To me replication privilege means the ability to transfer data out of
>> the master, not to cause arbitrary state changes on
On 2015-09-02 19:48:15 -0400, Tom Lane wrote:
> Just on general principles, this seems like a pretty horrid idea.
> To me replication privilege means the ability to transfer data out of
> the master, not to cause arbitrary state changes on the master.
It's not about the permission to trigger pg_re
Michael Paquier writes:
> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera
> wrote:
>> Michael Paquier wrote:
>>> The main argument for this change is that pg_rewind makes use of those
>>> functions, forcing users to use a superuser role when rewinding a
>>> node.
>> Can this piggyback on Stephen
On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> Hi all,
>>
>> As of now, file access functions in genfile.c can only be used by
>> superusers. This proposal is to relax those functions so as
>> replication users can use them as well. Here are the functions aimed
>
On Wed, Sep 2, 2015 at 11:32 PM, Fujii Masao wrote:
> Did you confirm that replication user can complete pg_rewind
> after this patch is applied?
Yes.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
Michael Paquier wrote:
> Hi all,
>
> As of now, file access functions in genfile.c can only be used by
> superusers. This proposal is to relax those functions so as
> replication users can use them as well. Here are the functions aimed
> by this patch:
> - pg_stat_file
> - pg_read_binary_file
> -
On Thu, Aug 27, 2015 at 10:50 AM, Michael Paquier
wrote:
> Hi all,
>
> As of now, file access functions in genfile.c can only be used by
> superusers. This proposal is to relax those functions so as
> replication users can use them as well. Here are the functions aimed
> by this patch:
> - pg_stat
Hi all,
As of now, file access functions in genfile.c can only be used by
superusers. This proposal is to relax those functions so as
replication users can use them as well. Here are the functions aimed
by this patch:
- pg_stat_file
- pg_read_binary_file
- pg_read_file
- pg_ls_dir
The main argumen
17 matches
Mail list logo
