Re: Safeguards against incorrect fd flags for fsync()

2025-06-24 Thread Michael Banck
Hi, On Wed, Jun 25, 2025 at 08:36:01AM +0900, Michael Paquier wrote: > On Tue, Jun 24, 2025 at 07:51:08AM +0200, Michael Banck wrote: > > I got it working, I had to rebuild gnumach with --enable-apic in order > > to get HPET. With that, the regular build-farm checks (check/ > > installcheck in con

Re: Safeguards against incorrect fd flags for fsync()

2025-06-24 Thread Michael Paquier
On Tue, Jun 24, 2025 at 07:51:08AM +0200, Michael Banck wrote: > I got it working, I had to rebuild gnumach with --enable-apic in order > to get HPET. With that, the regular build-farm checks (check/ > installcheck in contrib, src/test/regress and src/test/isolation) pass > without patches to tests

Re: Safeguards against incorrect fd flags for fsync()

2025-06-24 Thread Tom Lane
Michael Banck writes: > Is removing the debug_parallel_query=on configuration for HEAD a valid > mode of operation for a buildfarm animal? I ran the tests 10 times in a > row without issues today. Sure, especially on slower machines. It's pretty much owner's option whether to use that.

Re: Safeguards against incorrect fd flags for fsync()

2025-06-24 Thread Michael Banck
Hi, another update: On Wed, Jun 11, 2025 at 09:24:24PM +0200, Michael Banck wrote: > So it seems the low-resolution timer is the only functional issue right > now. I upgraded my VM to current Debian unstable, but unfortunately that > did not increase the timer resolution is hoped, maybe some more

Re: Safeguards against incorrect fd flags for fsync()

2025-06-11 Thread Michael Banck
On Tue, Jun 10, 2025 at 09:09:35PM -0400, Tom Lane wrote: > Still, I'd like to be closer to having a working Hurd buildfarm member > before we take a portability risk that would only benefit Hurd. I've spent some more time on this, here's the status beyond make check: 1. The pg_stat_statements en

Re: Safeguards against incorrect fd flags for fsync()

2025-06-10 Thread Tom Lane
Michael Paquier writes: > We don't have a trace of O_ACCMODE in the tree, and POSIX defines it. > I'm wondering how the buildfarm would react on that, but perhaps > that's fine on !WIN32. It's hard to say with all the hosts there, at > least the CI is OK. POSIX has required O_ACCMODE in fcntl.h

Re: Safeguards against incorrect fd flags for fsync()

2025-06-10 Thread Michael Paquier
On Tue, Jun 10, 2025 at 12:26:48PM +0200, Michael Banck wrote: > Well O_RDONLY might historically be 0 almost everywhere, but it is > defined to 1 on the GNU system [1]: > > |#define O_RDONLY0x0001 /* Open read-only. */ > > So there, the comparison with 0 does not work and initdb (a

Re: Safeguards against incorrect fd flags for fsync()

2025-06-10 Thread Michael Banck
Hi, one more thing: On Tue, Jun 10, 2025 at 12:26:48PM +0200, Michael Banck wrote: > The better way might be to mask the flags with O_ACCMODE and then just > check what you want, like in the attached. I forgot to mention it in the patch, but Samuel Thibault reviewed the patch and suggested impro

Re: Safeguards against incorrect fd flags for fsync()

2025-06-10 Thread Michael Banck
Hi, On Wed, Oct 09, 2019 at 03:26:40PM +0900, Michael Paquier wrote: > After the set of issues discussed here, it seems to me that it would > be a good thing to have some safeguards against incorrect flags when > opening a fd which would be used for fsync(): > https://www.postgresql.org/message-id

Re: Safeguards against incorrect fd flags for fsync()

2019-11-25 Thread Michael Paquier
On Mon, Nov 25, 2019 at 04:18:33PM +0900, Michael Paquier wrote: > Thanks for the review. I'll look at that pretty soon. Tweaked a bit the comment block added, and committed. Thanks Mark for the input! -- Michael signature.asc Description: PGP signature

Re: Safeguards against incorrect fd flags for fsync()

2019-11-24 Thread Michael Paquier
On Sun, Nov 24, 2019 at 08:18:38PM -0800, Mark Dilger wrote: > Ok, it passes all regression tests, and I played around with > intentionally breaking the code to open file descriptors in > the wrong mode. The assertion appears to work as intended. > > I'd say this is ready for commit. Thanks for

Re: Safeguards against incorrect fd flags for fsync()

2019-11-24 Thread Mark Dilger
On 11/24/19 6:53 PM, Mark Dilger wrote: On 11/24/19 6:28 PM, Michael Paquier wrote: On Thu, Nov 07, 2019 at 01:57:57PM -0800, Mark Dilger wrote: The code and comments don't clearly indicate what you have said in the email, that you are verifying directories are opened read-only and files

Re: Safeguards against incorrect fd flags for fsync()

2019-11-24 Thread Mark Dilger
On 11/24/19 6:28 PM, Michael Paquier wrote: On Thu, Nov 07, 2019 at 01:57:57PM -0800, Mark Dilger wrote: The code and comments don't clearly indicate what you have said in the email, that you are verifying directories are opened read-only and files are opened either read-write or write-only.

Re: Safeguards against incorrect fd flags for fsync()

2019-11-24 Thread Michael Paquier
On Thu, Nov 07, 2019 at 01:57:57PM -0800, Mark Dilger wrote: > The code and comments don't clearly indicate what you have said in the > email, that you are verifying directories are opened read-only and files are > opened either read-write or write-only. I'd recommend changing the comments > a bit

Re: Safeguards against incorrect fd flags for fsync()

2019-11-07 Thread Mark Dilger
On 10/8/19 11:26 PM, Michael Paquier wrote: Hi all, After the set of issues discussed here, it seems to me that it would be a good thing to have some safeguards against incorrect flags when opening a fd which would be used for fsync(): https://www.postgresql.org/message-id/16039-196fc97cc05e1.