On Sun, Feb 26, 2017 at 10:16 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Feb 22, 2017 at 11:49 PM, Mithun Cy <mithun...@enterprisedb.com> > wrote: >> Hi all thanks, >> I have tried to fix all of the comments given above with some more >> code cleanups. > > While reading this patch tonight, I realized a serious problem with > the entire approach, which is that this patch is supposing that we can > read relation blocks for every database from a single worker that's > not connected to any database. I realize that I suggested that > approach, but now I think it's broken, because the patch isn't taking > any locks on the relations whose pages it is reading, and that is > definitely going to break things. While autoprewarm is busy sucking > blocks into the shared buffer cache, somebody could be, for example, > dropping one of those relations. DropRelFileNodesAllBuffers and > friends expect that nobody is going to be concurrently reading blocks > back into the buffer cache because they hold AccessExclusiveLock, and > they assume that anybody else who is touching it will hold at least > AccessShareLock. But this violates that assumption, and probably some > others. > > This is not easy to fix. The lock has to be taken based on the > relation OID, not the relfilenode, but we don't have the relation OID > in the dump file, and recording it there won't help, because the > relfilenode can change under us if the relation is rewritten with > CLUSTER or VACUUM FULL or relevant forms of ALTER TABLE. I don't see > a solution other than launching a separate worker for each database, > which seems like it could be extremely expensive if there are many > databases. Also, I am pretty sure it's no good to take locks before > recovery reaches a consistent state.
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? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
