Re: [HACKERS] pg_upgrade old cluster delete script

2013-02-14 Thread Bruce Momjian
On Thu, Feb 14, 2013 at 12:29:52AM -0500, Bruce Momjian wrote:
 You might remember this pg_upgrade bug report where the user complained
 that user-defined tablespaces _inside_ the old cluster directory were
 deleted by the old cluster delete script:
 
   
 http://www.postgresql.org/message-id/e1thpdm-00018c...@wrigleys.postgresql.org
 
 and my reply that we don't want to fix this:
 
   http://www.postgresql.org/message-id/20121004191201.ga11...@momjian.us
 
 However, creating a script that deletes data is never a good idea so I
 have created the attached patch to avoid creating the script in these
 cases, and issue a message to the user.
 
 The test isn't perfect but it is probably close enough.  I don't think
 it is worth unlinking a possibly matching filename in such cases.

OK, I have applied a modified version of this patch the uses the
port/path.c functions to do proper path comparison, and decided to
conditionally unlink the script file just in case.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] pg_upgrade old cluster delete script

2013-02-13 Thread Bruce Momjian
You might remember this pg_upgrade bug report where the user complained
that user-defined tablespaces _inside_ the old cluster directory were
deleted by the old cluster delete script:


http://www.postgresql.org/message-id/e1thpdm-00018c...@wrigleys.postgresql.org

and my reply that we don't want to fix this:

http://www.postgresql.org/message-id/20121004191201.ga11...@momjian.us

However, creating a script that deletes data is never a good idea so I
have created the attached patch to avoid creating the script in these
cases, and issue a message to the user.

The test isn't perfect but it is probably close enough.  I don't think
it is worth unlinking a possibly matching filename in such cases.
 
-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/check.c b/contrib/pg_upgrade/check.c
new file mode 100644
index a7d4a68..0be90ae
*** a/contrib/pg_upgrade/check.c
--- b/contrib/pg_upgrade/check.c
*** output_completion_banner(char *analyze_s
*** 246,255 
  		by pg_upgrade so, once you start the new server, consider running:\n
  			   %s\n\n, analyze_script_file_name);
  
! 	pg_log(PG_REPORT,
! 		   Running this script will delete the old cluster's data files:\n
! 		   %s\n,
! 		   deletion_script_file_name);
  }
  
  
--- 246,262 
  		by pg_upgrade so, once you start the new server, consider running:\n
  			   %s\n\n, analyze_script_file_name);
  
! 
! 	if (deletion_script_file_name)
! 		pg_log(PG_REPORT,
! 			   Running this script will delete the old cluster's data files:\n
! 			   %s\n,
! 			   deletion_script_file_name);
! 	else
! 		pg_log(PG_REPORT,
! 			   Could not create a script to delete the old cluster's data files\n
! 			   because user-defined tablespaces exist in the old cluster directory.\n
! 			   The old cluster's contents must be deleted manually.\n);
  }
  
  
*** create_script_for_old_cluster_deletion(c
*** 585,590 
--- 592,609 
  	FILE	   *script = NULL;
  	int			tblnum;
  
+ 	/*
+ 	 *	Some users (oddly) create tablespaces inside the cluster data
+ 	 *	directory.  We can't create a proper old cluster delete script
+ 	 *	in that case.
+ 	 */
+ 	for (tblnum = 0; tblnum  os_info.num_old_tablespaces; tblnum++)
+ 	{
+ 		if (strncmp(os_info.old_tablespaces[tblnum], old_cluster.pgdata,
+ 			strlen(old_cluster.pgdata)) == 0)
+ 			return;
+ 	}
+ 
  	*deletion_script_file_name = pg_malloc(MAXPGPATH);
  
  	prep_status(Creating script to delete old cluster);

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers