Thank you for the explanation! I looked into what OpenSSL does when freeing
the underlying OSSLCipher resources, and as you say, it is more than just a
free. There is sometimes aditional values to free, and they go through and
overwrite the data in a special way regardless. So I see why the
On Fri, 2024-02-02 at 10:14 +0530, veem v wrote:
> On Fri, 2 Feb 2024 at 02:43, Laurenz Albe wrote:
> > On Fri, 2024-02-02 at 02:27 +0530, veem v wrote:
> > > We have the below query which is running for ~45 seconds on postgres
> > > aurora reader instance.
> > > I have captured the explain
Thanks Greg, I really appreciated you message.I executed the query you shared,
and it is showing exactly the same type of lock you talked, it help me a lot.
ThanksIt is a usual behavior in some busy databases, I am trying to avoid
cancel sessions. I would like also double check my
On Wed, Jan 31, 2024 at 2:05 PM abrahim abrahao
wrote:
> There is a three-day vacuum freeze on a partition table with wait_event =
> BufferPin, no transactions (active or idle) older than it that are not
> blocked, but at least one select query is executing at all times related of
> this
*PROBLEM*
*yum update nothing provides libarmadillo.so.12()(64bit) needed by
gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common *
[root@rhel9-pg14 ~]# yum update --exclude=postgis33_14
--exclude=postgresql14*
Updating Subscription Management repositories.
EPEL_9
Vano Beridze writes:
> I granted insert and update permission on the table outbox_event to the
> user "app"
> When the following command is run with the user app
> update adm.outbox_event set .. where id = ..
> Postgresql gives the notification:
> ERROR: permission denied for table outbox_event
Hello,
I've got a table outbox_event in schema adm
The owner of this table is some role
I granted insert and update permission on the table outbox_event to the
user "app"
When the following command is run with the user app
update adm.outbox_event set .. where id = ..
Postgresql gives the
On Fri, Feb 2, 2024 at 3:25 PM abrahim abrahao
wrote:
> SHARE UPDATE EXCLUSIVE (ShareUpdateExclusiveLock) should not be blocked
> by ACCESS SHARE (AccessShareLock). Am I wrong about it? If I am not wrong
> why it still locking it?
>
Those locks with no other context are somewhat of a red
On Fri, 2 Feb 2024 at 13:20, Chris Angelico wrote:
> create or replace function send_settings_notification() returns
> trigger language plpgsql as $$begin perform
> pg_notify('stillebot.settings', ''); return null; end$$;
> create trigger settings_update_notify after update on
>
