Hi,
+ case POSTMASTER_STILL_STARTING:
+ write_eventlog(EVENTLOG_ERROR_TYPE, _("Timed out waiting for
server startup\n"));
+ pgwin32_SetServiceStatus(SERVICE_START_PENDING);
+ return;
Could this patch solve first post's problem [1] ?
I think
Hi,
Thank you for picking up this and I'm sorry for delay reply.
>> If wait_for_postmaster returns POSTMASTER_STILL_STARTING will it
>> be correct to set the status of windows service to SERVICE_START_PENDING ?
Yes, I think this is the best. Currently, I do not have good solution to change
Hi,
> I think we need to fix that script to either cope with missing semicolons,
> or at least complain about them. Too tired to look into how, right now.
I attached the patch which cope with missing semicolons.
Previous parse.pl find semicolon and dump data to buffer. When attached patch's
Hi,
I found ECPG's bug which SET xxx = DEFAULT statement could not be used.
[PROBLEM]
When the source code (*.pgc) has "EXEC SQL set xxx = default;", created c
program by ECPG has no " = default".
For example, "EXEC SQL set search_path = default;" in *.pgc will be converted
to "{
Hi, Meskes-san
> Thank you, committed.
Thank you!
By the way, I have found another bugs which are related to ECPG , so I will
post that later.
Regards,
Daisuke, Higuchi
Hi, Meskes-san
> Yes, I fully understand that. However, in doing so you accept
> statements that the backend later on rejects. The sole reason for
> the big ecpg grammar is to prevent those cases whenever possible.
Ok, I agree with you.
> > I also want to hear your opinion. I will change my
Hi, Meskes-san,
Thanks for your response!
> I beg to disagree, or I don't understand. Why would ecpg's changes to
> the statement be wrong nowadays?
I might confuse you, but it does not mean that it is wrong to reject CREATE
TABLE AS ... INTO ... syntax in ECPG.
My goal is to accept
Michael Paquier wrote:
> You should register this patch to the next commit fest in the section for bug
> fixes to not lose sight of it;
Thank you for picking up my post. I registered to the next CF.
> I haven't put much thoughts into what you propose here, but this status
> message is not
Hi,
This thread is inactive, but I want to solve this problem.
I think this problem rarely occurs in 10 or later version because of commit
[1]. Because "pg_ctl start -w" wait for only PID file creation. It means that
timeout is not occurred even if crash recovery takes a lot of times.
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>I took a quick look at this.
Thank you for review.
>So I think that we ought to unconditionally make the sqlda value's digit
>buffer look just like the one we're copying, even when ndigits = 0,
>which just requires removing the tests on ndigits.
I
From: Dmitry Dolgov [mailto:9erthali...@gmail.com]
>Also what's strange for me is that after applying your patches I still got the
>same output, not sure why:
Hmm... In my environment, the output was changed.
I also updated regression test and cfbot.cputube.org reports no problem now.
Do you
From: Dmitry Dolgov [mailto:9erthali...@gmail.com]
> Thanks for the patches. Unfortunately, judging from the cfbot.cputube.org they
> can't be applied anymore to the current master, could you please rebase them?
Thank you for checking!
I rebased patches on the current master, so I attach them.
Michael-san,
From: Michael Paquier [mailto:mich...@paquier.xyz]
>Does something like the patch attached help?
>This makes sure that st_size is set correctly for files with a size larger
>than 4GB.
Thank you for creating patch, but this does not solve current problem.
Of cause setting wrong
Hi,
This mail is about following bug report post:
https://www.postgresql.org/message-id/flat/153442391458.1505.9181095584291689853%40wrigleys.postgresql.org
When pg_dump has '--format=directory' option and the dump file size become
4GB over, the strange error message 'Unknown error' will be
14 matches
Mail list logo
