Getting error while running the pg_basebackup through PGBOUNCER #382
Labels
feature
discussion about functionality that does not exist yet
Comments
|
Why you want use connection pool for replication protocol? |
|
The ‘pg_basebackup’ makes a replication protocol connection (just like a
replication client) to the PostgreSQL server indirectly.
We are using pgbouncer for connection pool mechanisam only.
…On Mon, 8 Apr 2019 at 19:31, Melkij ***@***.***> wrote:
Why you want use connection pool for replication protocol?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#382 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Afs31x2SD_NOS-V9FoMLH9hVN-_jTcSkks5ve0uugaJpZM4ciQIe>
.
--
Regards,
Raghavendra Rao J S V
Mobile- 8861161425
|
|
What is the value of your |
|
Replication connections through PgBouncer are not supported. I'm not sure if there is any sense in supporting that. |
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jun 30, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jun 30, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
|
Re-opening for tracking, since I created a #876 that fixes this. My main usecase for allowing replication connections is giving users only a single connection string, that works for everything. |
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jun 30, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jun 30, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 3, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added
feature
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 11, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 19, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy,
i.e. the client does normally not even need to know that PgBouncer is in
the middle. This allows things like load balancing and failovers without
the client needing to know about this at all. But as soon as replication
connections are needed, this was not possible anymore, because PgBouncer
would reject those instead of proxying them to the right server.
This PR fixes that by also proxying replication connections. They are
handled pretty differently from normal connections though. A client and
server replication connection will form a strong pair, as soon as one is
closed the other is closed too. So, there's no caching of the server
replication connections, like is done for regular connections. This
seems like a good tradeoff for ease of implementation, because
TODO:
- [ ] Implement hba support for replication database. The current
version allows PgBouncer allows any user that can authenticate to
also open a physical replication connection. Normally Postgres
requires a replication database entry in the hba file for this.
Obviously this is still checked by postgres, but if a hardcoded user
is used for the connection this might still be problematic.
- [ ] tests with `pg_recvlogical`, `pg_receivewal` and `pg_basebackup`
- [ ] basic tests over SSL
Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jul 19, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Aug 16, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Aug 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Aug 31, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Sep 1, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Sep 1, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Sep 5, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. This seems like a good tradeoff for ease of implementation, because Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Sep 6, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Sep 6, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Sep 6, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Oct 5, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Oct 5, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
eulerto
pushed a commit
to JelteF/pgbouncer
that referenced
this issue
Oct 18, 2023
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
There is, eg if you are running your databases inside a k8s cluster and expose them using pg-bouncer. |
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Jan 29, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Feb 23, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Mar 4, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
Mar 6, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
May 6, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
May 6, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
May 6, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
to JelteF/pgbouncer
that referenced
this issue
May 6, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes pgbouncer#382
JelteF
added a commit
that referenced
this issue
May 6, 2024
In session pooling mode PgBouncer is pretty much a transparent proxy, i.e. the client does normally not even need to know that PgBouncer is in the middle. This allows things like load balancing and failovers without the client needing to know about this at all. But as soon as replication connections are needed, this was not possible anymore, because PgBouncer would reject those instead of proxying them to the right server. This PR fixes that by also proxying replication connections. They are handled pretty differently from normal connections though. A client and server replication connection will form a strong pair, as soon as one is closed the other is closed too. So, there's no caching of the server replication connections, like is done for regular connections. Reusing replication connections comes with a ton of gotchas. Postgres will throw errors in many cases when trying to do so. So simply not doing it seems like a good tradeoff for ease of implementation. Especially because replication connections are pretty much always very long lived. So re-using them gains pretty much no performance benefits. Fixes #382 Depends on #945
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are using PGBOUNCER(connection pool mechanisam). PGBOUNCER uses port 5433.
Postgres database port number is 6433. By using port 5433 PGBOUNCER is connecting to postgres port 6433 database.
Now PGBOUNCER is establishing the connections properly but when I try to run the pg_basebackup through port 5433(PGBOUNCER port) we are receiving below error. Please guide me.
/opt/postgres/9.2/bin/pg_basebackup -p 5433 -U postgres -P -v -x --format=tar --gzip --compress=1 --pgdata=- -D /opt/rao
pg_basebackup: could not connect to server: ERROR: Unsupported startup parameter: replication
The text was updated successfully, but these errors were encountered: