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
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
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.
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.
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,
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 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,
> 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, 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
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,
+ 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
14 matches
Mail list logo
