On Thu, Apr 14, 2016 at 01:40:21PM -0400, David Steele wrote: > On 4/14/16 1:33 PM, Tom Lane wrote: > > David Steele <da...@pgmasters.net> writes: > >> On 4/14/16 7:16 AM, Andreas Karlsson wrote: > >>> I am personally not a fan of the pg_get_Xdef() functions due to their > >>> heavy reliance on the syscache which feels rather unsafe in combination > >>> with concurrent DDL. > > > >> As far as I know pg_dump share locks everything before it starts so > >> there shouldn't be issues with concurrent DDL. Try creating a new > >> inherited table with FKs, etc. during a pg_dump and you'll see lots of > >> fun lock waits. > > > > I think pg_dump is reasonably proof against DDL on tables. It is not > > at all proof against DDL on other sorts of objects, such as functions, > > because of the fact that the syscache will follow catalog updates that > > occur after pg_dump's transaction snapshot. > > Hmm, OK. I'll need to go look at that. > > I thought that the backend running the pg_dump would fill it's syscache > when it took all the locks and then not update them during the actual > dump. If that's not the case then it's a bit scary, yes. > > It seems to make a good case for physical backups vs. logical.
I think another issue is that the pg_dump backend gets cache invalidations from other backends that cause it to reload the cache with new contents, so even if you pre-loaded the cache at snapshot time, you would still need to ignore cache invalidations from other backends. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
