Jelte Fennema-Nio writes:
> The new documentation looks good to me, but I think the same change
> should be applied to the documentation for pg_receivewal.
Good idea, will do.
regards, tom lane
On Mon, 4 Nov 2024 at 19:57, Tom Lane wrote:
> I'm intending to go with the attached.
The new documentation looks good to me, but I think the same change
should be applied to the documentation for pg_receivewal.
Daniel Gustafsson writes:
> +1 on your patch, reading through I can't see anything it misses. Maybe a
> comment above the change with a note on why dbname is tested for NULL there
> would be good?
I thought Jelte's suggestion of clarifying the first comment was good:
-/* pg_recvlogical uses
> On 4 Nov 2024, at 18:14, Tom Lane wrote:
> perhaps under the illusion that dbname and connection_string can't
> both be NULL.
Ugh, yes, I failed to capture that nuance.
> I think the attached will fix it, but I wonder if there are edge
> cases I'm not thinking of.
+1 on your patch, reading t
On Mon, 4 Nov 2024 at 18:14, Tom Lane wrote:
> perhaps under the illusion that dbname and connection_string can't
> both be NULL.
Yeah, I'm pretty sure I didn't realise that was an option. I think I
probably misinterpreted this comment (might be nice to clarify there
that both being NULL is also
Daniel Gustafsson writes:
> On 18 Sep 2023, at 14:11, Daniel Gustafsson wrote:
>> Unless something sticks out in a second pass over it I will go ahead and
>> apply
>> it.
> And applied, closing the CF entry.
I believe this patch (commit cca97ce6a) is the cause of bug #18685,
which reports that
> On 18 Sep 2023, at 14:11, Daniel Gustafsson wrote:
> Unless something sticks out in a second pass over it I will go ahead and apply
> it.
And applied, closing the CF entry.
--
Daniel Gustafsson
> On 31 Aug 2023, at 11:01, Jelte Fennema wrote:
> Attached is a new version with some slightly updated wording in the docs
I had a look at this Ready for Committer entry in the CF and it seems to strike
a balance between useful in certain cases and non-intrusive in others.
Unless something sti
Attached is a new version with some slightly updated wording in the docs
v4-0001-Allow-specifying-a-dbname-in-pg_basebackup-connec.patch
Description: Binary data
On 30.08.23 14:11, Jelte Fennema wrote:
Oops it indeed seemed like I made an unintended change when handling
database names that did not exist in pgbouncer.conf when you used
auth_type=hba. I pushed a fix for that now to the replication-support
branch. Feel free to try again. But as you said it's
On Wed, 30 Aug 2023 at 01:01, Jim Jones wrote:
> However, pgbouncer closes with a segmentation fault, so I couldn't test the
> result of pg_basebackup itself - but I guess it isn't the issue here.
Oops it indeed seemed like I made an unintended change when handling
database names that did not ex
Hi Jelte
On 29.08.23 15:55, Jelte Fennema wrote:
Thanks for the review. I've updated the documentation to make it
clearer (using some of your suggestions but also some others)
This patch applies and builds cleanly, and the documentation is very clear.
I tested it using the 'replication-suppor
On Mon, 28 Aug 2023 at 23:50, Tristen Raab wrote:
> I've reviewed your patch and it applies and builds without error. When
> testing this patch I was slightly confused as to what its purpose was, after
> testing it I now understand. Initially, I thought this was a change to add
> database-level
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Hello,
I've reviewed your patch and it applies and builds without er
On Wed, 5 Jul 2023 at 20:09, Thom Brown wrote:
> Okay, understood. In that case, please remember to write changes to
> the pg_basebackup docs page explaining how the dbname value is ignored
I updated the wording in the docs for pg_basebackup and pg_receivewal.
They now clarify that Postgres its
On Wed, 5 Jul 2023 at 16:50, Jelte Fennema wrote:
>
> On Wed, 5 Jul 2023 at 16:01, Euler Taveira wrote:
> > One of the PgBouncer's missions is to be a transparent proxy.
> >
> > Sometimes you cannot reach out the database directly due to a security
> > policy.
>
> Indeed the transparent proxy us
On Wed, 5 Jul 2023 at 16:01, Euler Taveira wrote:
> One of the PgBouncer's missions is to be a transparent proxy.
>
> Sometimes you cannot reach out the database directly due to a security policy.
Indeed the transparent proxy use case is where replication through
pgbouncer makes sense. There's qu
On Wed, Jul 5, 2023, at 9:43 AM, Thom Brown wrote:
> I guess my immediate question is, should backups be taken through
> PgBouncer? It seems beyond PgBouncer's remit.
One of the PgBouncer's missions is to be a transparent proxy.
Sometimes you cannot reach out the database directly due to a secur
On Mon, 3 Jul 2023 at 13:23, Jelte Fennema wrote:
>
> Normally it doesn't really matter which dbname is used in the connection
> string that pg_basebackup and other physical replication CLI tools use.
> The reason being, that physical replication does not work at the
> database level, but instead
Normally it doesn't really matter which dbname is used in the connection
string that pg_basebackup and other physical replication CLI tools use.
The reason being, that physical replication does not work at the
database level, but instead at the server level. So you will always get
the data for all
20 matches
Mail list logo
