Hi All,
We recently started seeing an error “ERROR: uncommitted xmin 3100586
from before xid cutoff 10339367 needs to be frozen” on our user tables.
I’m unable to do ‘vacuum’, ‘vacuum freeze’ or ‘vacuum full’ on Postgres
14.4 running on a windows environment.
Error:
first come this ERROR:
Can someone please confirm if this behavior of foreign key is expected with
the partition created through partman extension and thus we need to have
our manual process written for partition purge (in order of child first and
then parent) , rather relying on partman partition maintenance to take car
> On 21 Mar 2024, at 14:27, Alvaro Herrera wrote:
>
> On 2024-Mar-21, Daniel Gustafsson wrote:
>
>> On 21 Mar 2024, at 13:28, Alvaro Herrera wrote:
>>
>>> I very much doubt that they realized that comments were going to be
>>> omitted. But clearly it's just a mistake, and easily fixed.
>>
>>
On Thu, 21 Mar 2024 at 23:39, Laurenz Albe wrote:
> On Thu, 2024-03-21 at 22:50 +0530, veem v wrote:
> > So when you mentioned "to create the foreign keys *not* between the
> > partitioned table but between the individual partitions" , can that
> > be done using the same "partman.create_parent" p
On Thu, 2024-03-21 at 22:50 +0530, veem v wrote:
> So when you mentioned "to create the foreign keys *not* between the
> partitioned table but between the individual partitions" , can that
> be done using the same "partman.create_parent" procedure and automated
> cron job schedule or has to be done
On Thu, 21 Mar, 2024, 6:18 pm Laurenz Albe,
wrote:
What you *can* do is detach the partition and then drop it, but detatching
will
be slow because PostgreSQL has to check for referencing rows.
The best solution is to create the foreign key *not* between the partitioned
tables, but between the i
On Thu, Mar 21, 2024 at 7:48 AM Alvaro Herrera wrote:
> On 2024-Mar-21, Joseph Kennedy wrote:
> > I'm planning to upgrade my PostgreSQL database from version 12 to
> > version 15 using pg_upgrade. After completing the upgrade process, I'm
> > curious to know whether it's necessary to reindex the d
On 3/20/24 17:13, Adrian Klaver wrote:
On 3/20/24 15:52, Jeff Ross wrote:
On 3/20/24 16:25, Adrian Klaver wrote:
On 3/20/24 15:18, Jeff Ross wrote:
Greetings!
I built a trigger fired process that copies an "order" from our
production database to our dev database. An order, in this case,
- Mail original -
> De: "Laurenz Albe"
> À: "veem v" , "pgsql-general"
>
> Envoyé: Jeudi 21 Mars 2024 13:48:19
> Objet: Re: Not able to purge partition
> On Thu, 2024-03-21 at 11:07 +0530, veem v wrote:
>> CREATE TABLE schema1.test_part_drop_parent
>> (
>> c1 varchar(36) NOT NULL ,
>>
On 2024-Mar-21, Daniel Gustafsson wrote:
> On 21 Mar 2024, at 13:28, Alvaro Herrera wrote:
>
> > I very much doubt that they realized that comments were going to be
> > omitted. But clearly it's just a mistake, and easily fixed.
>
> It sure looks like a search/replace kind of bug. I had just
On Thu, 2024-03-21 at 11:07 +0530, veem v wrote:
> CREATE TABLE schema1.test_part_drop_parent
> (
> c1 varchar(36) NOT NULL ,
> c2_part_date timestamp with time zone NOT NULL ,
> c3 numeric(12,0) NOT NULL ,
> CONSTRAINT test_part_drop_parent_PK PRIMARY KEY (c1,c2_part_date)
> ) PARTITION B
> On 21 Mar 2024, at 13:28, Alvaro Herrera wrote:
>
> On 2024-Mar-21, Daniel Gustafsson wrote:
>
>> Comments on roles are stored against the pg_authid catalog relation which is
>> the catalog used for dumping roles, but when using --no-role-passwords we
>> instead switch to using the pg_roles ca
On 2024-Mar-21, Daniel Gustafsson wrote:
> Comments on roles are stored against the pg_authid catalog relation which is
> the catalog used for dumping roles, but when using --no-role-passwords we
> instead switch to using the pg_roles catalog relation. Since comments are
> dumped for the relation
Also, i see, its not allowing to drop the parent table partition even all
the respective child partitions are dropped and no child record exists in
the child table. But this started working , when we detach parent partition
and then drop the partitions. So it means if we just change the setup of
th
On Thu, Mar 21, 2024 at 11:52 AM Dominique Devienne
wrote:
> On Thu, Mar 21, 2024 at 11:46 AM Daniel Gustafsson
> wrote:
>
>> > However I noticed that comments on roles are also omitted from the
>> dump, as if --no--comments flag was set - but it wasn't.
>>
>> Comments on roles are stored agains
On 2024-Mar-21, Joseph Kennedy wrote:
> I'm planning to upgrade my PostgreSQL database from version 12 to
> version 15 using pg_upgrade. After completing the upgrade process, I'm
> curious to know whether it's necessary to reindex the database.
>
> Could anyone please clarify whether reindexing is
On Wed, 20 Mar 2024 at 21:01, Celia McInnis wrote:
> Correct. But the initial CREATE VIEW was done as a SELECT from the database,
> so if the create view was quick, I thought that the select from the view
> would be equally quick. Is this a faulty assumption?
It is. Create view does not run th
On Thu, Mar 21, 2024 at 11:46 AM Daniel Gustafsson wrote:
> > However I noticed that comments on roles are also omitted from the dump,
> as if --no--comments flag was set - but it wasn't.
>
> Comments on roles are stored against the pg_authid catalog relation
Hi. What do you mean? ROLEs are not
> On 20 Mar 2024, at 18:40, Bartosz Chroł wrote:
>
> Hello,
> I've tried to dump roles using the following call to pg_dumpall:
> pg_dumpall.exe --roles-only --no-role-passwords
> However I noticed that comments on roles are also omitted from the dump, as
> if --no--comments flag was set - but it
Hello everyone,
I'm planning to upgrade my PostgreSQL database from version 12 to version 15
using pg_upgrade. After completing the upgrade process, I'm curious to know
whether it's necessary to reindex the database.
Could anyone please clarify whether reindexing is required after completing the
Hello,
I've tried to dump roles using the following call to pg_dumpall:
pg_dumpall.exe --roles-only --no-role-passwords
However I noticed that comments on roles are also omitted from the dump, as if
--no--comments flag was set - but it wasn't.
When I call `pg_dumpall.exe --roles-only` than it work
On Thu, Mar 21, 2024 at 8:10 AM alex work wrote:
> We encounter slow `GRANT ROLES` only on PostgreSQL 16 instances up to 42
> seconds
> in production, the client process at PostgresSQL would use 100% of the
> CPU. [...]
>
Using ROLE `acc`, grant `d_` ROLE to a session ROLE:
> real0m7.579s [..
Hello,
we run multiple versions of PostgreSQL instances on production. Some time ago
we add new physical servers and decided to go with latest GA from pgdg APT
repository, that is PostgreSQL 16.
We encounter slow `GRANT ROLES` only on PostgreSQL 16 instances up to 42 seconds
in production, the cl
23 matches
Mail list logo
