On Wed, 2025-07-09 at 17:37 +0100, Mircea Cadariu wrote:
> Just to let you know that I have added a review through the commitfest app.
Thanks!
The patch is still in state "needs review".
If there is something that I should change, you should set it to
"waiting on author". If you think that the
> Best solution: Upgrade everyone to scram, then change md5 to scram in
> pg_hba.conf and never look back.
>
To expand more on the "upgrade everyone to scram", that means force all
users to set a new password while using scram (which should be the
default). You can do it yourself by getting a list
Hi again,
Thanks very much for the replies last week. We’ve been continuing to
investigate this problem, and I thought I’d share an update on where we are.
To recap: the situation is that, looking at our backup from 2025-06-26
via pageinspect, we have btree index rows which point to either
n
Hi Laurenz,
On 09/07/2025 16:26, Laurenz Albe wrote:
I have added the patch to the current commitfest:
https://commitfest.postgresql.org/patch/5871/
Just to let you know that I have added a review through the commitfest app.
You can see it here:
https://www.postgresql.org/message-id/flat/175
On 7/9/25 07:06, Jordan Adams wrote:
Hi Team,
Hope this email finds you well,
Apologies as I am unaware if this is the correct mailing address.
I would however like to inquire about an issue currently being
experienced with Postgres with one of our external clients.
When doing the setup and
On Wed, 2025-07-09 at 14:06 +, Jordan Adams wrote:
> "psql: FATAL: password authentication failed"
>
> Please advise if assistance can be provided?
Possibly. That error will cause an error message in the PostgreSQL
server log. Ask your DBA to find that error message and tell you
what it say
On Wed, Jul 9, 2025 at 11:26 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Wed, Jul 9, 2025 at 8:09 AM Ron Johnson
> wrote:
>
>> That requires setting the password to null and then recreating the
>> password, no?
>>
>
> You might want to verify that claim, and suggest a doc patch
On Wed, 2025-07-09 at 11:09 -0400, Ron Johnson wrote:
> > Best solution: Upgrade everyone to scram, then change md5 to scram
> > in pg_hba.conf and never look back.
>
> That requires setting the password to null and then recreating the
> password, no? Otherwise IIRC, changing an md5 password leav
On Wed, Jul 9, 2025 at 8:09 AM Ron Johnson wrote:
> That requires setting the password to null and then recreating the
> password, no?
>
You might want to verify that claim, and suggest a doc patch or bug fix if
you find it to be true - I sure don't see anything that remotely suggests
this.
Dav
On Wed, 2025-07-09 at 11:30 +, Zechman, Derek S wrote:
> > > There are no entries in pg_stats for the parent table until after I
> > > manually run an analyze on it – Example below
> >
> > You are right. I looked at the code, and "vacuumdb" does not process
> > partitiond tables, even if --an
On Wed, Jul 9, 2025 at 11:11 AM Adrian Klaver
wrote:
> On 7/9/25 06:56, Alpaslan AKDAĞ wrote:
> > Hello all
> >
>
> > As a result, some users are able to connect, while others cannot.
>
> What client is being used and what version of said client?
>
This is a salient point:clients from the pre-PG
On 7/9/25 06:56, Alpaslan AKDAĞ wrote:
Hello all
As a result, some users are able to connect, while others cannot.
What client is being used and what version of said client?
Best regards,
Alpaslan
--
Adrian Klaver
adrian.kla...@aklaver.com
On Wed, Jul 9, 2025 at 10:59 AM Greg Sabino Mullane
wrote:
> On Wed, Jul 9, 2025 at 9:57 AM Alpaslan AKDAĞ
> wrote:
>
>> Is it expected behavior that users created with scram-sha-256 passwords
>> can still connect via md5 in pg_hba.conf?
>
>
> Yes. From the docs:
>
>> To ease transition from the
On Wed, Jul 9, 2025 at 9:57 AM Alpaslan AKDAĞ
wrote:
> Is it expected behavior that users created with scram-sha-256 passwords
> can still connect via md5 in pg_hba.conf?
Yes. From the docs:
> To ease transition from the md5 method to the newer SCRAM method, if md5 is
> specified as a method i
On Wed, Jul 9, 2025 at 6:57 AM Alpaslan AKDAĞ
wrote:
>
>1. In such a case, what would be the recommended approach or best
>practice to follow during upgrades in order to avoid this kind of issue?
>
> This is all described quite clearly in the documentation, including the
upgrade procedure
> > Well, that wouldn't explain why it doesn't work on partitioned tables.
> > I am under the impression that it should.
> >
> > Derek, can cou share the pg_stats entries for the partitioned table?
>
> There are no entries in pg_stats for the parent table until after I manually
> run an analy
On Wed, 9 Jul 2025 at 12:19, Shlok Kyal wrote:
>
> On Wed, 9 Jul 2025 at 11:43, abrahim abrahao wrote:
> >
> > I got error “server process was terminated by signal 11: Segmentation
> > fault” using pg_create_logical_replication_slot with pgoutput plugin
> > parameter and using test_decoding wor
On Wed, 9 Jul 2025 at 11:43, abrahim abrahao wrote:
>
> I got error “server process was terminated by signal 11: Segmentation fault”
> using pg_create_logical_replication_slot with pgoutput plugin parameter and
> using test_decoding worked fine, any idea that is wrong?
>
> Note: I am using docke
Thanks Tom, really appreciate it.
On Sun, Jul 6, 2025 at 10:12 PM Tom Lane wrote:
> Soni M writes:
> > We just do patch updates from 15.12 to 15.13, restart Logical Master and
> > then Logical Replica, and suddenly Logical replication stops working.
> > Streaming replication of both are fine.
>
Soni M writes:
> We just do patch updates from 15.12 to 15.13, restart Logical Master and
> then Logical Replica, and suddenly Logical replication stops working.
> Streaming replication of both are fine.
This sounds like the same bug previously discussed in
https://www.postgresql.org/message-id/
Some updates :
Checking at lsn_diff from 33D44/EF3219B0 to 33D45/373C2D98,
pg_wal_lsn_diff
-
1208620008
which is quite different to memory alloc request 1095736448.
Digging deeper into debug messages :
DEBUG,0,"find_in_dynamic_libpath: trying
""/usr/pgsql-15/lib/libpqwa
DB;
but thanks to the responses, I should be able to make this work...
Also, I appreciate the clarification re CREATE INDEX (Doh!) and --jobs
Best,
Pierre
On 7/5/25 12:19, Pierre Fortin wrote:
On Sat, 05 Jul 2025 14:30:20 -0400 Tom Lane wrote:
I'd say give it a try; be sure to use one of the pg_dump modes
that compress the data.
OK... I failed to mention I have several databases in this cluster; so
digging into pg_dumpall, I see:
--binar
8227910662297 /var/lib/pgsql/data
It's likely that there's a deal of bloat in that. Even if there's not
much bloat, this number will include indexes and WAL data that don't
appear in pg_dump output.
Does this imply that on restore, I'll have to re-index everything?
The
On 7/5/25 11:24, p...@pfortin.com wrote:
On Sat, 5 Jul 2025 11:11:32 -0700 Adrian Klaver wrote:
Didn't try given:
$ df /mnt/db
Filesystem Size Used Avail Use% Mounted on
/dev/sdh117T 13T 3.0T 82% /mnt/db
You said you have ~70TB of free space, so where is the other ~63TB?
L data that don't
> >appear in pg_dump output.
>
> Does this imply that on restore, I'll have to re-index everything?
>
> >>> What was the pg_dump command?
> >
> >> Didn't try given:
> >> $ df /mnt/db
> >> Filesystem Siz
Pierre Fortin writes:
> OK... I failed to mention I have several databases in this cluster; so
> digging into pg_dumpall, I see:
>--binary-upgrade
> This option is for use by in-place upgrade utilities. Its use for
> other purposes is not recommended or supported. The behavior of the
t; 8227910662297 /var/lib/pgsql/data
>
>It's likely that there's a deal of bloat in that. Even if there's not
>much bloat, this number will include indexes and WAL data that don't
>appear in pg_dump output.
Does this imply that on restore, I'll have to re-
On Sat, Jul 5, 2025 at 2:24 PM wrote:
> On Sat, 5 Jul 2025 11:11:32 -0700 Adrian Klaver wrote:
>
> >On 7/5/25 09:52, Pierre Fortin wrote:
>
> >> Wanting to upgrade from:
> >> PostgreSQL 15.13 on x86_64-mageia-linux-gnu,
> >> compiled by gcc (Mageia 15.1.0-1.mga10) 15.1.0, 64-bit
> >> to:
> >> PG
p...@pfortin.com writes:
> On Sat, 5 Jul 2025 11:11:32 -0700 Adrian Klaver wrote:
>> How did you measure above?
> # du -sb /var/lib/pgsql/data
> 8227910662297 /var/lib/pgsql/data
It's likely that there's a deal of bloat in that. Even if there's not
much bloat, this number will include indexes
On Sat, 5 Jul 2025 11:11:32 -0700 Adrian Klaver wrote:
>On 7/5/25 09:52, Pierre Fortin wrote:
>> Wanting to upgrade from:
>> PostgreSQL 15.13 on x86_64-mageia-linux-gnu,
>> compiled by gcc (Mageia 15.1.0-1.mga10) 15.1.0, 64-bit
>> to:
>> PG 17.5
>>
>> Way back, I was able to use -k|--link option
On Sat, Jul 5, 2025 at 2:11 PM Adrian Klaver
wrote:
> On 7/5/25 09:52, Pierre Fortin wrote:
> > Hi,
> >
> > [Hope this gets through after dumping DKIM-ignorant mail provider.]
> >
> > Wanting to upgrade from:
> > PostgreSQL 15.13 on x86_64-mageia-linux-gnu,
> > compiled by gcc (Mageia 15.1.0-1.mg
On 7/5/25 09:52, Pierre Fortin wrote:
Hi,
[Hope this gets through after dumping DKIM-ignorant mail provider.]
Wanting to upgrade from:
PostgreSQL 15.13 on x86_64-mageia-linux-gnu,
compiled by gcc (Mageia 15.1.0-1.mga10) 15.1.0, 64-bit
to:
PG 17.5
Way back, I was able to use -k|--link option on
On Sat, 05 Jul 2025 13:04:55 -0400 Tom Lane wrote:
>You cannot do pg_upgrade without a copy of the old postgres
>server binary as well as the new one.
Bummer. Wish I had skills & time to try to overcome this...
Thanks!
Pierre
Pierre Fortin writes:
> - my Linux distro (Mageia) is not setup to handle multiple versions of
> postgres (installing 17.5 removes 15.13).
Ugh. You cannot do pg_upgrade without a copy of the old postgres
server binary as well as the new one. pg_upgrade by itself is not
capable of accessing ei
On Sat, Jul 5, 2025 at 9:52 AM Pierre Fortin wrote:
> If new pg_upgrade is the only binary, will both -b and -B default to it?
> Maybe at minimum I may need to specify:
> $ pg_upgrade -b /usr/bin -d data15 -D data17 -k
>
>
pgsql/pgsql-18/bin
> ./pg_ctl -D /var/pgsql/postgres-17 start
waiting for
osh S ; pgsql-gene...@postgresql.org
; pgsql-nov...@postgresql.org
Subject: Re: Foreign Data Wrapper from Oracle to Postgres 16
Caution: This email was sent from an external source. Please verify the
sender’s identity before clicking links or opening attachments.
On Wed, 2025-07-02 at 23:58 +0530, Santho
e context of a query that will update and re-insert the
recently-dead tuples? Still a bit far-fetched though, and if the
index is actually corrupt this doesn't explain how it got that way.
I'm more inclined to just say "once a btree index is out of order it
can do some very strange
On Fri, 4 Jul 2025, 15:38 Ron Johnson, wrote:
> On Fri, Jul 4, 2025 at 9:49 AM Erik Johnston wrote:
>
>> Hi, a quick update:
>>
>> - We have discovered that the corruption was present from before libicu
>> update.
>> - We ran `pg_amcheck --index state_groups_state_type_idx --heapallindexed
>> ma
On Fri, Jul 4, 2025 at 9:49 AM Erik Johnston wrote:
> Hi, a quick update:
>
> - We have discovered that the corruption was present from before libicu
> update.
> - We ran `pg_amcheck --index state_groups_state_type_idx --heapallindexed
> matrix`, which returned nothing
> - We believe that means t
an there actually are. (We do not believe
anything can have deleted a row with state group 483128098). Also
interestingly, querying (with the index re-enabled) for 963361875
returns the same row as returned above, so the row is in the index twice.
Another example state group (147961623) should o
Ron Johnson schrieb am 04.07.2025 um 12:05:
> On Fri, Jul 4, 2025 at 5:50 AM mailto:sham...@gmx.net>>
> wrote:
>
> > One coincidence is that we started seeing the first symptoms of this
> > around the same time as libicu was updated with a security patch.
> > However, postgres hasn’t
On Fri, Jul 4, 2025 at 5:50 AM wrote:
> > One coincidence is that we started seeing the first symptoms of this
> > around the same time as libicu was updated with a security patch.
> > However, postgres hasn’t been restarted and doesn’t reference the
> > new version in its process maps. Plus stat
> One coincidence is that we started seeing the first symptoms of this
> around the same time as libicu was updated with a security patch.
> However, postgres hasn’t been restarted and doesn’t reference the
> new version in its process maps. Plus state groups are integers
> anyway. We also use the
On Wed, 2025-07-02 at 23:58 +0530, Santhosh S wrote:
> I am working on a project along with my peers on developing an Foreign Data
> Wrapper
> to transfer data from Oracle to Postgres 16. We followed the below steps in
> order:
>
> 1. Developed the Foreign Data Wrapper (64-bit) using Microsoft V
On 7/2/25 07:26, Durumdara wrote:
Sorry.
I forgot to mention that I have two arrays (records).
One for the modifiable elements, and one for the checkable elements.
If there is a conflict between the actual mod. item and one of the
checkable items, the checkable item will move to the end of the
On Wed, 2025-07-02 at 20:12 +0530, Gaurav Aradhya wrote:
> Can you please let me know when Postgresql 17.x shall be supported for
> Windows Server 2025? Greatly appreciated your feedback.
If you want to know if it is working, the best answer is "as soon as
someone donates a Windows 2025 buildfarm
On 7/2/25 07:42, Gaurav Aradhya wrote:
Greetings,
Can you please let me know when Postgresql 17.x shall be supported for
Windows Server 2025? Greatly appreciated your feedback.
The Windows packaging is done by EDB, someone from there will need to
see this and respond or you could contact th
On Wednesday, July 2, 2025, Gaurav Aradhya wrote:
>
> Can you please let me know when Postgresql 17.x shall be supported for
> Windows Server 2025? Greatly appreciated your feedback.
>
Impossible to guess when someone may choose to set up a build farm member
running that OS.
David J.
I don't know exactly what I did wrong but redoing what I described in the
email worked perfectly! Thanks everyone!
Enviado do Gmail para celular
Em seg., 30 de jun. de 2025 às 15:35, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:
> I'm trying to simulate a PITR in postgr
Sorry.
I forgot to mention that I have two arrays (records).
One for the modifiable elements, and one for the checkable elements.
If there is a conflict between the actual mod. item and one of the
checkable items, the checkable item will move to the end of the
modification list.
And the actual mo
On Wed, Jul 2, 2025 at 8:21 AM Durumdara wrote:
> Hello!
>
> I have to store some fetched records into two lists (arrays) to work with
> them.
>
There's almost certainly a way to do what you need done without using
arrays. Might require a bit of rethinking, though.
--
Death to , and butter sa
On Wednesday, July 2, 2025, Durumdara wrote:
>
>
> Is there any way to avoid this? To use a "simple untyped record" in an
> array without "dependencies"?
>
Use jsonb
David J.
A few more examples:
1. Why are different query_ids displayed in the log for this test query?
2025-07-01 13:38:47.852 MSK [2518006:549/405366] [postgres] pgAdmin
*-11391618518959119* 10.206.112.24(51180) LOG: duration: 101.141 ms plan:
Query Text: BEGIN;
select pg_sleep(.1);
On Tue, Jul 01, 2025 at 10:24:14AM +0300, Maksim Gorkov wrote:
> 2064869707185898531;'BEGIN;...' -- the full text in query1.sql attachment
> 2064869707185898531;'COMMIT;'
>
> there is another example, if required I can send it for review.
>
> Why does this happen and how can it be fixed?
Hard to
Am 30.06.2025 um 21:45 schrieb Ron Johnson:
Using PgBackRest might be more convenient, since it handles everything
you need, is multithreaded, never removes too many wal files,
compresses files if you want and also encrypts them if you want.
I agree, with pgBackRest it's basically: pgbackre
## Franklin Anderson de Oliveira Souza (frankli...@gmail.com):
> LOG: database system was shut down at 2025-06-30 12:15:28 -04
> cp: cannot stat '/dados/temp/wals/0002.history': No such file or directory
> -
>
>
> The restore_command requires the .history file but it does not
On 6/30/25 12:35, Franklin Anderson de Oliveira Souza wrote:
I'm trying to simulate a PITR in postgresql 16 with the following steps:
-
LOG: starting PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc
(GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
LOG: listening on IPv6
Using PgBackRest might be more convenient, since it handles everything you
need, is multithreaded, never removes too many wal files, compresses files
if you want and also encrypts them if you want.
(In 2025, I also leave pg_wal on the same mount point as data/. Disk space
is plentiful and it's ju
On 2025-06-28 18:06:51 +0200, raphi wrote:
> Am 28.06.2025 um 15:59 schrieb Peter J. Holzer:
> > On 2025-06-27 19:00:36 +0200, raphi wrote:
> >
> > > It's the application's password that we want to ensure that it is
> > > complex and gets changed after we set an initial password for it.
> > Why le
Am 28.06.2025 um 15:59 schrieb Peter J. Holzer:
On 2025-06-27 19:00:36 +0200, raphi wrote:
It's the application's password that we want to ensure that it is
complex and gets changed after we set an initial password for it.
Why let a human change that at all? Couldn't you just create a suita
On Sat, Jun 28, 2025 at 9:59 AM Peter J. Holzer wrote:
> On 2025-06-27 19:00:36 +0200, raphi wrote:
> >
> >
> > Am 26.06.2025 um 14:27 schrieb Peter J. Holzer:
> > > On 2025-06-25 17:55:12 +0200, raphi wrote:
> > > > Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
> > > > > On 2025-06-25 14:42:26
On 2025-06-27 19:00:36 +0200, raphi wrote:
>
>
> Am 26.06.2025 um 14:27 schrieb Peter J. Holzer:
> > On 2025-06-25 17:55:12 +0200, raphi wrote:
> > > Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
> > > > On 2025-06-25 14:42:26 +0200, raphi wrote:
> > > > > That's not how the identiy principle w
On Sat, 2025-06-28 at 01:23 +, Zechman, Derek S wrote:
> > Well, that wouldn't explain why it doesn't work on partitioned tables.
> > I am under the impression that it should.
> >
> > Derek, can cou share the pg_stats entries for the partitioned table?
>
> There are no entries in pg_stats for
> > We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and
> > performed the analyze-in-stages post upgrade. It has been noticed that
> > some plans changed to use hash joins instead of nested loops. Further
> > investigation found it was because the parent table of partitioned
We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and performed
the analyze-in-stages post upgrade. It has been noticed that some plans
changed to use hash joins instead of nested loops. Further investigation found
it was because the parent table of partitioned tables did no
On Fri, 2025-06-27 at 08:31 -0700, Adrian Klaver wrote:
> On 6/27/25 06:35, Zechman, Derek S wrote:
> > We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and
> > performed the analyze-in-stages post upgrade. It has been noticed that
> > some plans changed to use hash joins instea
Am 26.06.2025 um 14:27 schrieb Peter J. Holzer:
On 2025-06-25 17:55:12 +0200, raphi wrote:
Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
On 2025-06-25 14:42:26 +0200, raphi wrote:
That's not how the identiy principle works, at least not how it's
implement in our company. A user in ldap ha
On 6/27/25 06:35, Zechman, Derek S wrote:
We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and
performed the analyze-in-stages post upgrade. It has been noticed that
some plans changed to use hash joins instead of nested loops. Further
investigation found it was because the p
>
> It would be really handy to know that `$1` is being used as a non nullable
> value
To push back in a different way, how exactly would this be useful?
The system catalogs are the best place to get all the various information
about a relation, including any and all constraints. Data type info
On Friday, June 27, 2025, Giacomo Cavalieri
wrote:
>
> It would be really handy to know that `$1` is being used as a non nullable
> value, while `$2` could actually be null. Can this already be achieve
> today, or would there be a way to surface this kind of information for
> query parameters in
Hi,
I have no idea how/if this is possible using the query protocol but I would
try to parse the INSERT statement to get the table and columns names and
then look up whether they are nullable in the information schema (
https://www.postgresql.org/docs/current/infoschema-columns.html)
Petr
On Fri,
On Fri, Jun 27, 2025 at 9:35 AM Zechman, Derek S
wrote:
>
>
> We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and
> performed the analyze-in-stages post upgrade. It has been noticed that
> some plans changed to use hash joins instead of nested loops. Further
> investigation fo
On Thursday, June 26, 2025, Arpad Kiss A wrote:
> Can someone explain why the difference in behavior? Does postgres only use
> the seqno only to differentiate the wal files here? Why does postgres not
> rotate out files in the former case?
>
Seems like it is being helpful not throwing away data
On 2025-06-25 17:55:12 +0200, raphi wrote:
> Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
> > On 2025-06-25 14:42:26 +0200, raphi wrote:
> > > That's not how the identiy principle works, at least not how it's
> > > implement in our company. A user in ldap has a direct relation to
> > > one digit
gured
LDAP as described in the documentation:
https://www.postgresql.org/docs/current/auth-ldap.html
[quote]
Once the user has been found in this search, the server re-binds to the
directory as this user, using the password specified by the client, to
verify that the login is correct
[/quote
On 2025-06-23 16:35:35 +0200, raphi wrote:
> To be fair, setting up LDAP is very easy in PG, just one line in hba.conf
> and all is done. But sadly, that's only where the problems begin. The
> difficult part is to embedd this setup into a company, especially a large
> one as I work for with over 10
On 2025-06-25 14:42:26 +0200, raphi wrote:
>
>
> Am 25.06.2025 um 13:55 schrieb Peter J. Holzer:
> > On 2025-06-23 16:35:35 +0200, raphi wrote:
> > > To be fair, setting up LDAP is very easy in PG, just one line in hba.conf
> > > and all is done. But sadly, that's only where the problems begin. T
Basic debugging:
Try looking at each node more closely with pcp_node_info
https://www.pgpool.net/docs/latest/en/html/pcp-node-info.html
Also make sure you are always using health_check
https://www.pgpool.net/docs/latest/en/html/runtime-config-health-check.html
Specific debugging:
2025-06-19 1
Am 25.06.2025 um 13:55 schrieb Peter J. Holzer:
On 2025-06-23 16:35:35 +0200, raphi wrote:
To be fair, setting up LDAP is very easy in PG, just one line in hba.conf
and all is done. But sadly, that's only where the problems begin. The
difficult part is to embedd this setup into a company, esp
I wrote:
> I have a Postgres sever with the 'track_counts' setting
> stuck in 'off'. [...]
I ghosted-out from this thread with my tail between my legs,
because the only collegue who had access to the affected
machine had no time to spare and then went of vacation. He
has returned now, and I hav
many companies do, but you need a modern auth
system like Kerberos. Even if we were to put something into Postgres
today (and given the MFA and re-use requirements, it's near
impossible), PCI DSS keeps evolving and getting stricter, so keeping
up with it would get harder with each release.
On 6/24/25 08:38, Kouber Saparev wrote:
Barman is involved indeed, its version is 3.14. The command: "barman
backup xxx --incremental latest".
I don't use Barman and I am still figuring out incremental backups, so
what I say should be taken lightly.
From here:
https://docs.pgbarman.org/rele
os. Even if we were to put something into Postgres today (and
given the MFA and re-use requirements, it's near impossible), PCI DSS keeps
evolving and getting stricter, so keeping up with it would get harder with
each release.
Can I do something to help bringing these feature into PG? My C
Barman is involved indeed, its version is 3.14. The command: "barman backup
xxx --incremental latest".
PostgreSQL is version 17.3.
На вт, 24.06.2025 г. в 18:26 Adrian Klaver
написа:
> On 6/24/25 02:31, Kouber Saparev wrote:
> > Hello,
> >
> > We are trying to use pg_combinebackup but eventually
On 6/24/25 02:31, Kouber Saparev wrote:
Hello,
We are trying to use pg_combinebackup but eventually it fails with:
What is the command you are using to take the incremental backups?
What version of Postgres are you taking the incremental backups from?
Given the naming below, is Barman involv
Le 24/06/2025 à 07:18, raphi a écrit :
Am 23.06.2025 um 22:39 schrieb Christoph Berg:
Re: raphi
Sorry for this rather long (first) email on this list but I feel
like I had
to explain our usecase and why LDAP is not always as simple as
adding a line
to hba.conf.
Did you give the &quo
On 23.06.2025 16:33, Dmitry wrote:
Hi,
The problem is as follows.
A replication cluster includes a primary server and one hot-standby replica.
The workload on the primary server is represented by multiple requests
generating multixact IDs, while the hot-standby replica performs reading
request
Am 23.06.2025 um 22:39 schrieb Christoph Berg:
Re: raphi
Sorry for this rather long (first) email on this list but I feel like I had
to explain our usecase and why LDAP is not always as simple as adding a line
to hba.conf.
Did you give the "pam" method a try? T
Not really beca
Re: raphi
> Sorry for this rather long (first) email on this list but I feel like I had
> to explain our usecase and why LDAP is not always as simple as adding a line
> to hba.conf.
Did you give the "pam" method a try? There are PAM modules for all
sorts of password checks.
Christoph
On 6/23/25 13:19, C. wrote:
Reply to list also.
Ccing list.
I don't know. The postgres kernel crashes, not the client
app.
So does the Postgres log show anything?
On Monday, June 23, 2025 at 09:41:33 PM GMT+2, Adrian Klaver
wrote:
On 6/23/25 12:32, C. wrote:
> Hi there and thx for re
On 6/23/25 12:32, C. wrote:
Hi there and thx for reading and answering if you can
A few years ago, I wrote a pg module in C on gcc/linux. This module
works fine, and I'm striving to port on windows postgres edb, I compiled
the corresponding .dll wirh both mingw54 and msvc 2022, but got postgr
Am 23.06.2025 um 17:05 schrieb Tom Lane:
raphi writes:
We can set a password for a role in PG but there is no way to force a
user to change it, prevent reuse or to enforce some complexity on it. As
I understand, that's by choice and when I ask about this, the usual
answer is "that's not the job
raphi writes:
> We can set a password for a role in PG but there is no way to force a
> user to change it, prevent reuse or to enforce some complexity on it. As
> I understand, that's by choice and when I ask about this, the usual
> answer is "that's not the job of a database, use LDAP for it".
On 2025-Jun-19, Dominique Devienne wrote:
> Hi. Little mystery we don't understand. v17.
>
> Create new DB, owned by dedicated new ROLE.
> Create extension (pgcrypto) in our case. Installed in public, owned by
> DB owner role.
> Create schemas and populate them inside the DB.
I would investigate
Hi,
Thanks for the good point:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
That is a difference, the old pg11 running on Ubuntu 18.4 had
disabled overcommit (vm.overcommit_memory = 2).
Anyway, on a dedicated DB server box with 123GB RAM running only vacuum (14
parallel processes (2GB
On 6/21/25 23:09, Aleš Zelený wrote:
> Hello,
> ...
>
> The application benefits from parallel queries, so despite the first
> temptation to disable parallel queries (based on log entries correlation
> only, but is that the root cause?) I did not want to disable parallel
> queries, if there is anot
Good to know. Thank you!
On Fri, Jun 20, 2025 at 7:17 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thursday, June 19, 2025, Laurenz Albe wrote:
>
>> On Thu, 2025-06-19 at 23:05 +0200, Phillip Diffley wrote:
>> > Postgres has a to_jsonb function that will convert a value into it
Hello Laurenz, thanks for your quick reply.
The issue was having the old postgres library in LD_LIBRARY_PATH. Once I
removed it, everything started to look good! In all the past years this was not
a problem though. But anyway: All good now!
Thanks again: peter
> On 20 Jun 2025, at 14:00, Laur
On 6/19/25 07:54, Dominique Devienne wrote:
On Thu, Jun 19, 2025 at 4:18 PM Adrian Klaver wrote:
On 6/19/25 06:09, Dominique Devienne wrote:
Hi. Little mystery we don't understand. v17.
Does 'all' include the public schema?
No. We don't touch `public` at all, beside pgcrypto ending up insid
1 - 100 of 26182 matches
Mail list logo
