You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Though pg_shard correctly marks its metadata tables so they are included in the output of pg_dump, these dumps are unusable because the relation_id column of pg_shard's metadata tables is of type oid. Because there is no guarantee a given relation will have identical oids, the oids in the metadata tables will not match any relations, rendering the dump unusable.
I found an old thread that insinuates pg_dump will produce a textual representation of tables that works across a restore boundary if the column is of type regclass instead of oid. As far as lower-level code is concerned, these two types are identical (so we will not need to change any implementation). By switching to regclass we can give users the ability to rebuild a master in an identical fashion to restoring a normal PostgreSQL instance from backup.
The text was updated successfully, but these errors were encountered:
Though
pg_shard
correctly marks its metadata tables so they are included in the output ofpg_dump
, these dumps are unusable because therelation_id
column ofpg_shard
's metadata tables is of typeoid
. Because there is no guarantee a given relation will have identicaloid
s, theoid
s in the metadata tables will not match any relations, rendering the dump unusable.I found an old thread that insinuates
pg_dump
will produce a textual representation of tables that works across a restore boundary if the column is of typeregclass
instead ofoid
. As far as lower-level code is concerned, these two types are identical (so we will not need to change any implementation). By switching toregclass
we can give users the ability to rebuild a master in an identical fashion to restoring a normal PostgreSQL instance from backup.The text was updated successfully, but these errors were encountered: