Skip site navigation (1) Skip section navigation (2)

Re: parallel pg_restore - WIP patch

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, Jeffrey Baker <jwbaker(at)gmail(dot)com>
Subject: Re: parallel pg_restore - WIP patch
Date: 2008-09-29 13:51:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Le lundi 29 septembre 2008, Tom Lane a écrit :
> * Extend the archive format to provide some indication that "restoring
> this object requires exclusive access to these dependencies".
> * Hardwire knowledge into pg_restore that certain types of objects
> require exclusive access to their dependencies.

Well, it seems to me that currently the FK needs in term of existing indexes 
and locks, and some other object lock needs, are all hardwired. Is it even 
safe to consider having the locks needed for certain commands not be 

Provided I'm not all wrong here, I don't see how having something more 
flexible at restore time than at build time is a win. The drawback is that 
whenever you change a lock need in commands, you have to remember teaching 
pg_restore about it too.

So my vote here is in favor of hardwired knowledge of pg_restore, matching 
target server code assumptions and needs.


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-09-29 13:53:28
Subject: Re: [PATCHES] Infrastructure changes for recovery
Previous:From: Tom LaneDate: 2008-09-29 13:46:08
Subject: Re: FSM rewrite: doc changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group