Ryo Kanbayashi ryogrid

PostgreSQLのMVCCとレコードバージョンの可視性（１）

MVCCでの並行性制御とバージョンの見つけ方

PostgreSQLのMVCC（Multi-Version Concurrency Control）では、各トランザクションが見るべきレコードのバージョンを効率的に見つける仕組みとして、以下のような方法が使われています。

基本的な概念

Heap Tuple:

環境

WSL Ubuntu 20.04 (WSL2)
Docker version 24.0.5, build ced0996

Dockerイメージを作る

https://github.com/citusdata/docker/tree/4ea8a14e6db62adb903e698816588ded8f6ba402 をclone
ローカルにベースイメージを登録
- $ cd docker
- $ docker build -t citusdata/citus:12.1.5 .

The other day, I wrote an articleshown below, and I was thinking about whether I could prepare or have a machine that can run the server continuously.

NostrP2P: Pure P2P Distributed Microblogging System - ryo_grid's tech articles

Then, I remembered that there is an app called Termux that creates a unique Linux environment within an Android device. So, I thought it would be a good idea to use an old Android smartphone to run the server, and when I tried it, it worked perfectly!

(The idea behind Termux is that since Android is a type of Linux, by changing the root location of the file system in the shell shown to the user with chroot and placing the necessary files, you can create a unique Linux userland.)

First, referring to the sites below, install Termux via the Fdroid app.

Trying to enable (some) Nostr clients to connect to the NostrP2P server

The I/F for NostrP2P clients is REST, but it is necessary to insert a WS <-> REST bridge server for Nostr called Yonle/nhttp-adapter So, I tried to make it behave in a way that is compatible to some extent
- Some modifications were required to the NostrP2P server to achieve this...
- The specifications of nhttp -adapter were not compatible with NostrP2P's REST I/F, so I made some modifications ryogrid/nhttp-adapter

How to try

Client to use
- For now, I will use Snort because it seems to handle the display of posts and profile information well even if I respond to REQ in a careless manner
  - https://snort.social
procedure

Concept
- Microblogging system by all user's contribution
  - Problem NostrP2P focus on: Existing distributed SNS (Mastdon, Nostr, Bluesky, etc.) place a big works on the server operators, but there is no insentive for that
Other points
- A system centered on broadcasting using the gossip protocol (messaging is handled by the weaveworks/mesh library)
- Focus on ease of implementation and simplicity over performance and data consistency
  - In the end, it may come down to wanting to save man-hours, but if you put a complicated mechanism into this kind of system, it's difficult to make it work stably
  - For the above reasons, we will not adopt structuring mechanisms such as DHT (for the time being)
- Make the whole thing fuzzy (ex: event data loss is acceptable as long as it is a small amount)
Compared to other decentralized SNS, it is a pure P2P architecture that is difficult to operate with decent performance, but it can be managed by making a

正直、精査していないので普通に穴があるかもしれない。
GitHub Repo

コンセプト
- 利用者皆の貢献により構成されるシステム
  - 課題感: 既存の分散SNS（Mastdon、Nostr、Bluesky、etc..）は言うて、サーバ運用者にかかる負荷が高く、その割に見返りもない
その他のポイント
- gossipプロトコルによるブロードキャストを軸にしたシステム（メッセージングはweaveworks/mesh ライブラリが担う）
- パフォーマンスやデータの一貫性より実装の容易さとシンプルさに重点を置く
結局のところは省工数にしたいという理由に落ちるかもしれないが、この手のシステムで複雑な仕組みを入れると安定して動くようにするのが大変

	<!DOCTYPE html>
	<html>
	<head>
	<meta charset="utf-8">
	<title>フルーツ合成パズルゲーム</title>
	<!-- Matter.js を CDN 経由で読み込み -->
	<script src="https://cdnjs.cloudflare.com/ajax/libs/matter-js/0.19.0/matter.min.js"></script>
	<style>
	body { margin: 0; font-family: sans-serif; }
	/* 上部の情報＆操作エリア */

	// Code generated by protoc-gen-go. DO NOT EDIT.
	// versions:
	// protoc-gen-go v1.32.0
	// protoc v3.19.1
	// source: np2p_event.proto

	package schema

	import (
	protoreflect "google.golang.org/protobuf/reflect/protoreflect"

	package main

	import (
	"bufio"
	"fmt"
	"log"
	"math/rand"
	"os"
	"strconv"
	)

	// Bostr config

	module.exports = {
	// Server listener [Required]
	address: "127.0.0.1",
	port: "8080",

	// Clusters.
	// 0 will make bostr run clusters with available parallelism / CPU cores.
	clusters: 1,