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
(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.
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
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.
"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
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
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
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
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
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
10 matches
Mail list logo
