On Thu, Feb 3, 2022 at 12:26 PM Andrew Dunstan wrote:
> I've fixed this using the auth_extra method, which avoids a reload.
Thank you much.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 2/2/22 17:52, Tom Lane wrote:
> I wrote:
>> The Windows animals don't like this:
>> pg_basebackup: error: connection to server at "127.0.0.1", port 59539
>> failed: FATAL: SSPI authentication failed for user "backupuser"
>> Not sure whether we have a standard method to get around that.
>
Tom Lane writes:
> I wrote:
>> The Windows animals don't like this:
>> pg_basebackup: error: connection to server at "127.0.0.1", port 59539
>> failed: FATAL: SSPI authentication failed for user "backupuser"
>
>> Not sure whether we have a standard method to get around that.
>
> Ah, right, we
I wrote:
> The Windows animals don't like this:
> pg_basebackup: error: connection to server at "127.0.0.1", port 59539 failed:
> FATAL: SSPI authentication failed for user "backupuser"
> Not sure whether we have a standard method to get around that.
Ah, right, we do. Looks like adding
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Here's a follow-on patch that adds a test for non-superuser server-side
> basebackup, which crashes without your patch and passes with it.
The Windows animals don't like this:
# Running: pg_basebackup --no-sync -cfast -U backupuser --target
Daniel Gustafsson writes:
>> On 2 Feb 2022, at 19:58, Robert Haas wrote:
>> And one thing that concretely stinks about is the progress reporting
>> you get while the tests are running:
>>
>> t/010_pg_basebackup.pl ... 142/?
>>
>> That's definitely less informative than 142/330 or whatever.
>
> On 2 Feb 2022, at 19:58, Robert Haas wrote:
>
> On Wed, Feb 2, 2022 at 1:50 PM Robert Haas wrote:
>> On Wed, Feb 2, 2022 at 1:46 PM Tom Lane wrote:
>>> Well, if someone wants to step up and provide a patch that changes 'em
>>> all at once, that'd be great. But we've discussed this before
On Wed, Feb 2, 2022 at 1:50 PM Robert Haas wrote:
> On Wed, Feb 2, 2022 at 1:46 PM Tom Lane wrote:
> > Well, if someone wants to step up and provide a patch that changes 'em
> > all at once, that'd be great. But we've discussed this before and
> > nothing's happened.
>
> I mean, I don't
On Wed, Feb 2, 2022 at 1:46 PM Tom Lane wrote:
> Well, if someone wants to step up and provide a patch that changes 'em
> all at once, that'd be great. But we've discussed this before and
> nothing's happened.
I mean, I don't understand why it's even better. And I would go so far
as to say that
Robert Haas writes:
> On Wed, Feb 2, 2022 at 12:55 PM Tom Lane wrote:
>> Actually, it seemed that the consensus in the nearby thread [1]
>> was to start doing exactly that, rather than try to convert them
>> all in one big push.
> Urk. Well, OK then.
> Such an approach seems to me to have
On Wed, Feb 2, 2022 at 12:55 PM Tom Lane wrote:
> Robert Haas writes:
> > This seems like a good idea, but I'm not going to slip a change from
> > an exact test count to done_testing() into a commit on some other
> > topic...
>
> Actually, it seemed that the consensus in the nearby thread [1]
>
Robert Haas writes:
> This seems like a good idea, but I'm not going to slip a change from
> an exact test count to done_testing() into a commit on some other
> topic...
Actually, it seemed that the consensus in the nearby thread [1]
was to start doing exactly that, rather than try to convert
On Wed, Feb 2, 2022 at 10:42 AM Dagfinn Ilmari Mannsåker
wrote:
> Here's a follow-on patch that adds a test for non-superuser server-side
> basebackup, which crashes without your patch and passes with it.
This seems like a good idea, but I'm not going to slip a change from
an exact test count to
Robert Haas writes:
> On Fri, Jan 28, 2022 at 12:35 PM Dagfinn Ilmari Mannsåker
> wrote:
>> On Fri, 28 Jan 2022, at 17:33, Robert Haas wrote:
>> > LGTM. Committed.
>>
>> Thanks!
>
> It appears that neither of us actually tested that this works.
Oops!
> For me, it works when I test as a
On Fri, Jan 28, 2022 at 12:35 PM Dagfinn Ilmari Mannsåker
wrote:
> On Fri, 28 Jan 2022, at 17:33, Robert Haas wrote:
> > LGTM. Committed.
>
> Thanks!
It appears that neither of us actually tested that this works. For me,
it works when I test as a superuser, but if I test as a non-superuser
with
On Fri, 28 Jan 2022, at 17:33, Robert Haas wrote:
> LGTM. Committed.
Thanks!
- ilmari
On Fri, Jan 28, 2022 at 12:16 PM Dagfinn Ilmari Mannsåker
wrote:
> Or now. Patch attached.
LGTM. Committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
Dagfinn Ilmari Mannsåker writes:
> Robert Haas writes:
>
>> On Fri, Jan 28, 2022 at 5:58 AM Dagfinn Ilmari Mannsåker
>> wrote:
>>> I just noticed that the new server-side base backup feature requires
>>> superuser privileges (which is only documented in the pg_basebackup
>>> manual, not in the
Robert Haas writes:
> On Fri, Jan 28, 2022 at 5:58 AM Dagfinn Ilmari Mannsåker
> wrote:
>> I just noticed that the new server-side base backup feature requires
>> superuser privileges (which is only documented in the pg_basebackup
>> manual, not in the streaming replication protocol
On Fri, Jan 28, 2022 at 5:58 AM Dagfinn Ilmari Mannsåker
wrote:
> I just noticed that the new server-side base backup feature requires
> superuser privileges (which is only documented in the pg_basebackup
> manual, not in the streaming replication protocol specification).
>
> Isn't this the kind
Hi Hackers,
I just noticed that the new server-side base backup feature requires
superuser privileges (which is only documented in the pg_basebackup
manual, not in the streaming replication protocol specification).
Isn't this the kind of thing the pg_write_server_files role was created
for, so
21 matches
Mail list logo
