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 try
420/INCREMENTAL.4085177931.76" has truncation
block length 9501840 in excess of segment size 131072
Any idea what's wrong?
--
Kouber Saparev
На нд, 24.12.2023 г. в 3:37 Michael Paquier написа:
> > What quick solution would fix the replication? Repack of the table?
> Reload
> > of the database? Killing some backends?
>
> There may be something you could do as a short-term solution, but it
> does not solve the actual root of the problem
vily on this feature in a production environment and cannot just
leave the subscriber side out of sync.
Regards,
--
Kouber Saparev
[1]
https://postgrespro.com/list/thread-id/2597009#tycpr01mb83731ade7fd7c7cf5d335bceed...@tycpr01mb8373.jpnprd01.prod.outlook.com
>
> The fact that creating a _RETURN rule for a table causes it to be
> changed into a view. That's ugly and arguably dangerous.
>
>
Right, thank you.
Cheers,
--
Kouber Saparev
table to stay always a table), but not possible in case the table
is a partition (yet still possible if the partition is remote pointing back
to the same original server for instance).
Regards,
--
Kouber Saparev
space) for us, as it allows us to introduce
significant changes to the partitioned tables model without the need to
populate these changes on all the hundreds of past partitions that do exist
(and that we barely read anyway, that's why they reside on a remote server).
--
Kouber Saparev
ach?
I noticed that attaching the "_RETURN" rule to a table converts it to a
view, and the operation is irreversible, i.e. once attached, I cannot drop
the rule and put the relation back to a table one.
Cordially,
--
Kouber Saparev
>
> So the analyze(and freeze) are done before the new cluster are fully
> populated. Is the time being taken maybe for the loading schema/data
> portion?
>
>
No, the upgrade is stuck on these 2 stages indeed, maybe 50% on the first
and 50% (or a little more) on the second. When a run them outside
speed-up the entire process?
--
Kouber Saparev
Just in case somebody else also needs such a functionality in PostgreSQL <
12, I made a function in plpgsql:
https://github.com/kouber/pg_utils/blob/master/rename_index.sql
--
Kouber Saparev
commit;
COMMIT
It looks good. The only exceptional case I am able to discover is when the
index is used within a constraint, in which case I should also update
pg_constraint.
Thank's again for the accurate responses.
Regards,
--
Kouber Saparev
ER statement instead anyway, which makes a
lock implicitly. Thanks for the responses. There is nobody else doing DDLs
except me - Mr. DBA, so I guess I am safe on this side. ;)
Cheers,
--
Kouber Saparev
n't count for much.
>
Ah, 9.3 is not using MVCC for system catalogs?... Ouch. Then most probably
it is really not a good idea. That said, I am not modifying table names,
only index names... and I guess the internals, the planner etc. are not
working with names, but with oids instead?
Thanks and caffeine regards,
--
Kouber Saparev
27;::regclass;
Are there any risks to corrupt the database or to lose concurrent
transactions? I tried to make some tests with parallel queries and locks
over the table, but I did not discover anything special.
--
Kouber Saparev
15 matches
Mail list logo
