Hi Tom, thanks for the response!
So the same user is able to connect using a non replication connection
using the same mtls certificate and pg_ident.conf map. So it seems like the
cert & map are working for this user.
hostssl all pgrepmgr_nonprod 100.0.0.0/8 cert map=pgrepmgr_nonprod_map
This ab
On 6/21/24 12:31, Shenavai, Manuel wrote:
Hi,
Thanks for the suggestions. I found the following details to our
autovacuum (see below). The related toast-table of my table shows some
logs related the vacuum. This toast seems to consume all the data
(27544451 pages * 8kb ≈ 210GB )
Those tuple
Here some more details related to the toast table:
{
"analyze_count": 0,
"autoanalyze_count": 0,
"autovacuum_count": 22,
"idx_scan": 1464881,
"idx_tup_fetch": 363681753,
"last_analyze": null,
"last_autoanalyze": null,
"last_autovacuum": "2024-06-19T17:45:02.564937+0
Hi,
Thanks for the suggestions. I found the following details to our autovacuum
(see below). The related toast-table of my table shows some logs related the
vacuum. This toast seems to consume all the data (27544451 pages * 8kb ≈ 210GB )
Any thoughts on this?
Best regards,
Manuel
Autovacuum d
Drew Zoellner writes:
> So the same user is able to connect using a non replication connection
> using the same mtls certificate and pg_ident.conf map. So it seems like the
> cert & map are working for this user.
Hmph. I tried to reproduce your problem, and it works for me: I can
create a replic
Drew Zoellner writes:
> Hi Postgres team, I’m receiving an issue matching pg_hba rules that I can’t
> seem to sort out. I am trying to use mtls certificate authentication for
> physical replication connections but keep receiving the following error…
> pg_receivewal: error: FATAL: no pg_hba.conf
"David G. Johnston" writes:
> On Fri, Jun 21, 2024 at 8:51 AM Tom Lane wrote:
>> The PG wire protocol specification [1] defines these fields thus:
>> If the field can be identified as a column of a specific
>> table, the object ID of the table; otherwise zero.
> s/can be identified as/
"David G. Johnston" writes:
> Based upon that unargued point the only bug here is in the documentation,
> leaving the reader to assume that some effort will be made to chain
> together a function returns clause to a physical table through that table's
> automatically-generated composite type.
Hmm
On Fri, Jun 21, 2024 at 8:51 AM Tom Lane wrote:
>
> The PG wire protocol specification [1] defines these fields thus:
>
> If the field can be identified as a column of a specific
> table, the object ID of the table; otherwise zero.
>
> If the field can be identified as a c
On Fri, Jun 21, 2024 at 8:41 AM Maxwell Dreytser <
maxwell.dreyt...@assistek.com> wrote:
> On Friday, June 21, 2024 11:28 AM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
> > In short, the system doesn't generate the information you need, where
> you need it, to tie these pieces toget
Maxwell Dreytser writes:
> I am working on a meta-programming use-case where I need to scrape some
> detailed information about the results of a function that "RETURNS TABLE
> (LIKE physical_table)", which ends up with prorettype =
> 'physical_table'::regtype.
> The problem is that for the quer
On Friday, June 21, 2024 11:28 AM David G. Johnston
wrote:
> Interesting, then I suppose it is semantics. There is no table involved -
> you are referencing the type of that name, not the table - so no TableOID.
> There is no guarantee the row you are holding came from a table - and I'd
> i
On Fri, Jun 21, 2024 at 8:04 AM Maxwell Dreytser <
maxwell.dreyt...@assistek.com> wrote:
> On Friday, June 21, 2024 10:48 AM David G. Johnston <
> david.g.johns...@gmail.com>wrote:
>
> >Yes, but the bug is yours. The definition you want is: RETURNS SETOF
> physical_table (not tested though)
> >W
On Friday, June 21, 2024 10:48 AM David G. Johnston
wrote:
>Yes, but the bug is yours. The definition you want is: RETURNS SETOF
>physical_table (not tested though)
>What you did was produce a one-column table whose column type is a composite
>(and whose name is like - what with case-folding
On Fri, Jun 21, 2024 at 7:42 AM Maxwell Dreytser <
maxwell.dreyt...@assistek.com> wrote:
> I am working on a meta-programming use-case where I need to scrape some
> detailed information about the results of a function that "RETURNS TABLE
> (LIKE physical_table)"
>
Yes, but the bug is yours. The
Hello,
I am working on a meta-programming use-case where I need to scrape some
detailed information about the results of a function that "RETURNS TABLE (LIKE
physical_table)", which ends up with prorettype = 'physical_table'::regtype.
The problem is that for the query "SELECT * FROM my_function(
Hello,
I get the install packages from this repository:
https://download.postgresql.org/pub/repos/yum/16/redhat/rhel-8.9-ppc64le/
Michal
Od: Adrian Klaver
Odesláno: čtvrtek 20. června 2024 17:03
Komu: Šika Michal ; pgsql-gene...@postgresql.org
Předmět: Re: Postg
Hi Postgres team, I’m receiving an issue matching pg_hba rules that I can’t
seem to sort out. I am trying to use mtls certificate authentication for
physical replication connections but keep receiving the following error…
pg_receivewal: error: FATAL: no pg_hba.conf entry for replication
connectio
18 matches
Mail list logo
