pg_notify contention

Hi, I am measuring a very simple case of pg_notify in an after update trigger. The trigger is the following: CREATE OR REPLACE FUNCTION audit_event() RETURNS TRIGGER AS $$ BEGIN PERFORM pg_notify('user', 'hello world'); RETURN NULL; END; $$ LANGUAGE plpgsql; and configured on the

Re: pg_notify contention

As part of the commit operation, Postgres inserts the notification into a queue. Naturally, that insert is guarded by a lock and that lock is released only at the very end of the commit operation. This effect gets much worse if you also configure synchronous replication because commit finishes only

Re: pg_notify contention

Hi Torsten and thanks for your quick response. My problem with WAL stream and pg_logical_emit_message is that this will pollute the wal files resulting in bigger files in which btw are also archived using archive-command for disaster recovery cases. I am thinking of an approach that instead of no

Introduction of a new field in pg_class indicating presence of a large object in a table

Hi All, I hope you're all doing well! Recently, I have across a scenario where one of our client was unable to perform a major version upgrade of their PostgreSQL instance as it was failing due to OOM errors. When reviewed the upgrade log files and queried pg_largeobject_metadata, we found a sign

Re: Introduction of a new field in pg_class indicating presence of a large object in a table

On Tue, Apr 30, 2024 at 11:57 AM Gaurav Pant wrote: > I wanted to know if there is any such system table that we can use to > identify and map the fields containing large objects and the respective > tables and if it is not already there, do we have any plans to incorporate > the same in pg_class

Re: Introduction of a new field in pg_class indicating presence of a large object in a table

"David G. Johnston" writes: > On Tue, Apr 30, 2024 at 11:57 AM Gaurav Pant > wrote: >> I wanted to know if there is any such system table that we can use to >> identify and map the fields containing large objects and the respective >> tables and if it is not already there, do we have any plans to

Linked directory or explicit reference

Hi All; When doing an initial install of PostgreSQL on RHEL 7 or 8 derived OS via rpm, what are pros, cons and recommendations of these 2 procedures for utilizing a second disk? Secondary SSD or RAID mounted at /disk2. Option #1 1. install the rpm which creates basic user and home 2. Create

Re: Linked directory or explicit reference

On Tue, Apr 30, 2024 at 7:00 PM Senor Cervesa wrote: > Hi All; > > When doing an initial install of PostgreSQL on RHEL 7 or 8 derived OS via > rpm, what are pros, cons and recommendations of these 2 procedures for > utilizing a second disk? > > Secondary SSD or RAID mounted at /disk2. > > Option

Posgresql 14 and CarbonBlack on RHEL8?

(CarbonBlack is cross-platform AV software sold by VMware.) Currently we're running PG 9.6.24 on RHEL 6.10 with CB (version unknown to me) in production, and testing PG 14.11 on RHEL 8.9 with CB 2.15.2 (hopefully going into production next month). Both old and new VMs are 32 CPU with 128GB RAM. N

Re: Posgresql 14 and CarbonBlack on RHEL8?

Ron Johnson writes: > When running stress tests on the systems (in prod, during the maintenance > window), 171K events/second are generated on the RHEL8 servers, and CB > needs (according to top(1)) 325% of CPU to handle that, and still dropping > 92% of them. > The RHEL6 system doesn't bat an eye