pg_resetsysid
| От | Petr Jelinek | 
|---|---|
| Тема | pg_resetsysid | 
| Дата | |
| Msg-id | 557D9DED.2080204@2ndquadrant.com обсуждение исходный текст  | 
		
| Ответы | 
                	
            		Re: pg_resetsysid
            		
            		 | 
		
| Список | pgsql-hackers | 
Hi, This is an attempt to revive the resetsysid tool submission that didn't go anywhere last year [1]. In that thread there were mainly two complains, one that pg_resetxlog would preferably be tool for more advanced stuff and similar utilities that are not as dangerous should have separate binaries using some of the functionality of pg_resetxlog as library and the other was with the string to uint64 parsing which is apparently not so easy to do portably. About the second one there was also separate discussion between Andres and Tom [2]. Here is series of patches that implements both the original feature and solves the issues mentioned above. 0001 - This patch splits the code of pg_resetxlog to common.c/h api and pg_resetxlog.c itself which does the program logic using the api. The only logical change in the XLogSegNoOffsetToRecPtr call is moved into main() function, which I think is ok as the main() does all the other ControlFile changes. All other changes should be just cosmetic in order to not rely on global static variables. 0002 - Adds pg_resetsysid utility which changes the system id to newly generated one. 0003 - Adds -s option to pg_resetxlog to change the system id to the one specified - this is separate from the other one as it can be potentially more dangerous. It also adds some defines that try to portably map pg_strtoint64 and pg_strtouint64 to the underlying implementations (strtol/strtoll/_strtoi64 and unsigned variants of those). It will leave the pg_strtoint64/pg_strtouint64 undefined if the platform does not support the functionality. Tom was unsure if there are such platforms on our supported list anymore. Which is why I also added 0004, that adds fall-back implementation of the two functions based on very slightly modified code from OpenBSD. This is here mostly in case buildfarm gets red after applying 0003 or we have reports from users that things got broken. [1] http://www.postgresql.org/message-id/539B97FC.8040806@2ndquadrant.com [2] http://www.postgresql.org/message-id/20140603144654.GM24145@awork2.anarazel.de -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: