mohanpedala

Table of Contents

• set -e, -u, -x, -o pipefail
• set -e
• set -x
• set -u
• set -o pipefail
• Setting IFS
• Original Reference

set -e, -u, -x, -o pipefail

antirez

RESP3 specification

Versions history:

• 1.0, 2 May 2018, Initial draft to get community feedbacks.

Background

The Redis protocol has served us well in the past years, showing that, if carefully designed, a simple human readable protocol is not the bottleneck in the client server communication, and that the simplicity of the design is a major advantage in creating a healthy client libraries ecosystem.

Yet the Redis experience has shown that after about six years from its introduction (when it replaced the initial Redis protocol), the current RESP protocol could be improved, especially in order to make client implementations simpler and to support new features.

antirez

• XGROUP CREATE <key> <groupname> <id or $>
• XGROUP SETID <key> <id or $>
• XGROUP DELGROUP <key> <groupname>
• XGROUP DELCONSUMER <key> <consumername>
• XPENDING <key> [<start> <stop>]
• XCLAIM <key> <group-name> <consumer-name> <min-idle-time> <ID-1> <ID-2> ...
• XACK <key> <ID-1> <ID-2> ...
• XREAD-GROUP (wrapper for XREAD that accepts GROUP and CONSUMER options)
• XINFO [CONSUMERS|GROUPS|STREAM|...]. STREAM is the default

antirez

Meltdown fix impact on Redis performances in virtualized environments

UPDATE: apparently kernel difference may have a serious impact, so I'll redo the test from scratch.

Test performed with AOF enabled, fsync policy 1 second, allowing the rewrites to be triggered.

Command lines used:

findepi

Source: https://gist.github.com/findepi/04c96f0f60dcc95329f569bb0c44a0cd .

quick build

./mvnw -T2C clean install -nsu -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true -Dair.check.skip-all=true -pl '!:trino-server-rpm,!:trino-docs,!:trino-proxy,!:trino-verifier,!:trino-benchto-benchmarks'

run Trino in a container, quickly

docker rm -f trino; docker run --rm -it --name trino -p 8080:8080 trinodb/trino:438

EshaMaharishi

Debugging MongoDB with gdb

gdb is a command line tool that you can use to examine the state of a (1) terminated or (2) running C or C++ process.

Background: Debugging a terminated process

A process can terminate (uncleanly) for a few reasons, such as triggering a segmentation fault, failing an invariant, or throwing an uncaught exception.

A binary can be compiled so that when a process terminates (uncleanly), the process produces a core dump, which is a file containing a "frozen" record of the state of all threads that existed in the process at the time it terminated.