On Thu, Mar 2, 2017 at 7:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > So we should move this loading of blocks once the recovery reaches a > consistent state so that we can connect to a database. To allow > worker, to take a lock, we need to dump relation oid as well. Is that > what you are envisioning to fix this problem?
No. The relation -> relfilenode mapping isn't constant, and the dumping process has no way to get the relation OIDs from the relfilenodes anyway. I think what you need to do is dump the relfilenodes as at present, but then at restore time you need a worker per database, and it connects to the database and then uses the infrastructure added by f01d1ae3a104019d6d68aeff85c4816a275130b3 to discover what relation OID, if any, currently corresponds to the proposed relfilenode. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
