431–440 of 756 posts
Earlier quoted context omitted.
i may be missing context, but shared memory across processes, without ipc?
There's nothing special about threads vs processes in Linux. mmap works the same, the challenge is to map the same file. You can share a path, pass a file descriptor via fork or unix domain socket, among other techniques.
Hey author here. Wasn't expecting to see this up. To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture. I'm now working on a new, not yet published version of pgrust that inc…
Earlier quoted context omitted.
Yes, BSD licenses are compatible with AGPL meaning BSD licensed code can be combined with AGPL licensed code while complying with both licenses. However, it does not give you permission to relicense the BSD code (or derivative works) as AGPL. The author is free to license any new code they write as AGPL, however the license for the machine translated code is another question. If it is considered a derivative work (wh…
IANAL, but calling this "relicensing" is technically inaccurate. It is more precise to describe it as adding constraints. When you combine your work with upstream code, you are layering additional requirements (like copyleft) onto the existing attribution requirements. The original limitations remain in effect. Therefore, it is not a shift from A to B, but rather from A to A ∪ B. This practice is entirely compatible…
The BSD license only explicitly permits the author “to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement.”
By default, the owner of a protected work retains all rights not conveyed to someone else. Changing the license isn’t one of the enumerated activities, and so I think there’s a case to be made that it’s not permitted.
Now if the author wants to claim it’s a new work, as opposed to a modification (which opens up a big bag of issues by itself because this was AI-authored), then the author can license it however they see fit.
Earlier quoted context omitted.
> A very long time ago, there was once a feature called "Data Blades" which tanked a commercial database vendor. I have no idea what this is and a web search turned up Harbor Freight woodworking tools.
My first web search (data blades) turned up harbor freight woodworking tools. Then I made a second web search: data blades database. That turned up some ibm database software module technology which I assume is what's being discussed.
Earlier quoted context omitted.
> A very long time ago, there was once a feature called "Data Blades" which tanked a commercial database vendor. I have no idea what this is and a web search turned up Harbor Freight woodworking tools.
I think it's this: https://www.ibm.com/docs/en/informix-servers/15.0.x?topic=co... And what you found seems to be "Dado", not "Data".
Earlier quoted context omitted.
A thread per connection is a almost always the correct decision for performance, but by choosing a process per connection, postgres is able to let you load whatever sketchy extensions you want. Worst case you crash the process, not the database. It would be nice if you could strike a balance so a segfaul in the extension only crashes a small percentage of connections, not the whole thing.
If it's a choice between performance and being able to "safely" run sketchy extensions, I'd rather have performance.
2664 "unsafe {", 1835 "unsafe fn". This is completely unsafe. It doesn't look like a rewrite that understands what's actually going on or how the architecture should be redesigned to take advantage of Rust strengths. Instead, it looks like an AI generated transpilation with extensive use of raw pointers.
Note that most of the unsafes are confined to the parser which was generated by running c2rust over the Postgres parser. The Postgres parser is itself generated from yacc/bison, so I decided to port it over mechanically rather than idiomatically. If there's particular unsafes that you think are egregious, let me know.
Hey author here. Wasn't expecting to see this up. To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture. I'm now working on a new, not yet published version of pgrust that inc…
A thread per connection is a almost always the correct decision for performance, but by choosing a process per connection, postgres is able to let you load whatever sketchy extensions you want. Worst case you crash the process, not the database. It would be nice if you could strike a balance so a segfaul in the extension only crashes a small percentage of connections, not the whole thing.
It does this because it can’t possibly know whether the dying process did bad things to the shared memory pool.
Hey author here. Wasn't expecting to see this up. To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture. I'm now working on a new, not yet published version of pgrust that inc…
Earlier quoted context omitted.
There's nothing special about threads vs processes in Linux. mmap works the same, the challenge is to map the same file. You can share a path, pass a file descriptor via fork or unix domain socket, among other techniques.
That induces disk I/O overhead (even if it somehow doesn't impact IPC performance)