DEV Community: Peter Paravinja

SIMD in GO

Peter Paravinja — Wed, 15 Apr 2026 19:50:06 +0000

When Go 1.26 released - they released something interesting under the experimental tag.

SIMD: Single instruction multiple data

Now the problem that modern cpus face is that cpu clock rate has stagnated.

So if we take scalar approach to executing instruction. For example float multiplication.

Here we take two numbers and we multiply them right - which is fine and dandy.

But designers long ago (literally) asked a question "What if we could theoretically widen the operation so that developers could place more data on one instruction?"

And they did!

We got:

XMM0–XMM15 which has the width of 128 bits
YMM0–YMM15 which has the width of 256 bits
ZMM0–ZMM31 which has the width of 512 bits

Lets take 256 bits for example...

We have a float which is 4 bytes == 32 bits which means we have place 8 floats into 256 bits wide instruction right?

SIMD shines on data-parallel workloads — operations where you apply the same transformation to every element of a large array.

Image processing, audio DSP, physics simulations, matrix math, cryptography, text search (finding bytes in a buffer), and vector similarity search all fit this pattern.

Go announced fantastic news that they are working on SIMD standard library and they have put it out for testing under the experimental flag.

It works only for amd64 architecture for now.

I prepared a short demonstration but we are using XOR which is heavily used in cryptography.

oriiyx / simd-presentation

SIMD in Go — Cryptographic XOR Benchmark

Demonstrates Go 1.26's simd/archsimd package applied to the core operation behind stream ciphers (AES-CTR, ChaCha20, OTP): XOR of a plaintext buffer with a keystream.

What's benchmarked

Implementation	Strategy	Instructions
`XORScalar`	Byte-by-byte loop	`XOR r8, r8`
`XORSimd256`	32 bytes/iteration via AVX2	`VPXOR ymm, ymm, ymm`
`XORSimd256Unrolled`	128 bytes/iteration (4× unrolled)	4× `VPXOR ymm` per iter

Run (macOS with Docker)

./run.sh

Expected speedup

On x86_64 (emulated via Docker on Apple Silicon, real numbers will be higher on native):

Small payloads (256B): ~5-10× faster with SIMD
Large payloads (1MB+): ~15-25× faster with SIMD (memory-bandwidth limited)

On native x86 hardware (e.g. Emerald Rapids Xeon), expect even better numbers since VPXOR has 1-cycle latency and can retire 3 per cycle on ports p0/p1/p5.

uops.info reference

For the presentation, show the Emerald Rapids measurements for:

VPXOR (YMM, YMM, YMM) — the instruction behind Uint8x32.Xor() - link
VAESENC (XMM, XMM,…

View on GitHub

where we can first checkout how the scalar operation would look like:

func XORScalar(destination, plaintext, keystream []byte) {
    for i := range plaintext {
        destination[i] = plaintext[i] ^ keystream[i]
    }
}

Pretty straight forward!

Now lets look at SIMD Vector optimized code

// XORSimd256 applies a repeating keystream over plaintext using 256-bit (32-byte)
// SIMD vectors. Each VPXOR instruction XORs 32 bytes in a single cycle.
//
// This means the CPU can XOR 96 bytes per clock cycle with 256-bit vectors.
func XORSimd256(destination, plaintext, keystream []byte) {
    n := len(plaintext)
    i := 0

    // Process 32 bytes at a time using AVX2 VPXOR
    for i+32 <= n {
        p := archsimd.LoadUint8x32((*[32]byte)(plaintext[i : i+32]))
        k := archsimd.LoadUint8x32((*[32]byte)(keystream[i : i+32]))
        r := p.Xor(k)

        // r holds the XOR result in a SIMD register (a CPU vector register, not memory).
        // .Store() writes those 32 bytes from the register back into the destination slice in main memory.
        // Without it, the result would just be discarded when the register gets reused.
        r.Store((*[32]byte)(destination[i : i+32]))
        i += 32
    }

    // Handle remaining bytes (< 32) with scalar fallback
    for ; i < n; i++ {
        destination[i] = plaintext[i] ^ keystream[i]
    }
}

And the results were stunning! Even as I ran it on a Macbook where we lost some performance due to architecture miss-match!

You can run it for yourselves and test the results out!

Here are mine:

peter-paravinja.me

Bottomline is that Go dev team is working on something great I think. It is a step in the right direction in my opinion! We don't need custom for loops in my opinion...

But for those sweet low level optimisations where you squeeze everything out of the hardware - this is a great step forward!

Debug Go with Air

Peter Paravinja — Thu, 05 Jun 2025 19:21:10 +0000

State before and after

Before:
You're stuck in the loop of hell - constantly stopping your Go web server, recompiling, and starting it again just to see if your template changes work. It's painful.

After:
Now you've got the good stuff - live reloading that actually works WITH proper debugging. No more compile-restart dance. You can set breakpoints, step through your code like a human being, AND you're still logging the important bits.

Your development flow is smooth. Changes happen instantly. You can actually understand what your code is doing instead of guessing. You've grown as an engineer because you're being mindful about your tooling - and that makes you write better code that has a longer use cycle.

☁️ Air tool

If you want to develop web application that is served with Go you usually (very soon) find out that you do not want to compile your Go code to see the changed templates! This eventually leads you to use live reloading to speed up development.

Go has a popular tool for that called air.

Now this article isn't aimed at how you setup everything from scratch. If you wish for content on that topic because you think it's missing after googling it - comment on this post and I'll mix something up.

Debug

I love developing with debugger. I just can't process everything that is happening... I need to walk through code step by step which helps me understand it more deeply.
Do NOT skip logging tho... I have realised that some developers only program with logging - which leaves loads of logs behind which can be useful while debugging in live application - WHILE the other half only uses debugger and never logs anything due to being able to step into the code.

Use both!

I have improved as an engineer due to being mindful about these pillars.

Debug setup with Air

Delve is my go-to debugger for Go - so you need to have it installed.
Air (obviously) is also required for this to work.

Full example is uploaded on my repository.

After we initialise go project with go mod init we follow it up with initing air project with air init.

This creates a new file .air.toml with default values that air uses when you run the watcher.

We can create a simple main.go file inside the root project which we will use for testing our debugger.

package main

import "fmt"

func main() {
    a := 1
    b := 2
    c := a + b
    fmt.Printf("%d + %d = %d\n", a, b, c)
}

We can test the setup if we run air which should output the following:

❯ air

  __    _   ___  
 / /\  | | | |_) 
/_/--\ |_| |_| \_ v1.62.0, built with Go go1.24.2

watching .
!exclude tmp
building...
running...
1 + 2 = 3
Process Exit with Code 0

Now lets use delve to actually create a binary which we can debug!

Inside .air.toml we have to modify cmd and full_bin properties:

[build]
  cmd = "CGO_ENABLED=0 go build -gcflags=all=\"-N -l\" -o ./tmp/main ."
  full_bin = "dlv --listen=127.0.0.1:2345 --headless=true --api-version=2 --accept-multiclient exec ./tmp/main"
...

Explaining -gcflags=all="-N -l";
-N disables compiler optimizations
-l disables function inlining
all= applies these flags to all packages being built

Mostly we just ask compiler to not optimize things.

If we go to air's repository we can see inside air_example.toml how they explain full_bin

# Customize binary, can setup environment variables when run your app.
full_bin = "APP_ENV=dev APP_USER=air ./tmp/main"

in our case we actually tell it to run the dlv debugger instead of just running the binary! Important param is this: --listen=127.0.0.1:2345 which we will have to setup in the IDEs to listen on this port for any information that debugger is sending.

If we run air now - we see it prints another line:
API server listening at: 127.0.0.1:2345 which means we are successfully listening with delve!

IDE setup with goland & vscode

Goland

I will attach screenshots from my IDE.
But general things that you need to do is add a new Debug configuration of type Go Remote - presets are generally setup to work with you out of the box!

So now if we set a breakpoint in the main() method then click debug icon and then run air we should see the breakpoint being triggered!

Success!

VSCode

We need to add information inside the launch.json

your-project/
├── .vscode/
│   └── launch.json
...

We add the configuration that is very similar to settings in GoLand:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Connect to Air Debugger",
      "type": "go",
      "request": "attach",
      "mode": "remote",
      "remotePath": "${workspaceFolder}",
      "port": 2345,
      "host": "127.0.0.1",
      "showLog": true,
      "trace": "verbose",
      "logOutput": "rpc"
    }
  ]
}

Try it out!

Give feedback!

Thanks for reading! :)

Adding Request ID to Go's requests

Peter Paravinja — Thu, 29 May 2025 12:37:26 +0000

Why

Why would you use request IDs?
Request IDs can help you diagnose problems by correlating log entries for a given web request across many log entries or files.
It is a way to track and "brand" the request that travels across your application(s).

Tools

xid tool that helps us create a new unique id
chi lightweight router

Creating a ctx utility

First we create an utility function that helps us set and get request values in (or out of) context.

I usually save it inside <root project>/utils/ctx/ctx.go, but whatever floats your boat.

package ctx

import (
    "context"
)

const keyRequestID key = "requestID"

type key string

func RequestID(ctx context.Context) string {
    requestID, _ := ctx.Value(keyRequestID).(string)

    return requestID
}

func SetRequestID(ctx context.Context, requestID string) context.Context {
    return context.WithValue(ctx, keyRequestID, requestID)
}

Creating middleware function

This is the middleware function that we will plug in the chi router.

What we're doing is first checking if X-Request-ID is set - and we use that ID to 'drag it' across our request. We can then append it to every log statement that we do. Every (not really sure if every) logging go library enables adding more context to log entry - so we just append it to everything.

If it doesn't exist - we just create a new unique ID.

Whichever requestID we get - we set use our set ctx function from before.

With our enriched ctx we just call next serve HTTP with enriched ctx.

package middleware

import (
    "net/http"

    "github.com/rs/xid"

    ctxUtil "github.com/example/example-repo/utils/ctx"
)

const requestIDHeaderKey = "X-Request-ID"

func RequestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        ctx := r.Context()

        requestID := r.Header.Get(requestIDHeaderKey)
        if requestID == "" {
            requestID = xid.New().String()
        }

        ctx = ctxUtil.SetRequestID(ctx, requestID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

Router and route example

Just a simple example of a chi router with a route that shows how we actually pull the request ID out of context and use it as a value inside the route.

package main

import (
    "net/http"

    "github.com/go-chi/chi/v5"
    "github.com/example/example-repo/api/middleware"
    ctxUtil "github.com/example/example-repo/utils/ctx"
)

func main() {
    chiRouter := chi.NewRouter()
    chiRouter.Use(middleware.RequestID)

    chiRouter.Get("/", func(w http.ResponseWriter, r *http.Request) {
        reqID := ctxUtil.RequestID(r.Context())
        w.Write([]byte(reqID))
    })
}

Implementing log rotate in Go

Peter Paravinja — Wed, 28 May 2025 10:25:42 +0000

Tools

lumberjeack is the primary tool we will be using
(optional)zerolog package providing logger interface

Implementation with log package

Normal log package is okay if you're looking for something simple yet effective.

We create multiwriter io so that we can see output in the stdout and at the same time have the writer write to .log file.

As you can see we created the file writer with the lumberjack package where we defined a few variables.

Filename - takes the full path. It uses -lumberjack.log in os.TempDir() if you do not set it.
MaxSize - maximum size in megabytes of the log file before it gets rotated
MaxBackups - maximum number of old log files to retain
MaxAge - maximum number of days to retain old log files based on the timestamp encoded in their filename
Compress - determines if we compress the rotated log files with gzip

package logger

import (
    "fmt"
    "io"
    "log"
    "os"
    "path/filepath"

    "gopkg.in/natefinch/lumberjack.v2"
)

func New(logPath string) (*log.Logger, error) {
    if err := os.MkdirAll(filepath.Dir(logPath), 0755); err != nil {
        return nil, fmt.Errorf("create log directory: %w", err)
    }

    fileWriter := &lumberjack.Logger{
        Filename:   logPath,
        MaxSize:    10,   // megabytes
        MaxBackups: 5,    // number of backups to keep
        MaxAge:     30,   // days
        Compress:   true, // compress old logs
    }

    // Create a multi-writer that writes to both stdout and the file
    var writers []io.Writer
    writers = append(writers, os.Stdout)
    writers = append(writers, fileWriter)

    multiWriter := io.MultiWriter(writers...)

    logger := log.New(multiWriter, "", log.LstdFlags|log.Lshortfile)

    return logger, nil
}

Implementation with zerolog package

Same implementation but more powerful - here we can defined if we're debugging the application and change the level that zerolog is sending the logs through. In this example we have base level of info and debug level (if active) of trace.

package logger

import (
    "fmt"
    "os"
    "path/filepath"

    "github.com/rs/zerolog"
    "gopkg.in/natefinch/lumberjack.v2"
)

func New(isDebug bool, logPath string) (*zerolog.Logger, error) {
    logLevel := zerolog.InfoLevel
    if isDebug {
        logLevel = zerolog.TraceLevel
    }

    if err := os.MkdirAll(filepath.Dir(logPath), 0755); err != nil {
        return nil, fmt.Errorf("create log directory: %w", err)
    }

    fileWriter := &lumberjack.Logger{
        Filename:   logPath,
        MaxSize:    10,   // megabytes
        MaxBackups: 5,    // number of backups to keep
        MaxAge:     30,   // days
        Compress:   true, // compress old logs
    }

    zerolog.SetGlobalLevel(logLevel)
    multi := zerolog.MultiLevelWriter(zerolog.ConsoleWriter{Out: os.Stdout}, fileWriter)
    logger := zerolog.New(multi).With().Timestamp().Logger()

    return &logger, nil
}

That is it!
Pretty simple and very effective!
If you have very large logs with an application I suggest you give it a try!

Migrations with Go & Postgres

Peter Paravinja — Tue, 27 May 2025 14:01:40 +0000

Implementing migrations into your Golang application?

This can be a source of some information while you search around for implementation details on how-to tackle it in Go systems.

Tools

Golang migrate tool: golang-migrate
PGX - driver for postgres: pgx
GoDotEnv - reading .env: godotenv

Project structure

cmd/
   migrate/
           main.go
           migrations/
                      <generated migration files>

How to create a new migration file

While checking out golang-migrate repo you probably noticed that we need to install a CLI tool first so we have access to the tool from your local machine.

Lets break down what the migrate create does by reading the official help docs:

create [-ext E] [-dir D] [-seq] [-digits N] [-format] [-tz] NAME
           Create a set of timestamped up/down migrations titled NAME, in directory D with extension E.
           Use -seq option to generate sequential up/down migrations with N digits.
           Use -format option to specify a Go time format string. Note: migrations with the same time cause "duplicate migration version" error.
           Use -tz option to specify the timezone that will be used when generating non-sequential migrations (defaults: UTC).

  -digits int
        The number of digits to use in sequences (default: 6) (default 6)
  -dir string
        Directory to place file in (default: current working directory)
  -ext string
        File extension
  -format string
        The Go time format string to use. If the string "unix" or "unixNano" is specified, then the seconds or nanoseconds since January 1, 1970 UTC respectively will be used. Caution, due to the behavior of time.Time.Format(), invalid format strings will not error (default "20060102150405")
  -seq
        Use sequential numbers instead of timestamps (default: false)
  -tz string
        The timezone that will be used for generating timestamps (default: utc) (default "UTC")

Important one is seq - this has some implications in how you want to track your migration sequence. If you are doing a solo project it doesn't matter that much... but with a team it actually does matter.

If you for example deploy a migration with seq number 10 and teammate working in another branch deployed a migration yesterday with the same number 10... your migration wont run.

Then we can actually start with creating a new up and down migration sql files.

migrate create -ext sql -dir cmd/migrate/migrations -seq create_users

This will create 2 files:
cmd/migrate/migrations/000001_create_users.down.sql
cmd/migrate/migrations/000001_create_users.up.sql

How is migrations storing the data

Migrations when running the first time will create it's own table in the database called schema_migrations with 2 columns version(bigint) and dirty(boolean).
Version holds the information which version was last ran.
Dirty holds information about current state of the last migration ran.

You could make a sql mistake and you ran the migration... happens right?

Lets say you ran a migration with number 4 and you had a mistake in the sql.

The single row in the table would change to 4 (version) and true (dirty).

You would then have to manually change the version back to 3 and dirty to false. And retry! This time without any mistake hopefully :)

Running the migrations

Well we created the migrations - we know how the tool is tracking it - now we just need to write the script that will actually handle the changes.

For this example lets just create UP and DOWN migrations.

We need to edit our cmd/migrate/main.go which will contain all the logic.

You need to have defined DB_USER, DB_USER, DB_PASSWORD, DB_HOST, DB_PORT and DB_NAME in your .env file.

package main

import (
    "context"
    "database/sql"
    "errors"
    "fmt"
    "log"
    "os"

    "github.com/golang-migrate/migrate/v4"
    "github.com/golang-migrate/migrate/v4/database/postgres"
    _ "github.com/golang-migrate/migrate/v4/source/file"
    "github.com/jackc/pgx/v5/pgxpool"
    "github.com/joho/godotenv"
)

func main() {
    if err := godotenv.Load(); err != nil {
        fmt.Println("No .env file found")
    }

    ctx := context.Background()
    fmt.Println("Starting database migration process")

    connectionString := fmt.Sprintf("postgres://%s:%s@%s:%s/%s?sslmode=disable",
        os.Getenv("DB_USER"),
        os.Getenv("DB_PASSWORD"),
        os.Getenv("DB_HOST"),
        os.Getenv("DB_PORT"),
        os.Getenv("DB_NAME"))

    dbConfig, err := pgxpool.ParseConfig(connectionString)
    if err != nil {
        log.Fatalf("Failed to parse database config: %v", err)
    }

    pool, err := pgxpool.NewWithConfig(
        ctx,
        dbConfig,
    )
    if err != nil {
        log.Fatalf("Failed to create database connection pool: %v", err)
    }
    defer pool.Close()

    fmt.Println("Database connection established successfully")

    db, err := sql.Open("postgres", connectionString)
    if err != nil {
        log.Fatalf("Unable to connect to database: %v", err)
    }

    // Create migration instance
    driver, err := postgres.WithInstance(db, &postgres.Config{})
    if err != nil {
        log.Fatal(err)
    }

    // Point to your migration files. Here we're using local files, but it could be other sources.
    m, err := migrate.NewWithDatabaseInstance(
        "file://cmd/migrate/migrations",
        "postgres",
        driver,
    )
    if err != nil {
        log.Fatal(err)
    }

    cmd := os.Args[len(os.Args)-1]
    if cmd == "up" {
        if err := m.Up(); err != nil && !errors.Is(err, migrate.ErrNoChange) {
            log.Fatalf("Migration up failed: %v", err)
        }
        fmt.Println("Migration up completed successfully")
    }

    if cmd == "down" {
        if err := m.Down(); err != nil && !errors.Is(err, migrate.ErrNoChange) {
            log.Fatalf("Migration down failed: %v", err)
        }
        fmt.Println("Migration down completed successfully")
    }
}

That is it!

You can run it with the following commands:
Up:
go run cmd/migrate/main.go up

Down:
go run cmd/migrate/main.go down

You can put it in the makefile if you want to:

migrate-up: ## Database migration up
    @go run cmd/migrate/main.go up

migrate-down: ## Database migration down
    @go run cmd/migrate/main.go down

Hope it helps someone out!

Go zerolog setup with pgx

Peter Paravinja — Sun, 20 Apr 2025 20:19:35 +0000

Overview

Golang currently holds really special place in my heart ❤️

But since I'm doing mostly user facing oriented projects I usually need a database.

My weapon of choice is Postgres (like many others).

But I really want to know how queries are doing.

I am a freak and want to optimize things.
Now since I sometimes don't think ahead enough - I get "burned" and I found out that looking at my logs in terminal
usually catch this. So I want to add zerolog to pgx so that I can see traces and how long a query took to execute. This
way I can catch it easily.

9:08PM TRC Query args=[] commandTag="DELETE 0" duration=4.653 pid=123 sql="-- name: CleanupExpiredTokens :exec\nDELETE\nFROM refresh_tokens\nWHERE expires_at < CURRENT_TIMESTAMP\n   OR revoked_at IS NOT NULL\n"

Why I like zerolog?
I started with normal golang log API and was having okay experience. But started sniffing around the web to see what
other people were using.

At the same time I was developing my first bigger hobby project and started to hit the "wall" of project structure "
smell".

I didn't like the way the project was structured.

I have a pretty okay nose for figuring out that something isn't at the best level... I have a tougher time figuring out
a solution for that problem on my own.

So I started looking on the web and found out a
very nice public repository depicting a project structure that I
really liked.

I really liked it - good job dumindu and thanks for sharing the idea!

Afterwards I checked hashicorp who I think are really next level company in golang space... dear god - things they have
open source... the amount of knowledge someone can gain from them by just reading and implementing ideas from them...
Amazing! Even
the comment out thoughts
are a very nice touch!

Anyway... lets talk about zerolog and pgx working somehow hand in hand!

This is more of a general idea what you can do with it and a few tips on how to use it.

It's not a general defacto way or anything... just my own implementation that I liked.

Let's start with dependencies I guess.

I am working with versions:
zerolog: 1.33.0
pgx: v5 5.7.1

go get -u github.com/rs/zerolog/log
go get github.com/jackc/pgx/v5

Now I personally like to split the depth of logging into 2 separate concerns. One is for local, development and staging
environments - the other is for production.

Now this is totally up to you.

I like to triple tests stuff before publishing to production, so I don't usually include traces there. Buuuuut you
theoretically could - its just... depends how much logs can your production take. If you have high traffic... you will
fill them big boy log files up.

What we'll do now is create a function that will create a new instance of zerolog with some configs that we want

package logger

import (
    "fmt"
    "os"
    "path/filepath"

    "github.com/rs/zerolog"
)

func New(isDebug bool, logPath string) (*zerolog.Logger, error) {
    logLevel := zerolog.InfoLevel
    if isDebug {
        logLevel = zerolog.TraceLevel
    }

    if err := os.MkdirAll(filepath.Dir(logPath), 0755); err != nil {
        return nil, fmt.Errorf("create log directory: %w", err)
    }

    runLogFile, err := os.OpenFile(
        logPath,
        os.O_APPEND|os.O_CREATE|os.O_WRONLY,
        0664,
    )
    if err != nil {
        return nil, fmt.Errorf("open log file: %w", err)
    }

    zerolog.SetGlobalLevel(logLevel)
    multi := zerolog.MultiLevelWriter(zerolog.ConsoleWriter{Out: os.Stdout}, runLogFile)
    logger := zerolog.New(multi).With().Timestamp().Logger()

    return &logger, nil
}

now we want 2 level writers - one for the console standard out and one for appending to the log file.

We can set global level - for production we want Information level events - and for debug environments we lower that
down to trace so we see everything!

But this config depends entirely up to you!

The last line
logger := zerolog.New(multi).With().Timestamp().Logger()

Creates a new logger and we return a pointer to that logger.
Alternative solution would be that we create a struct and assign the pointer to a property inside the struct. We could
add the pointer to *os.File as-well so we can do operations on it (closing it for example).

After that we instantiate this new beautiful piece of abstract code:

l, _ := logger.New(conf.Server.Debug, "logs/app.log")

!!deal with your errors boys and girls!!

Ok now we'll create a new Trace Logger!

We need to satisfy this daddy interface

type Logger interface {
    Log(ctx context.Context, level LogLevel, msg string, data map[string]any)
}

After that we'll use this new struct and method Log and append him on this pgx5 struct:

// /github.com/jackc/pgx/v5@v5.7.1/tracelog/tracelog.go:135
type TraceLog struct {
    Logger   Logger
    LogLevel LogLevel

    Config           *TraceLogConfig
    ensureConfigOnce sync.Once
}

Let's bring it all together now!

package logger

import (
    "context"

    "github.com/jackc/pgx/v5/tracelog"
    "github.com/rs/zerolog"
)

type zerologPgxLogger struct {
    logger zerolog.Logger
}

func (l zerologPgxLogger) Log(ctx context.Context, level tracelog.LogLevel, msg string, data map[string]interface{}) {
    logEvent := l.logger.With().Fields(data).Logger()
    zerologLevel := l.logger.GetLevel()
    if zerologLevel == zerolog.TraceLevel {
        level = tracelog.LogLevelTrace
    }

    switch level {
    case tracelog.LogLevelTrace:
        logEvent.Trace().Msg(msg)
    case tracelog.LogLevelDebug:
        logEvent.Debug().Msg(msg)
    case tracelog.LogLevelInfo:
        logEvent.Info().Msg(msg)
    case tracelog.LogLevelWarn:
        logEvent.Warn().Msg(msg)
    case tracelog.LogLevelError:
        logEvent.Error().Msg(msg)
    default:
        logEvent.Info().Msg(msg)
    }
}

func NewTraceLogger(zeroLog zerolog.Logger, isDebug bool) *tracelog.TraceLog {
    logLevel := tracelog.LogLevelInfo
    if isDebug {
        logLevel = tracelog.LogLevelTrace
    }

    return &tracelog.TraceLog{
        Logger:   zerologPgxLogger{logger: zeroLog},
        LogLevel: logLevel,
        Config: &tracelog.TraceLogConfig{
            TimeKey: "duration",
        },
    }
}

so inside Log method we basically decide what we want to do with the message that we get and data that we get - for this example we're just logging message that we get and we route it to correct log level event.

The only thing that is really important is the

TimeKey: "duration"

This is how we'll get duration of the query! I think this is really, really important, and I am sad that out of the box the time value gets overwritten with time when the query took place (that is important as well! But we need both!!!!)

https://github.com/jackc/pgx/pull/2098 <- say thanks ❤️

Next comes creating a multi query which means satistfying another interface daddy, this time:

// QueryTracer traces Query, QueryRow, and Exec.
type QueryTracer interface {
    // TraceQueryStart is called at the beginning of Query, QueryRow, and Exec calls. The returned context is used for the
    // rest of the call and will be passed to TraceQueryEnd.
    TraceQueryStart(ctx context.Context, conn *Conn, data TraceQueryStartData) context.Context

    TraceQueryEnd(ctx context.Context, conn *Conn, data TraceQueryEndData)
}

Why MultiQuery?

Because mby in the future you'll want to implement OpenTelemetry Tracer (https://github.com/exaring/otelpgx) - why should I stop you with just standard logging - you can do so much more!!! I am feeling observability slowly becoming "my thing". I will dive deeper! I will go so fu*?ing deep!

Anyway...

package logger

import (
    "context"

    "github.com/jackc/pgx/v5"
)

type MultiQueryTracer struct {
    Tracers []pgx.QueryTracer
}

func (m *MultiQueryTracer) TraceQueryStart(ctx context.Context, conn *pgx.Conn, data pgx.TraceQueryStartData) context.Context {
    for _, t := range m.Tracers {
        ctx = t.TraceQueryStart(ctx, conn, data)
    }

    return ctx
}

func (m *MultiQueryTracer) TraceQueryEnd(ctx context.Context, conn *pgx.Conn, data pgx.TraceQueryEndData) {
    for _, t := range m.Tracers {
        t.TraceQueryEnd(ctx, conn, data)
    }
}

Basically we're just ranging over the 2 traces and telling them to do their thing - nothing else... just a smoll wrapper :)

Now we have all the components!

We'll just go and combine them.

func main() {
    // prepare everything
    l, _ := logger.New(conf.Server.Debug, "logs/app.log")
    traceLogger := logger.NewTraceLogger(*l, conf.Server.Debug)
    m := logger.MultiQueryTracer{
        Tracers: []pgx.QueryTracer{
            // open telemetry tracer: https://github.com/exaring/otelpgx
            otelpgx.NewTracer(),
            // logger
            traceLogger,
        },
    }

    l.Info().Msg("Initializing database connection")
    dbString := fmt.Sprintf(fmtDBString, conf.DB.Host, conf.DB.Username, conf.DB.Password, conf.DB.DBName, conf.DB.Port)
    l.Info().
        Str("host", conf.DB.Host).
        Int("port", conf.DB.Port).
        Str("database", conf.DB.DBName).
        Msg("Connecting to database")

    dbConfig, err := pgxpool.ParseConfig(dbString)
    if err != nil {
        l.Fatal().
            Err(err).
            Msg("Failed to parse database config")
        return
    }
    dbConfig.ConnConfig.Tracer = &m

    pool, err := pgxpool.NewWithConfig(
        ctx,
        dbConfig,
    )
    if err != nil {
        l.Fatal().
            Err(err).
            Msg("Failed to create database connection pool")
        return
    }
    defer pool.Close()
    l.Info().Msg("Database connection established successfully")
}

This is it actually... you should have a fully functional trace logging into your log file and console output!

Let's dive into it even more sometime in the future! 😍

Background Process Communication in CLI Applications

Peter Paravinja — Sun, 20 Apr 2025 20:16:33 +0000

Context

Currently, I am working on implementing a custom CLI application in Go at work which is a first for me in this scope.

One of the challenges which I want to blog about today is communication between the daemon and user-facing CLI part.

For simple context - lets say that daemon is a process which transforms an object that user submits via interacting with a command and does something with it - writes some updates since it takes some time to actually finish it and we want to give some feedback to the user while it's doing the work.

When I think about it, large amount of software which I usually use throughout the day requires users to create and edit configuration files to communicate with the software.
Once you edit the configuration file, it is required to restart the service which parses the configuration file and validates it at the startup. Communication during the running process is usually not viable. These are services like Docker, Nginx, SQLC,...

But some (actually quite a lot :P) software requires modification during the process.

But how do we communicate between processes?

One big question that I had during the development was how to implement communication between 2 different processes.

After searching the web about how other people tackled this problem I found out several possibilities:

file: write data to a file which multiple processes can access
shared memory: one block of memory reserved by the processes used for exchanging information
message queue: self evident - queue of messages

And many more!
Read a general overview on the wiki page for a generally okay general read.

Embedded database

This was my first thought due to reading about bbolt. I really wanted to give it a try and went on to prototype a quick working example.
Everything went pretty butter smooth - I really liked that I could use the same codebase for interacting with myself. Then it hit me during the testing... bbolt actually creates a binary on the disk - how would 2 processes actually open the same file at the same time... I thought about creating 2 different files and one process would only open it for reading while the other would have write permissions... but I didnt like the idea anymore... It wasnt clean anymore...

RPC

Going back to things I know... I recently went over a bookbook where we replicated an orchestration software (think kubernetes) and I saw that for interacting with the software you actually implement a web server.
But I implemented millions of web servers due to being a web developer... but I thought that the design would be ok. But I wanted to try out RPC and decided on that in the end. Basic REST api would work as well.

Strategy

First thing is that working on random environments we can't have a reserved port for the web server so we need to actually initiate the server with port 0 which signals OS to find any available port and bind it for us.

We can detect which port OS binds for us via the interface.

Now how do we communicate this random port to the other process?

I decided to actually use the .pid file which would include both the process id and the allocated port : and when I wanted to communicate I would just first check if daemon is actually running and use the port.

Conclusion

I'm slightly disappointed that I didn't actually try and commit to something completely new due to having time constraints for the project... I ended up using the same solution I use for most daily work with server communications. Feels like I am using one tool for everything... unfortunately it actually felt good in the end after I implemented it so I am not really regretting anything. RPC feels okay as well.