> 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
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
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
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
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
>
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
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
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
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
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
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
14 matches
Mail list logo
