shalvah

It was taking too long for Bucardo to import certain tables. Decided to look into it by querying the new database to check what was so slow.

First step was checking pg_stat_activity:

> select query, query_start, wait_event from pg_stat_activity where usename = 'bucardo_replicator';

/* Bucardo 5.6.0 */COPY public.some_table("id","...","...","created_at","updated_at") FROM STDIN | 2024-05-02 15:36:13.816752+00 | IO::DataFileRead

shalvah

Bucardo is unfortunately not very good at reporting its progress. This guide details the most important parts.

Note: This mostly assumes you're using Bucardo with onetimecopy=1

There are three major states of Bucardo we care about:

1. Truncating a table on the new database
2. Doing the initial copy from old to new database
3. Live replication mode from old to new (aka “delta mode”)

shalvah

# A man needs to get three items across a river:
#   a goose, a big bag of beans, and a fox.
#
# If left alone unsupervised with the beans, the goose will eat the beans.
# If left alone unsupervised with the goose, the fox will eat the goose.
# Only the man and one other item are all that will fit in the boat.
#
# Can the man get across the river with their goose, beans, and fox?

require 'set'

shalvah

A Primer on Ruby Method Lookup

Forked from @damien-roche's gist. Here's my addendum.

Method lookup is a simple affair in most languages without multiple inheritance. You start from the receiver and move up the ancestors chain until you locate the method. Because Ruby allows you to mix in modules and extend singleton classes at runtime, this is an entirely different affair.

I will not build contrived code to exemplify the more complicated aspects of Ruby method lookup, as this will only serve to confuse the matter. If you are having trouble following method lookup in your own programs, it is not because Ruby has strange rules (it does), it is because your code is too tangled.

When you pass a message to an object, here is how Ruby finds what method to call:

shalvah

<?php

$orderList = [
  'Jake',
  'Scully' => [
    'pet',
    'friend' => [
      'Michael',
      'Merissa',
    ],

shalvah

// Note: this uses Node.js' `Buffer`, so it might not work in the browser
// You can use a polyfill or write yours.

const RED = [0xFF, 0, 0, 0xFF]; // R, G, B, A
const GREEN = [0, 0xFF, 0, 0xFF];

function serialize(val, outputBytes = []) {
    if (typeof val === "string") {
        serializeString(val, outputBytes);
    } else {

shalvah

require 'algorithms'
require 'fiber'

class EventLoop
  def initialize
    @queue = TaskQueue.new
  end

  def run(&entrypoint)
    entrypoint.call

shalvah

// Make sure to run with node --expose-gc

// Control script for the circular references test
// We set circular references, but we remove them explicitly before removing the parent object
// On my machine, memory usage increases by around +1kB at first, then "stabilises" and increases more slowly
(async () => {
  while(1) {
    let a = {};
    let b = {};
    a.f = b;

shalvah

/**
 * Simple promise implementation. Doesn't have all the features of the actual Promise API, + assumes you know what you're doing.
 */
class ToyPromise {
    constructor(cb) {
        this.state = 'pending';
        this._promiseResult = undefined;
        this._fulfillmentCallbacks = [];
        this._rejectionCallbacks = [];

shalvah

When using legacy (heirarchical) activity IDs:

Format is described here: https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md#id-format

When using W3C format Activity IDs: