Re: psql client does not handle WSAEWOULDBLOCK on Windows

2024-08-06 Thread Ning
can be properly handled on both Windows and other platforms. To reproduce the issue, I used the following version of Postgres and MIT Kerberos: PostgreSQL version: 16.3 MIT Kerberos Version 4.1 Operating System: Windows 11 Visual Studio 2022 On Tue, Jul 30, 2024 at 4:47 PM Ning wrote: > >

psql client does not handle WSAEWOULDBLOCK on Windows

2024-07-31 Thread Ning
and other platforms. The patch file is attached to this email, please review and consider merging it to the main code library. Thanks, Ning Wu fix-windows-non-blocking-socket.patch Description: Binary data

Re: Possible race condition in pg_mkdir_p()?

2019-07-31 Thread Ning Yu
move the tests (cool!), 2) simplify PathNameCreateTemporaryDir() and other callers. The EEXIST handling will be put in a separate patch so depends on the reviews we could accept or drop it easily. Best Regards Ning

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
ng the presented patches, but it does not have enough value to be > merged. Yes, that's why we put the testing module in a separate patch from the fix, feel free to ignore it. In fact ourselves have concerns about it ;) Best Regards Ning > -- > Michael

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 12:41 PM Michael Paquier wrote: > > On Wed, Jul 31, 2019 at 12:26:30PM +0800, Ning Yu wrote: > > Could I double confirm with you that you made a clean rebuild after > > applying the patches? pg_mkdir_p() is compiled as part of libpgport.a, > > a

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 12:11 PM Andres Freund wrote: > > Hi, > > On 2019-07-18 16:17:22 +0800, Ning Yu wrote: > > This seems buggy as it first checks the existence of the dir and makes the > > dir if it does not exist yet, however when executing concurrently a > >

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 12:04 PM Michael Paquier wrote: > > On Tue, Jul 30, 2019 at 06:22:59PM +0800, Ning Yu wrote: > > In fact personally I'm thinking that whether could we replace all uses of > > MakePGDirectory() with pg_mkdir_p(), so we could simplify > >

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Tue, Jul 30, 2019 at 4:04 PM Michael Paquier wrote: > > On Tue, Jul 23, 2019 at 02:54:20PM +0800, Ning Yu wrote: > > MakePGDirectory() is also called in TablespaceCreateDbspace(), EEXIST is > > considered as non-error for parent directories, however as it considers > >

Re: Possible race condition in pg_mkdir_p()?

2019-07-22 Thread Ning Yu
ever as it considers EEXIST as a failure for the last level of the path so the logic is still correct, we do not add a final stat() check for it. Best Regards Ning On Thu, Jul 18, 2019 at 4:57 PM Michael Paquier wrote: > On Thu, Jul 18, 2019 at 04:17:22PM +0800, Ning Yu wrote: > >

Possible race condition in pg_mkdir_p()?

2019-07-18 Thread Ning Yu
ng with current code logic, because when the statusdir is a file the errno is also EEXIST, but it can pass the check here. Even if we fix pg_mkdir_p() by following the `mkdir -p` way the errno check here is still wrong. Best Regards Ning

Re: New Defects reported by Coverity Scan for PostgreSQL

2018-07-31 Thread Ning Yu
To make coverity happy we might be able to suppress this false alarm by adding a line like below: ``` /* coverity[SWAPPED_ARGUMENTS] */ lseg_closept_lseg(result, l2, l1); ``` >From my point of view it's better to also put some comments for humans to understand why we are passing l1 and l2 in reve