Re: Regarding publish_via_partiton_root with pglogical
Hi Durgamahesh In pglogical extension, there is no direct equivalent to the publish_via_partition_root option found in the built-in logical replication you can achieve similar results when a new partition is added; you must add it to the replication set using pglogical.replication_set_add_table. Similarly existing partitions are reorganized or split, ensure to update the replication sets accordingly. Thanks & Regards *Muhammad Affan (*아판*)* *PostgreSQL Technical Support Engineer** / Pakistan R&D* Interlace Plaza 4th floor Twinhub office 32 I8 Markaz, Islamabad, Pakistan On Sat, Jul 20, 2024 at 12:00 PM Durgamahesh Manne < maheshpostgr...@gmail.com> wrote: > Hi > > Respected Team > > I know the use case of implementing the partitions with publication and > subscription of built-in logical replication > CREATE PUBLICATION dbz_publication FOR TABLE betplacement.bet WITH > (publish_via_partition_root = true); This will use parent table to replica > data changes to target from source > But > Could you please provide a logic to implement the same with pglogical ? > Do i need to add this publish_via_partition_root to > pglogical.replication_set_add_table functionality ? > you response is valuable in this aspect > > Regards, > Durga Mahesh >
Re: Bloated pg_catalog.pg_largeobjects
Hi I would suggest to backup your DB before doing such a thing. Run Vaccum Full, (VACUUM FULL pg_catalog.pg_largeobject) Running this on the system table might be risky Make sure you backup the database. & if you are using PG version above 9.1 use Pg_repack to reclaim the space. Note: It can be disruptive, so planning and preparing for potential downtime is essential. Thanks & regards *Muhammad Affan (*아판*)* *PostgreSQL Technical Support Engineer** / Pakistan R&D* Interlace Plaza 4th floor Twinhub office 32 I8 Markaz, Islamabad, Pakistan On Sun, Jul 21, 2024 at 3:46 AM wrote: > Hello All, > > I've got a cluster that's having issues with pg_catalog.pg_largeobject > getting massively bloated. Vacuum is running OK and there's 700GB of free > space in the table and only 100GB of data, but subsequent inserts seem to > be not using space from the FSM and instead always allocating new pages. > The table just keeps growing. > > Is this a known thing, maybe something special about LOs? > > Also, is the only way to recover space here a vacuum full on the table > since it's a catalog table? > > Thanks, > -- > Jon Erdman (aka StuckMojo on IRC) > PostgreSQL Zealot >
