Thank you for sharing
Best regards
Shenhao Wang
-Original Message-
From: Michael Paquier
Sent: Thursday, February 25, 2021 2:22 PM
To: Wang, Shenhao/王 申豪
Cc: Tom Lane ; Juan José Santamaría Flecha
; Emil Iggland ; PostgreSQL
Hackers
Subject: Re: BUG #15858: could not stat file
On Thu, Feb 25, 2021 at 06:07:06AM +, wangsh.f...@fujitsu.com wrote:
> I noticed that this modification only commit into master branch,
> there is still have a problem on 12.6 or 13.2 on Windows.
>
> Do you have a plan to backpatch this commit into REL_12_STABLE or
> REL_13_STABLE ?
The
"wangsh.f...@fujitsu.com" writes:
> Do you have a plan to backpatch this commit into REL_12_STABLE or
> REL_13_STABLE ?
https://www.postgresql.org/message-id/ycszix2a2ilsv...@paquier.xyz
regards, tom lane
Hi,
I noticed that this modification only commit into master branch,
there is still have a problem on 12.6 or 13.2 on Windows.
Do you have a plan to backpatch this commit into REL_12_STABLE or REL_13_STABLE
?
The commit:
On Mon, Oct 12, 2020 at 11:13:38AM -0400, Tom Lane wrote:
> Juan José Santamaría Flecha wrote:
>> Uhm, a good question indeed, forcing errno serves no purpose there.
>
> OK, changed.
Thanks!
--
Michael
signature.asc
Description: PGP signature
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> On Mon, Oct 12, 2020 at 5:27 AM Tom Lane wrote:
>> Michael Paquier writes:
>>> Why are we forcing errno=ENOENT here? Wouldn't it be correct to use
>>> _dosmaperr(GetLastError()) to get the correct errno?
>> Fair question. Juan, was
On Mon, Oct 12, 2020 at 5:27 AM Tom Lane wrote:
> Michael Paquier writes:
> > Why are we forcing errno=ENOENT here? Wouldn't it be correct to use
> > _dosmaperr(GetLastError()) to get the correct errno?
>
> Fair question. Juan, was there some good reason not to look at
> GetLastError() in
Michael Paquier writes:
> Why are we forcing errno=ENOENT here? Wouldn't it be correct to use
> _dosmaperr(GetLastError()) to get the correct errno?
Fair question. Juan, was there some good reason not to look at
GetLastError() in this step?
regards, tom lane
On Sat, Oct 10, 2020 at 08:34:48PM -0400, Tom Lane wrote:
> Nah, I fixed that hours ago (961e07b8c). jacana must not have run again
> yet.
Indeed, thanks. I have missed one sync here.
+ hFile = CreateFile(name,
+ GENERIC_READ,
+ (FILE_SHARE_READ |
Michael Paquier writes:
> We are visibly not completely out of the woods yet, jacana is
> reporting a compilation error:
Nah, I fixed that hours ago (961e07b8c). jacana must not have run again
yet.
regards, tom lane
On Sat, Oct 10, 2020 at 09:00:27PM +0200, Juan José Santamaría Flecha wrote:
> Great, thanks again to everyone who has taken some time to look into this.
We are visibly not completely out of the woods yet, jacana is
reporting a compilation error:
On Sat, Oct 10, 2020 at 7:43 PM Tom Lane wrote:
>
> I concur with Michael that it's inappropriate to make an end run around
> _dosmaperr() here. If you think that the DEBUG5 logging inside that
> is inappropriate, you should propose removing it outright.
>
> Pushed the rest of this.
>
Great,
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> If the file does not exist there is no need to call _dosmaperr() and log
> the error.
I concur with Michael that it's inappropriate to make an end run around
_dosmaperr() here. If you think that the DEBUG5 logging inside that
is
On Sat, Oct 10, 2020 at 2:24 PM Michael Paquier wrote:
>
> - _dosmaperr(GetLastError());
> + DWORD err = GetLastError();
> +
> + /* report when not ERROR_SUCCESS */
> + if (err == ERROR_FILE_NOT_FOUND || err ==
>
On Sat, Oct 10, 2020 at 01:31:21PM +0200, Juan José Santamaría Flecha wrote:
> Thanks for taking care of this. I see no problems in the build farm, but
> please reach me if I missed something.
Thanks for continuing your work on this patch. I see no related
failures in the buildfarm.
-
On Fri, Oct 9, 2020 at 10:22 PM Tom Lane wrote:
> Emil Iggland writes:
> > I tested the patch at hand, and it performs as expected. Files larger
> than 4GB can be imported.
>
> Thanks for testing!
>
Thanks for testing! +1
>
> I'd been expecting one of our Windows-savvy committers to pick
Emil Iggland writes:
> I tested the patch at hand, and it performs as expected. Files larger than
> 4GB can be imported.
Thanks for testing!
I'd been expecting one of our Windows-savvy committers to pick this up,
but since nothing has been happening, I took it on myself to push it.
I'll
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I tested the patch at hand, and it performs as expected. Files
On Thu, Sep 17, 2020 at 8:47 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
> On Thu, Sep 17, 2020 at 6:04 PM Tom Lane wrote:
>
>>
>> One thing I noticed, which is a pre-existing problem but maybe now
>> is a good time to consider it, is that we're mapping lstat() to be
>>
On Thu, Sep 17, 2020 at 6:04 PM Tom Lane wrote:
> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <
> juanjo.santama...@gmail.com> writes:
> > Thanks for the reminder. Please find attached a rebased version.
>
> (This hasn't shown up on -hackers yet, maybe caught in moderation?)
>
Thanks for
Em qui., 17 de set. de 2020 às 14:37, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Thu, Sep 17, 2020 at 9:46 AM Michael Paquier
> wrote:
>
>>
>> Could you send a rebase of the patch? Thanks!
>>
>
> Thanks for the reminder. Please find attached a rebased version.
>
Ranier Vilela writes:
> What's wrong with _stat64?
See upthread.
regards, tom lane
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> Thanks for the reminder. Please find attached a rebased version.
(This hasn't shown up on -hackers yet, maybe caught in moderation?)
I took a quick look through this. I'm not qualified to review the
actual Windows code in
On Thu, Sep 17, 2020 at 9:46 AM Michael Paquier wrote:
>
> Could you send a rebase of the patch? Thanks!
>
Thanks for the reminder. Please find attached a rebased version.
Regards,
Juan José Santamaría Flecha
0001-Support-for-large-files-on-Win32-v8.patch
Description: Binary data
On Mon, Oct 28, 2019 at 06:13:58PM +0100, Juan José Santamaría Flecha wrote:
> At this moment is missing review, so it is probably far from being
> commitable. Any attention is appreciated and might help pushing it forward.
> As a personal note, I have to check that is still applies before the
>
I assigned myself as a reviewer for this patch, as I hit this bug today and had
to perform a workaround. I have never reviewed a patch before but will try to
update within the next 5 days. I intend on performing "Implements Feature"
reviewing.
On Sat, Feb 29, 2020 at 9:40 AM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
> On Sat, Feb 29, 2020 at 12:44 AM Tom Lane wrote:
>
>>
>> The cfbot thinks this doesn't compile on Windows [1]. Looks like perhaps
>> a missing-#include problem?
>
>
> The define logic for
On Sat, Feb 29, 2020 at 12:44 AM Tom Lane wrote:
>
> The cfbot thinks this doesn't compile on Windows [1]. Looks like perhaps
> a missing-#include problem?
The define logic for _WIN32_WINNT includes testing of _MSC_VER, and is not
a proper choice for MSVC 2013 as the cfbot is showing.
Please
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> The latest version of this patch could benefit from an update. Please find
> attached a new version.
The cfbot thinks this doesn't compile on Windows [1]. Looks like perhaps
a missing-#include problem?
On Wed, Feb 5, 2020 at 12:47 PM Emil Iggland wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
>
The
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I ran into this problem when using psql.exe and copy command.
I have
On Mon, Oct 28, 2019 at 3:29 PM william allen
wrote:
> Hi - is this likely to be applied to an upcoming release? / How does a
> novice apply a patch..?
>
>
At this moment is missing review, so it is probably far from being
commitable. Any attention is appreciated and might help pushing it
; Magnus Hagander ;
PostgreSQL Hackers
Subject: Re: BUG #15858: could not stat file - over 4GB
Thanks for looking into this.
On Fri, Aug 23, 2019 at 11:49 PM Tom Lane wrote:
>
> Directly editing the configure script is Not Done ... or at least,
> such changes wouldn't survive the next
Thanks for looking into this.
On Fri, Aug 23, 2019 at 11:49 PM Tom Lane wrote:
>
> Directly editing the configure script is Not Done ... or at least,
> such changes wouldn't survive the next correctly-done configure
> update. You have to edit configure.in (or one of the sub-files in
> config/)
34 matches
Mail list logo
