2,363 karma · joined April 6, 2014
But for Postgres, you contact the developers. If your problems are costing you so much money why wouldn't you just hire a core developer on the Postgres team or hire EnterpriseDB on contract to work on your issues? They'll fix the bug, upstream the fix, and roll you updated packages you can push out to your servers. Not entirely different than working with Oracle, except you are working in the open source world.
Hints are bad. Next time you upgrade your database you may end up with worse performance due to other changes in the query planner. Once your data crosses a certain size threshold it may also start performing worse. They are unpredictable. You will never know when they could break. Using them is the wrong solution.
> - optimizer tracing
Hints are bad. They always have been. If you need hints your query planner is broken.
https://wiki.postgresql.org/wiki/OptimizerHintsDiscussion
Even Oracle Tom says DO NOT USE HINTS IN PRODUCTION! Report the bug to Oracle and let them fix it properly.
Things like:
* Java
* PHP
* Perl
* Python
* Ruby
* Apache
* Nginx
* Varnish
* MySqL
* Postgres
* Node.js
* etc
all run just fine on a Solaris-clone. Unless your app is using very specific kernel features it will probably work fine.It's actually quite easy to identify which should be allowed and which should not.
ICMP: 0,3,8,11 (echo reply, destination unreachable, echo, time exceeded)
ICMP6: 1,2,3,4,128,129,135,136 (unreachable, packet too big, time exceeded, parameter problem, echo request, echo reply, neighbor solicitation, neighbor advertisement)
See, that wasn't hard. These are the base requirements for you to have a reasonably functional IPv4 network, and the absolute minimum requirements for IPv6 to work properly.
There is no market for this product. Nobody wants it except a tiny fraction of the market who work in IT.
Tesla will make some cars for Tesla fans. Tesla will make billions selling key parts to everyone else. So they'll be the new Bosch of EVs, really.
Stop backporting fixes. You're forking the codebase.
Ship exactly what upstream provides.
Teach upstream projects how to do better release engineering if they're abandoning major releases to early or breaking API/ABI in a minor release.
Stop backporting fixes. You're forking the codebase.
edit: also stop incorrectly backporting security fixes and creating new CVEs. Seriously. Stop it.
Glad to see this software exists. Had to help build a poor man's version of it at a previous job and it was half baked due to lack of time.