Comment by DannyBee | Hacker News Reader

Comment by DannyBee | Hacker News Reader

Parent Full thread

This saddens me.

Looking at this thread - the patch is obviously right. It doesn't matter about NFS, Linux, or any host of random crap people brought up. (I unfortunately suspect if you hadn't mentioned any of that, and just said "write doesn't guarantee full writes, this handles that" it may have gone better).

The documentation (literally on every system) is quite clear:

"The return value is the number of bytes actually written. This may be size, but can always be smaller. Your program should always call write in a loop, iterating until all the data is written."

(see https://www.gnu.org/software/libc/manual/html_node/I_002fO-P...)

Literally all documentation you can find about write on all systems that implement it clearly mentions it doesn't have to write all the bytes you ask it to.

Instead of saying "yeah, that's right", people go off in every random direction, with people arguing about your NFS mount options, what things can cause write to do that and whether they are possible[1] or they should care about them.

Sigh.

[1] spoiler alert: it doesn't matter. The API allows for this, you need to handle it.

I'm a bit confused by this perception of the thread. There was one person doubtful the patch is the right approach (Tom), but still offered concrete review comments (of actual issues that'd at the very least need to be documented in code comments). Others agreed that it's something that needs to be done.

> Instead of saying "yeah, that's right", people go off in every random direction, with people arguing about your NFS mount options, what things can cause write to do that and whether they are possible[1] or they should care about them.

Given that changing the mount option solved the immediate problem for the OP, I fail to see how it's random.

> [1] spoiler alert: it doesn't matter. The API allows for this, you need to handle it.

Sure, it's not like the return value was ignored before though. I agree retrying is the better response, but erroring out is a form of handling (and will also lead to retries in several places, just with a loop that's not tightly around the write()).

> Given that changing the mount option solved the immediate problem for the OP, I fail to see how it's random.

It's random because pretty much anyone could volunteer that opinion. By diagnosing the problem, making a patch and reaching out the author has already made their intention of fixing the problem clear. Unless it has been established that the problem isn't valid a workaround isn't really relevant.

Effective communication and exchange of ideas needs to have a good ratio between work and value. I used to frequent meetups where people would present projects with thousands of hours or work and priorities behind them. There would almost always be someone with less experience stating their "ideas" on what should be done instead. Eventually those people would end up talking among themselves where their ideas could flow freely without any restriction of actual work being done.

Experienced people provide value. They try to understand the problem, add their own experience to it and validate the work that has already been done. They make the problem smaller and closer to a solution. They don't, or shouldn't, casually increase the scope for little reason.

> It's random because pretty much anyone could volunteer that opinion. By diagnosing the problem, making a patch and reaching out the author has already made their intention of fixing the problem clear. Unless it has been established that the problem isn't valid a workaround isn't really relevant.

I'm baffled by this. Even if the fix had been immediately committed, the workaround of using nointr still would have been valuable, because a fixed version of postgres wouldn't immediately have been released.

You seem to argue in a way that entirely counteract your own later comments.

If someone spends x amount of work hours on something, that is what they want feedback on. They aren't looking for quick suggestions on other paths to explore. It isn't a brain storming session. It is work done being represented by an e-mail, code or a product. You are being presented with their theory for a solution. At some point something else might be relevant, but that isn't something to assume. The assumption should be that the person presenting have made their choices based on their situation.

It is often the same with software. Good feedback on software isn't random ideas, suggestions or feature requests that adds hundreds of hours of work on a whim. It is feedback that considers the work that has already been done. Anyone can come up with something else, especially in theory and with a blank slate. It doesn't really require anything other than an opinion. Hacker News certainly is proof of that.

Sure. Postgres misses a bug for years because they can't give even the most basic attention to someone on a mailing list, you know were you supposedly talk about things like bugs, and then defend the whole thing with excuses, rhetoric and further useless assumptions but I am the bad guy. This is exactly why people don't bother. Experience is just a liability these days in the "community". Companies maintain their own patches and conversations happens privately. Just sad to see such potential for accessibility wasted on arrogance. I guess it isn't really surprising though when everyone different already left.

You're basically just making shit up at this point. The most critical message in that thread contained pieces like

https://news.ycombinator.com/item?id=19128154

> You're basically just making shit up at this point.

You keep making my point. All you have is defensive, deflecting and rude comments. If you disagree with something it isn't hard to say "I disagree that x is y because z", like anyone interested in a discussion would. I will keep this in mind when interacting with the community, commissioning work or buying services related to Postgres comes across my desk.

Turns out people don't like one baseless accusation after another. I provided you with concrete references where review comments where made, where people agreed it was necessary. Yet you deny that happened, without refuting anything concrete.

Note that you're the one hiding behind at least the third sockpuppet account.

There is really no point in carrying on this conversation. I have made a number of argument and you are the one who have accused me of things. First I was contradicting myself, then making shit up and now of hiding behind sockpuppets. I haven't denied anything, you singled out a single sentence of my comments where you could snipe at me. The overall point, the discussion, and the repeated arguments I have made still stands.

I am not hiding anymore than any other anonymous account and for no other reason than time management and privacy. I shouldn't frequent hacker news for reasons previously stated, but sometimes I tell myself that the decent thing is to reply. Especially as many people won't. Now it is clear that this discussion isn't going anywhere so I won't be creating any other accounts or comments. To prevent any ambiguity this won't change.

No one suggested having an anonymous account is an issue. The issue is the account being a sockpuppet one.

> I agree retrying is the better response, but erroring out is a form of handling

In this case it is “a form” but that specific handling is provably wrong. That is important: everybody could have tried and proved again. Therefore just dismissing the correct handling and keeping the wrong one is, let me repeat, also provably wrong.

They were not ewview comments. They were arguments about where it ends. He's totalyl unwilling, and says you shouldn't run of of NFS. But then other people are, and are talking about mount options, when the problem clearly lies in the code not following the specs.

Why are:

> 1. If writes need to be retried, why not reads? (No, that's not an invitation to expand the scope of the patch; it's a question about NFS implementation.)

and

> 4. As coded, the patch behaves incorrectly if you get a zero return on a retry. If we were going to do this, I think we'd need to absorb the errno-munging currently done by callers into the writeAll function.

not review comments?

> when the problem clearly lies in the code not following the specs.

There were plenty of questions about how exactly the fix should look like below

https://www.postgresql.org/message-id/AD4A13A5-8778-4D94-BBB...

How's that not review?

You had me until you tried to justify bubbling the error instead of handling it at its source while possible.

That can be a correct response, for instance, if you have some sort of async i/o in place so you don't want to wait for a write that's not ready because you'll block.

Hm? I explicitly said that retries would be better?

If “write” expects you to always call it in a loop, I wonder why it wasn’t simply implemented so that it calls itself in a loop in the first place. Or at least provide a “writeAll” wrapper function.

What if the disk is literally unplugged after a partial write? (or the network cable unplugged, etc.)

Callers would still need to be informed that a partial write occurred and would need to do something about it.

When I call write(), it is typically already inside a bigger loop. If the system can't write my whole buffer right now, then I am happy to get the CPU back so I can do more work before trying again (and now I might have more data for it too).

This is literally the case study from worse is better :) https://www.jwz.org/doc/worse-is-better.html

Reply on news.ycombinator.com