Re: PostgreSQL Service on Windows does not start if data directory given is relative path

Поиск
Список
Период
Сортировка
От Rajeev rastogi
Тема Re: PostgreSQL Service on Windows does not start if data directory given is relative path
Дата
Msg-id BF2827DCCE55594C8D7A8F7FFD3AB7713DDB9742@SZXEML508-MBX.china.huawei.com
обсуждение исходный текст
Список pgsql-hackers

On Tue, Jan 12, 2014 David Rowley wrote:

>>I have found a case that PostgreSQL as win32 service does not start, if the data directory given as relative path.

>>Error observed in this case is:

>>                                “The PostgreSQL on Local Computer started and then stopped”.

 >>This may happen because relative path given will be relative to path from where service is registered but

>>the path from where WIN32 service execution gets invoked may be different and hence it won’t be able

>>to find the  data directory.

 >>I have fixed the same by internally converting the relative path to absolute path as it is being done for executable file.

 >Hi,

>I've not quite got around to testing this yet, but I think the patch is a good idea as I can see that I can use a relative path when I start postgres.exe from the command line, I guess the behaviour should likely be the same when installed as a windows

> service.

 

Thanks for reviewing and providing the first level of feedback.

 

>So, I've just been looking over this patch and I'm just wondering about a few things:

 

>In pgwin32_CommandLine you declare dbPath, it looks like you could declare this in the scope of; if (pg_config) 

 

            Yes I have declared the same in the scope of “if (pg_config) “

 

>In find_my_abs_path you're making a call to StrNCpy, I know you likely just used find_my_exec as an example here, but I'd say the use of StrNCpy is not really needed here and is a bit of a waste of cycles. I'd rather see strlcpy being used as strncpy

> will needlessly zero the remaining buffer space.

            Yes you are right, it is much better to use strlcpy instead of StrNCpy. I have modified the patch. 

 

>Also in find_my_abs_path, I'm just wondering if the cwd variable is really needed, I think you could just use retpath each time and it would also save a little bit of copying that's done in join_path_components(). By the looks of it you can just call  

> join_path_components(retpath, retpath, inpath). Perhaps some people would disagree, but I'm not really seeing the harm in it and it saves some copying too.

            Yes I am also convinced with your suggestion. It really avoid one level of copy.

            I have seen that the similar mechanism is used in many places where join_path_components() is called. So I think it should be OK to use in our case also.

            I have made the necessary changes for the same.

 

I have attached the changed patch. Please provide your further feedback, if any.

 

Thanks and Regards,

 

Kumar Rajeev Rastogi

 

 

 

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: plpgsql.consistent_into