| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal : For Auto-Prewarm. |
| Date: | 2017-03-04 07:16:39 |
| Message-ID: | CA+Tgmoa=UqCL2mR+9WTq05tB3Up-z4Sv2wkzkDxDwBP7Mj_2_w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 2, 2017 at 7:14 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-03-04 07:19:55 | Re: UPDATE of partition key |
| Previous Message | Michael Paquier | 2017-03-04 07:15:53 | Re: 2017-03 Commitfest In Progress |