[syndicated profile] planet_postgresql_feed

High availability for PostgreSQL is often treated as a single, big, dramatic decision: “Are we doing HA or not?”

That framing pushes teams into two extremes:

  • a “hero architecture” that costs a lot and still feels tense to operate, or
  • a minimalistic architecture that everyone hopes will just keep running.

A calmer way to design this is to treat HA and DR as layers. You start with a baseline, then add specific capabilities only when your RPO/RTO and budget justify them.

Let us walk through the layers from “single primary” to “multi-site DR posture”.

Start with outcomes

Before topology, align on three things:

1. Failure scope

  • A database host fails
  • A zone or data center goes away
  • A full region outage happens
  • Human error

2. RPO (Recovery Point Objective)

  • We can tolerate up to 15 minutes of data loss
  • We want close to zero

3. RTO (Recovery Time Objective)

  • We can be back in 30 minutes
  • We want service back in under 2 minutes

Here is my stance (and it saves money!): You get strong availability outcomes by layering in the right order.

Layer 0 – Single primary (baseline, no backups)

This is the baseline: one PostgreSQL primary in one site. All reads and writes go to it.

That is it. No replicas. No archiving. No backup flow in this model.

What you get:

  • simplicity
  • low cost
  • low operational overhead

What it means operationally:

  • Your “recovery plan” is effectively “rebuild and rehydrate from wherever you can” (which might be
[...]
[syndicated profile] planet_postgresql_feed

The community met on Wednesday, March 4, 2026 for the 7. PostgreSQL User Group NRW MeetUp (Cologne, ORDIX AG). It was organised by Dirk Krautschick and Andreas Baier.

Speakers:

  • Robin Riel
  • Jan Karremans

PostgreSQL Berlin March 2026 Meetup took place on March 5, 2026 organized by Andreas Scherbaum and Sergey Dudoladov.

Speakers:

  • Andreas Scherbaum
  • Tudor Golubenco
  • Narendra Tawar
  • Kai Wagner

Kai Wagner wrote about his experience at the meetup PostgreSQL Berlin Meetup - March 2026

Andreas Scherbaum wrote a blog posting about the Meetup.

SCALE 23x (March 5-8, 2026) had a dedicated PostgreSQL track, filled by the following contributions

Trainings:

  • Elizabeth Christensen
  • Devrim Gunduz
  • Ryan Booz

Talks:

  • Nick Meyer
  • Tristan Ahmadi
  • Alexandra Wang
  • Christophe Pettus
  • Max Englander
  • Magnus Hagander
  • Bruce Momjian
  • Robert Treat
  • Payal Singh
  • German Eichberger
  • Jimmy Angelakos
  • Justin Frye

SCALE 23x PostgreSQL Booth volunteers:

  • Bruce Momjian
  • Christine Momjian
  • Gabrielle Roth
  • Jennifer Scheuerell
  • Magnus Hagander
  • Devrim Gunduz
  • Elizabeth Garret Christensen
  • Robert Treat
  • Pavlo Golub
  • Phill Vacca
  • Jimmy Angelakos
  • Erika Miller
  • Aya Griswold
  • Alex Wood
  • Donald Wong
  • Derya Gumustel
vitus_wagner: My photo 2005 (Default)
[personal profile] vitus_wagner

Любая информационная технология в начале своего развития крайне энергоёмка, а потом потребление энергии снижается на несколько порядков.

Вот например, радиосвязь. Возьмем воспоминания Эрнста Кренкеля «Мои позывные RAEM». Когда Кренкель в середине 20-х начинал свою карьеру полярного радиста, на станции Маточкин Шар стоял пятикиловаттный передатчик. И дальность действия была такая, что радиограммы в Архангельск приходилось передавать через два промежуточных пункта.

А всего через десятилетие, во второй половине 30-х тот же Кренкель с Земли Франца-Иосифа связывался с экспедицией Бэрда в Антарктиде. Используя всего лишь 200-ваттный передатчик.

Или возьмем компьютеры, обычные, в начале XXI века уже вездесущие. Свою первую компьютерную программу я написал в 1983 году для БЭСМ-6. Эта машина занимала огромный зал и потребляла 50 киловатт электричества. А при этом памяти у неё было 128К малинных слов (по 48 бит), то есть меньше мегабайта, и быстродействие всего миллион операций в секунду. Через десять лет у меня на столе стояла машина с несколько большими возможносятми и блоком питания. по-моему на 250 ватт. Правда разрядность у её CPU была малость поменьше, всего 32 бита. Но математический сопроцессор имел регистры по 80 бит. А сейчас 64-разрядное вычислительное устройство с памятью в миллиард 64-разрядных слов (8Гб) мы носим в кармане и еще расстраиваемся что больно прожорливое, больше суток от одной зарядки аккумулятора работать не хочет. (при том что энергию там на самом деле жрет не вычислительное устройство а передатчик, которому надо постоянно поддерживать связь сотой)

Можно еще рассмотреть спутниковую связь и сравнить первые станции "Орбита" 60-х годов с антеннами в несколько десятков метров диамером и современные карманные спутниковые телефоны.

В общем, похоже это универсальное явление — если надо только обрабатывать информацию, то никаких теоретических ограничений для снижения энергопотребления нет.

Поэтому современные прожорливые датацентры - это детство ИИ. По мере того как технология будет развиваться и взрослеть энергозатраты будут снижаться, как снизили энергозатраты на математические вычисления от мейнфреймов 60-х годов до десктопов 90-х.

[syndicated profile] planet_postgresql_feed

In the previous article we covered how the PostgreSQL planner reads pg_class and pg_statistic to estimate row counts, choose join strategies, and decide whether an index scan is worth it. The message was clear: when statistics are wrong, everything else goes with it.

Streaming replication provides bit-to-bit replication, so all replicas share the same statistics with primary server.
But there was one thing we didn't talk about. Statistics are specific to the database cluster that generated them. The primary way to populate them is `ANALYZE` which requires the actual data.

PostgreSQL 18 changed that. Two new functions: pg_restore_relation_stats and pg_restore_attribute_stats write numbers directly into the catalog tables. Combined with pg_dump --statistics-only, you can treat optimizer statistics as a deployable artifact. Compact, portable, plain SQL.

The feature was driven by the upgrade use case. In the past, major version upgrades used to leave pg_statistic empty, forcing you to run ANALYZE. Which might take hours on large clusters. With PostgreSQL 18 upgrades now transfer statistics automatically. But that's just the beginning. The same logic lets you export statistics from production and inject them anywhere - test database, local debugging, or as part of CI pipelines.

The problem

Your CI database has 1,000 rows. Production has 50 million. The planner makes completely different decisions for each. Running EXPLAIN in CI tells you nothing about the production plan. This is the core premise behind RegreSQL. Catching query plan regressions in CI is far more reliable when the planner sees production-scale statistics.

Same applies to debugging. A query is slow in production and you want to reproduce the plan locally, but your database has different statistics, and planner chooses the predictable path. Porting production stats can provide you that snapshot of thinking planner has to do in production, without actually going to production.

pg_restore_relation_stats

The first of functi

[...]
[syndicated profile] planet_postgresql_feed
On 5th of March, 2026, we had the PostgreSQL March Meetup in Berlin. Zalando hosted it again, and like last time it was four regular talks in two parallel tracks. Attendee number was a bit smaller compared to last time, likely because the Meetup was announced late. The Meetup took place in the Hedwig-Wachenheim-Straße in Berlin, right around the corner from the Uber Arena and East Side Gallery. Zalando has an office here, and the first floor is a large meeting and conference area.
[syndicated profile] dxdt_ru_feed

Posted by Александр Венедюхин

Типовая спутниковая навигационная система (GNSS, типовой пример – GPS) работает в модели, когда приёмник “смотрит” на спутники, а спутники – приёмник не видят: спутники лишь излучают сигнал с метками. Приёмник, на основании полученных данных о местоположении спутников, определяет собственное положение в пространстве (относительно спутниковой системы координат, естественно).

Такой подход выглядит пассивным, в том смысле, что приёмник только принимает сигнал, но никак не участвует в формировании навигационного поля: не передаёт запросов, не отвечает подтверждениями. То есть, в теории, если считать, что GPS-приёмник полностью пассивный (это не всегда так с приёмниками радиосигналов), то схема получается достаточно скрытной: собственные координаты поступают, но не уходят – нельзя узнать положение приёмника (через навигационную систему). Но координаты нужно вычислять, и делать это нужно относительно того, как “видны” спутники с точки зрения приёмника (его антенны/антенн, если говорить совсем строго). Это сопряжено с проблемами спуфинга и помехопостановки: приёмник может принимать дефектный/поддельный сигнал, не принимать ничего вовсе, кроме помех, а сама внешняя система – не знает про такую ситуацию конкретного приёмника, поэтому никак не может содействовать в улучшении его сигнального положения (например, в сетях мобильной связи с условным обозначением 5G, это не так – зная положение приёмника и его “электромагнитную ситуацию”, можно резервировать лучи для этого прёмника).

Вообще, вспоминая сети подвижной радиосвязи, можно представить источник навигационной информации уровня GNSS, работающий по схеме, обратной к только что описанной, но при этом всё равно “пассивной” для потребителя – “только на приём”. Местоположение потребителя геолокации определяет сеть, а потом передаёт этому потребителю его координаты, как они видны с точки зрения сети, в готовом виде. Вот только местоположение потребителя определяется не по исходящему от него специальному радиосигналу, а по сопутствующим признакам: визуально, по возмущениям вокруг, по помехам, источником которых является этот потребитель, ещё как-то.

Например, представьте, что у нас есть много космических спутников на низкой орбите и некоторый летательный аппарат в атмосфере, который нуждается в коррекции своих коордиант. Часть спутников видит этот аппарат, потому что, предположим, спутники как раз предназначены для наблюдения за такими летательными аппаратами и оснащены ИК-сенсорами, телескопами и радарами. Теперь эти спутники вычисляют географические координаты той точки, где видят аппарат, и передают их в сторону аппарата, например, по радио (но тут возможны и варианты – см. ниже). Естественно, это просто вариант давно и широко известной коррекции “по месту”, которая выполняется специальным наблюдателем. Только тут всё автоматическое и работает на базе сети спутников.

Что поменялось? Исходная система-источник геопривязки осталась спутниковой (это важно – спутники могут покрывать сигналом всю территорию Земли), аппарат остался с приёмником, но теперь приёмник получает сразу координаты, их не нужно вычислять, и это координаты с точки зрения внешней навигационной системы. Этой внешней системе гораздо сложнее поставить помеху с земли, а тем более, “подспуфить” сигнал. Но, как и в исходном варианте, можно задавить помехой нисходящий канал на стороне приёмника – последний не сможет принимать координаты, поступающие из внешней системы. Другое дело, что для передачи координат достаточно канала с малой пропускной способностью, и не требуется целая схема кодов для передачи “таймингов” с наносекундной точностью.

Заметьте, впрочем, что синхронное время всё равно требуется: иначе не получится определить задержку, чтобы задать отставание видимых внешних координат от реальных локальных. Но, во-первых, создать очень устойчивый к помехам канал для низкоскоростной передачи данных от распределённой космической системы в сторону приёмника с известными координатаминесколько проще, чем сконструировать сравнимый по помехозащищённости универсальный сигнал для универсального же приёма без привязки к координатам. Во-вторых, передавать координаты опять могут несколько спутников, выделенных специально для этого, но результат приёма сигнала от каждого из спутников уже не будет влиять на определение координат, как в случае “обычной” GNSS. Так что требования к точности синхронизации часов – ниже. В обычной GNSS потеря сигнала от одного спутника может полностью изменить общую картину и точность, – в том числе, можно потерять синхронное время, – в описанной же схеме со “скачиванием” собственных координат – достаточно получить их от одного любого спутника системы. Так что общая устойчивость явно улучшается. Самое занятное, что геолокационные сведения могут транслироваться на некоторый прокси-узел, который уже передаст их непосредственно получателю по оптической связи – это, например, та или иная лазерная система: атмосферная или даже волоконная. Подобные оптические системы хорошо защищены и от помех, и от прослушивания.

Вообще, что касается прослушивания, то вряд ли можно отнести к полезным эффектам онлайн-трансляцию координат наблюдаемых системой аппаратов в открытый эфир. Прочитать координаты может всякий, а не только приёмник на аппарате, которому эти данные адресованы. Да, тут необходимо использовать криптографические методы защиты: если приёмник и внешняя навигационная система согласовали общий секрет, то данные можно зашифровать. Вот только для динамического согласования без предрварительного распределения ключей потребуется передача данных от приёмника в сторону навигационной системы, а это полностью уничтожает “пассивные свойства”, когда потребитель навигации работает только на приём. Если же ключи раздавать по приёмникам заранее, то, в дополнение к технической проблеме надёжного распределения ключей, получаем административную проблему возможной утечки. Но, так или иначе, можно устроить криптографическую часть так, что, если ключи индивидуальные, то утечка конкретного ключа приводит лишь к компрометации онлайн-координат конкретного приёмника. А вот от демаскирующего эффекта направленного радиосигнала, транслируемого в сторону приёмника со спутников – отделаться посложнее. Однако, имея секретные ключи, и тут можно применить сигнальную схему с весьма малой вероятностью обнаружения.

Еженедельник OSM 815

Mar. 8th, 2026 02:10 pm
[syndicated profile] weeklyosm_ru_feed

Posted by weeklyteam

26.02.2026-04.03.2026

lead picture

[1] | Интерфейс инструмента «Podoma» с картой Италии | Данные карты © Участники OpenStreetMap.

О нас

  • StreetComplete теперь будет извещать о выходе нового выпуска weeklyOSM. Также в этом обновлении исправлены проблемы с расчётом статистики, появились уведомления об OSM-мероприятиях поблизости из OpenStreetMap Calendar и возможность настраивать эти уведомления.

Картографирование

  • Джеймс Уир начал обсуждение противоречащих друг другу определений тега wetland=tidalflat.

Картографические акции

  • [1] Daniele запустил экземпляр утилиты Podoma на платформе облачных сервисов Викимедии для отслеживания проекта месяца — инициативы итальянского сообщества OpenStreetMap.
  • Завершилась февральская кампания по картографированию от итальянского сообщества OpenStreetMap. Благодаря участникам, на карту было добавлено 100 тыс. уличных фонарей, включая даже тип лампочек и их угол поворота.

Сообщество

  • В своём последнем интервью об OpenStreetMap команда OpenCage обсудила с Deutsche Welle Innovation их разработку под названием SPOT, которая позволяет находить какое-либо место в городе по описанию объектов рядом с ним. Дискуссия развернулась вокруг того, как возник проект, технических деталей реализации и что по итогу смогли вынести для себя журналисты после года использования SPOT.
  • Межведомственное управление Франции по цифровым технологиям опубликовало беседу с Кристианом Квестом о проекте Panoramax. В ней затрагиваются темы старта и разработки на ранних этапах, обсуждаются различные трудности по созданию активного пользовательского сообщества и его судьбе спустя годы.
  • Группа энтузиастов MapRVA запустила бота The Yesterdays в Мастодоне. Каждые два часа он выкладывает архивные исторические фотографии города Ричмонд (столицы штата Вирджиния) вместе с геопозицией на современных картах OSM.

Фонд OpenStreetMap

  • Совет фонда OpenStreetMap официально представил свои замечания по предложению Консорциума по открытым геоданным (Open Geospatial Consortium) о стандартизации глобальной системы географических координат (GERS) разработки Overture Maps. Фонд OSM не возражает против концепции глобальной системы географических идентификаторов, однако указывает, что географическая реальность не может быть сведена к одному авторитетному источнику. По мнению совета OSM, знания об окружающем мире создаются не только в центрах обработки данных корпораций, но и благодаря усилиям многих добровольцев по всему миру, которые картографируют улицы, районы и окружающую их среду. Поэтому фонд OSM считает, что любой стандарт, которому необходимо одобрение консорциума, должен быть достаточно гибким, чтобы учитывать как централизованные, так и децентрализованные, то есть управляемые сообществом источники геоданных.

Карты

  • Проект OpenStreetMap Americana улучшает поддержку диалектов и многоязычности. Веб-разработчики могут установить утилиту Diplomat для экспорта языковых меток из OSM Americana на карты MapLibre.

Программы

  • GanderPL разработал MCP-сервер для тегирования OSM объектов, основой для которого стал проект iD Tagging Schema редактора iD.
  • Conveyal разработал Osmix — набор библиотек для просмотра данных, поиска по ним, а также работы с форматом OpenStreetMap PBF прямо в браузере (все вычисления производятся локально, вне сторонних серверов).
  • Sarath Sabarish демонстрирует работу собственной утилиты SafeStreets на примере таиландского города Чиангмай: отсутствие пешеходных переходов (highway=crossing) приводит к низкой оценке даже в случае хорошо картографированных улиц. Для геокодирования используются Nominatim, для получения данных — Overpass API.

Программирование

  • pascal_n рассказал , как ИИ-агенты справляются с задачами кодирования, будучи встроенными прямо в среду разработки, на примере создания аналога мобильной игры Flappy Birds и веб-страницы с картой OSM, слоями GeoJSON и WMS и так далее. В статье сравниваются Microsoft Copilot, OpenAI Codex и Anthropic Claude, а результаты подтолкнули автора к тому, чтобы попробовать такой вайб-кодинг со своими студентами.
  • HeiGIT поделились рассуждениями , как использование съёмки местности вместе с методами глубокого обучения помогает находить и картографировать критически важную инфраструктуру, данных о которой нет в существующих базах. Применяя описанные методы, можно эффективней классифицировать дорожное покрытие, детектировать мусор, замерять габариты тротуаров или строить маршруты с учётом актуальных погодных условий.

OSM в прессе

  • Петя Кангалова, старший менеджер по технологическому сотрудничеству в HOT, рассказала , как общественная организация сумела создать сложный технический продукт вокруг OpenStreetMap, призванный упростить картографирование территорий именно местными жителями, облегчить глобальные гуманитарные работы, устранение последствий стихийных бедствий и техногенных катастроф.

Разное о картах

  • НАСА и компания DevGlobal проведут онлайн-мероприятие, посвящённое совместной работе по устранению таких чрезвычайных происшествий, как пожары, наводнения и оползни. Встреча длительностью в один час пройдёт 11.03.2026 в 15:00 по UTC. Регистрация бесплатна.
  • Chromy рассказал про сайт Flexport Atlas. Это карта, частично использующая данные OpenStreetMap и на которой показываются грузовые суда (включая информацию о швартовке, стоянке или рейсе), а также порты и самолёты. Информация об объектах обновляется каждые 2 часа.

Предстоящие события

Страна Где Адрес Что Когда
flag Hogeschool Odissee Hospitaalstraat 23 Sint-Niklaas Vereniging Leraars Aardrijkskunde (VLA) conference 2026 2026-03-07
flag Perth Espresso Perk U Later Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth 2026-03-07
flag Perth Espresso Perk U Later Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth 2026-03-08
flag København Cafe Bevar’s OSMmapperCPH 2026-03-08
flag Delhi Books and Beans Café, Mayur Vihar Phase 1 OSM Delhi Mapping Party No.27 (East Zone) 2026-03-08
flag London Social Sciences Centre — Western University Friends of MSF UWO Mapathon 2026-03-09
flag Brno Geografický ústav, PřF MUNI, Brno Březnový brněnský Missing Maps Mapathon na Geografickém ústavu 2026-03-09
Missing Maps : Mapathon en ligne — CartONG [fr] 2026-03-09
flag Grenoble La Turbine Coop Découverte d’OpenStreetMap 2026-03-09
flag 臺北市 MozSpace Taipei OpenStreetMap x Wikidata Taipei #86 2026-03-09
flag Zaragoza Online Mappy Hour OSM España 2026-03-10
flag Hamburg Voraussichtlich: «Variable», Karolinenstraße 23 Hamburger Mappertreffen 2026-03-10
flag Cork Logitech, Cork, Ireland Logitech Missing Maps — Office Mapathon 2026-03-11
flag Reston George Mason University, HUB VIP 3 The GAIN Mapathon 2026-03-11
flag Zürich Bitwäscherei Zürich 185. OSM-Stammtisch Zürich 2026-03-11
flag Zürich Schweizerisches Rotes Kreuz Missing Maps Zürich Mapathon 2026-03-11
flag Milano Building 3A Ground Floor — Politecnico di Milano PoliMappers Maptedì 2026-03-12
flag Berlin Dieselhaus, Forum a. d. Museumsinsel 10 213. OSM-Stammtisch Berlin-Brandenburg 2026-03-12
flag München WikiMUC Münchner OSM-Treffen 2026-03-12
flag Magrathea Laboratories Chaos Computer Club Fulda OSM-Tools: Wenn die Welt zur Spielwiese wird 2026-03-13
flag Leuven Romaanse Poort Camera’s in kaart brengen 2026-03-14
Missing Maps London: (Online) Mid-Month Mapathon [eng] 2026-03-17
flag Lyon Tubà Réunion du groupe local de Lyon 2026-03-17
flag Bonn Dotty’s 198. OSM-Stammtisch Bonn 2026-03-17
flag Online Lüneburger Mappertreffen (online) 2026-03-17
flag MJC de Vienne Réunion des contributeurs de Vienne (38) 2026-03-18
flag Stainach-Pürgg Online 20. Österreichischer OSM-Stammtisch (online) 2026-03-18
Online Mapathon — Ärzte ohne Grenzen 2026-03-18
flag Heidelberg DEZERNAT#16 Rhein-Neckar OSM Treffen // Intro iD-Editor 2026-03-19
OSMF Engineering Working Group meeting 2026-03-20
flag Olomouc Přírodovědecká fakulta Univerzity Palackého Missing Maps Day Olomouc 2026 2026-03-21
flag Frühlingsmapping 2026 2026-03-22
Missing Maps : Mapathon en ligne — CartONG [fr] 2026-03-23

Примечание. Если вы хотите видеть своё мероприятие здесь, добавьте его в календарь. Данные оттуда автоматически появятся в еженедельнике. Не забудьте указать город и страну.

Над этим выпуском работали: Grass-snake, Raquel IVIDES DATA, Strubbl, TrickyFoxy, derFred, izen57, richter_fn.

Пиранези

Mar. 8th, 2026 01:53 am
kattrend: (ящерка на границе)
[personal profile] kattrend
Прочитала "Пиранези" Сюзанны Кларк, очень круто, хочется это рисовать - но, возможно, для этого надо быть Пиранези. Вообще, очень постмодерническая книга в смысле отсылочек. Мы любим отсылочки. Хотя на отсылочке к "Доктору Кто" я всё-таки заржала, хотя и сама думала, что это похоже на серию "Ниспосланный с небес" ("Это была очень упрямая птичка", но в дневниках главного героя отсылка была прямой. Точно чувствуется ощущение "Горменгаста" и "Города иллюзий" ЛеГуин, хотя второе понимаешь только в конце.

Вообще, первые восемь страниц читать не надо, потому что это как бы отзывы и блаблабла, маркетинг всякий; гуглить, о чём книга, до прочтения тоже опасно, потому что можно нарваться на кошмарные спойлеры и потерять две трети удовольствия от разгадывания загадки. Но вот сейчас я упираюсь в то же самое: а как рассказать, что я такое прочитала, не наспойлерив? А ведь это по сути детектив, невежливо портить другим людям впечатление. Вот и друг, который дал мне эту книжку, так же скрипел зубами, пока я её не прочитала.

Вот не скажу "всем срочно читать". Мне она подошла как родная, и каждый раз, когда я пересматриваю в своей голове прочитанное, там как будто распахивается весь этот простор бесконечного Дома с затопленными нижними этажами и облаками наверху, со статуями и арками и идеальным архивариусом внутри. Там во всём есть смысл, даже в этих бесконечных заглавных буквах в начале. Но не все же читатели - я. Надо быть опытным путешественником по мирам, чтобы понять, что произошло.

пауза

Mar. 8th, 2026 01:18 am
kattrend: (Default)
[personal profile] kattrend
Потоп внезапно закончился, мы вдруг увидели сухой пол, и сегодня я его помыла нормально с мылом. По результатам пострадал только случайно забытый в углу полосатый шоппер, но он высохнет - и норм, я в нём материалы для работы таскаю, не страшно. Правда, мы не знаем, что под сценой и под рундуком, но у рундука теперь есть дно, а в остальном он создан мокнуть, корабельный же. Мы молодцы, хорошо подготовились.

Термопару я тоже подсоединила со второго раза правильно, чашки отлично обожглись. Там есть чашка-лягушка, мятая пиала, которая выглядит так, словно на ней опробовали раку - но нет, это не настоящее раку, это глазурь "графит" и странный метод обжига. И еще одна чашка-нетрадициалка с горизонтальной ручкой, про которую я напрочь забыла со всеми этими событиями, чем покрыла. Она зеленоватая. Фиг знает, у нас полно зеленоватых глазурей.

Прожектор над баром Теней перегорел, и мы решились заменить его на такую же лампочку, как остальные. Потому что белые прожектора для выставок, а на баре лучше смотрится тёплый свет. Немножко непривычно, но уютно.

Таким образом, поломки исправлены. В целом ощущается как пауза, передышка. Доплыли до островка, сушимся, костерок развели, кофе варим. А дальше опять в бушующее море. Надо на этом островке сил набраться.

Bruce Momjian: New Presentation

Mar. 7th, 2026 06:45 pm
[syndicated profile] planet_postgresql_feed

I just gave a new presentation at SCALE titled The Wonderful World of WAL. I am excited to have a second new talk this year. (I have one more queued up.)

I have always wanted to do a presentation about the write-ahead log (WAL) but I was worried there was not enough content for a full talk. As more features were added to Postgres that relied on the WAL, the talk became more feasible, and at 103 slides, maybe I waited too long.

I had a full hour to give the talk at SCALE, and that was helpful. I was able to answer many questions during the talk, and that was important — many of the later features rely on earlier ones, e.g., point-in-time recovery (PITR) relies heavily on crash recovery, and if you don't understand how crash recovery works, you can't understand PITR. By taking questions at the end of each section, I could be sure everyone understood. The questions showed that the audience of 46 understood the concepts because they were asking about the same issues we dealt with in designing the features:

  • How does server start know if crash recovery is needed?
  • Can dirty shared buffers be written to storage before the WAL for the transaction that dirtied them is written?
  • Can the WAL and heap/index storage get out of sync?
  • How is the needed WAL accurately retained for replica servers?
  • Can logical replicas be used as failover servers?

Continue Reading »

[syndicated profile] planet_postgresql_feed
In PostgreSQL, a DELETE operation does not immediately erase data from disk. The MVCC mechanism retains deleted rows as dead tuples, and reading these dead tuples is one viable approach to data recovery. However, this approach has a clear time limitation: once autovacuum completes its cleanup, the dead tuples are physically removed, and recovery methods based on data files become ineffective. At this point, the WAL (Write-Ahead Log) offers an alternative recovery path. Specifically, the **FPW (Full Page Write)** mechanism within WAL is the foundation of this approach. PostgreSQL DELETE recovery tools — including [PDU (PostgreSQL Data Unloader)](https://github.com/wublabdubdub/PDU-PostgreSQLDataUnloader) — rely on this technique. Its key property: **as long as the WAL files generated during the deletion period still exist, the data can be fully recovered regardless of how much time has passed.** This article dissects that recovery path function by function, based on **PostgreSQL 18** source code.
[syndicated profile] dxdt_ru_feed

Posted by Александр Венедюхин

Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.

Заметьте, что URL – это не авторизационный куки-файл, который браузеру тоже известен, но который передаётся в составе заголовков HTTP-запроса, поэтому чётко отделяется в любом браузере от URL, и браузер, всё же, этот файл будет пытаться отправлять только тем узлам, которым он прямо предназначен (на сей счёт есть очень много спецификаций и требований, а про URL – подобных требований нет).

починила

Mar. 7th, 2026 01:27 pm
kattrend: (Default)
[personal profile] kattrend
Вроде бы со второго раза термопару я подключила правильно, и сейчас печка дожигает недожжённые чашки. Судя по состоянию глазурей, вчера она за полчаса догнала где-то до тысячи. Хорошо, что глина надёжная: кремовый шамот и не такие термоудары переносит, и печке это норм, если бы я плавила металл, я бы так и поднимала, а потом еще открыла бы, чтобы вынуть тигель. Она на такой экстрим рассчитана.

Поражает, сколько этого вот всего в моей жизни, как так вышло. То это чинить, то то. Подвалы Вавилова закрыли, но игра в фоллаут продолжается.

Зато Зябла пишет, что в Тенях уже гораздо меньше воды, она, зайдя, обнаружила довольно много сухого пола. Лужи, конечно, ещё есть, но мы и не ждали, что паводок прекратится вот так сразу.
[syndicated profile] planet_postgresql_feed

In this article I walk you through the journey of adding the pg_crash extension to the new CloudNativePG extensions project. It explores the transition from legacy standalone repositories to a unified, Dagger-powered build system designed for PostgreSQL 18 and beyond. By focusing on the Image Volume feature and minimal operand images, the post provides a step-by-step guide for community members to contribute and maintain their own extensions within the CloudNativePG ecosystem.

столько всего

Mar. 7th, 2026 02:02 am
kattrend: (ааа!)
[personal profile] kattrend
Каждый день происходит столько всего.

Где-то ночью в Тенях подвис насос, и, когда я пришла, вода стояла ровным слоем везде. Впрочем, не смертельно, сцену не залило, но колодец и бочка в нём были полны. К счастью, я уже знаю, как насос будить, и к приходу первых людей я уже довела всё до состояния местами мокрого пола. Приятные физические упражнения каждый день: гонять воду можно, например, стоя в стойке мабу.

Людей мне особенно не досталось, но потом меня сменила Зябла, я уехала и отыграла два сета в Квокке с двумя разными группами, причем, с Вереском - в четыре смычка. Я, Ришко, Чижов и Бэтька. Мало, но насыщенно. И Птицесишный сет драйвовый вышел.

Где-то в промежутке я успела выудить из сдэка свою термопару, после ужина вставила её в печь, и - перепутала полярность. Ну, вообще-то она никак не обозначена. Проводок я не переворачивала, в обучающем видосе чувак обращается с ним весьма вольно. В результате, похоже, печь за полчаса догналась до максимальной температуры, показывая при этом температуру отрицательную. Теперь мне ждать до утра, пока всё остынет, и смотреть, что вышло. Ну и перевернуть проводок. Вот советовала мне Зябла тестировать на одной чашке, а не на трёх.

Вот как это всё влезает в один день. А ведь почти каждый такой.
[syndicated profile] dxdt_ru_feed

Posted by Александр Венедюхин

Известная шутка гласит, что категорий людей – 10: одни уже знают двоичную систему счисления, а другие – ещё нет. Занятно, что 102 обозначает простое число – два. Это большая редкость в системах счисления, которые рутиннно используются в ИТ. Понятно, что ни в восьмеричной, ни в десятичной, ни в шестнадцатеричной, 10 (как запись) не может обозначать простое число (как и всякая запись, заканчивающаяся на 0). А в двоичной – пожалуйста.

Естественно, это возможно только потому, что основание двоичной системы – простое число два. Если взять любое другое простое основание, то 10 тоже будет простым, потому что это и есть запись основания: три – по основанию 3, пять – по основанию 5, семь – 7, и так далее. Но наиболее привычны, кроме десятичной (десятеричной), это двоичная, восьмеричная и шестнадцатеричная.

Возьмём запись 11. В двоичной – это простое число три (112 = 2 + 1 = 3). В восьмеричной – девять, составное, но квадрат простого: 3^2. Та же запись 11 означает одиннадцать в десятичной, простое. Шестнадцатеричное 11 – это семнадцать, тоже простое.

Использование в этом ряду двоичной системы ограничивает доступный набор цифр: только 0 и 1. Но можно взять, например, 101 – трёхзначное:
это пять в двоичной (простое);
шестьдесят пять – в восьмеричной, составное: пять на тринадцать;
сто один – в десятичной, простое;
двести пятьдесят семь – в шестнадцатеричной, простое.

Обратите внимание, что запись чисел словами – это инвариантная, относительно системы счисления, запись.

1112 = семь (простое);
1118 = семьдесят пять (составное);
11110 = сто одиннадцать (простое);
11116 = двести семьдесят три (составное: 3*7*D).

Не забывая о том, что все простые числа, кроме числа два и числа три, имеют вид 6*n +/- 1, на трёх цифрах можно и остановиться. Тем более, что шестеричная система счисления не является распространённой.

[syndicated profile] planet_postgresql_feed

The last PG Phriday article focused on the architecture of a Patroni cluster—the how and why of the design. This time around, it’s all about actually building one. I’ve often heard that operating Postgres can be intimidating, and Patroni is on a level above that. Well, I won’t argue on the second count, but I can try to at least ease some of the pain.To avoid an overwhelming deluge consisting of twenty pages of instructions, I’ve split this article into a series of three along these lines:

  • Etcd
  • Postgres and Patroni
  • HAProxy
This establishes each of the three layers that represent the full Patroni stack, and provides a convenient reference for later regarding each.With that out of the way, let’s get started!

Why etcd?

The last article should have made it abundantly clear that the DCS is the nexus of communication and status for the whole cluster. As a result, it’s important to install it first and certify that it’s operational. Etcd is the default and the example most often deployed in Patroni clusters. It’s also the key/value storage system Kubernetes uses as a default, so it should be reliable enough for our needs.Don’t forget to keep a browser tab opened to the etcd documentation handy.

What you’ll need

If you want to follow along with this demonstration, you’ll need:
  • The ability to create three VMs. Whether it’s
  • Amazon EC2
  •  instances,
  • Microsoft Hyper-V
  • ,
  • Xen
  • ,
  • QEMU
  • ,
  • Proxmox
  • ,
  • Oracle VirtualBox
  • , or even
  • VMWare Fusion
  • , make sure you have a hypervisor and know how to use it.
  • Three VMs running
  • Debian Stable
  •  version 13. At the time of writing, this should be the Trixie release.
  • SSH access as a root-capable user on each VM.
  • An internet connection. If you have the first three, it’s likely you have this as well.
Believe it or not, that should actually be all that’s necessary. While these instructions focus on Debian packaging when possible, feel free to substitute RedHat equivalen[...]
[syndicated profile] planet_postgresql_feed
It is 3 AM. A rogue DELETE just wiped 500,000 customer records. Traditional recovery takes hours and risks collateral damage. This guide shows you how to recover accidental DELETEs and UPDATEs in five steps using PDU — no kernel expertise, no downtime, data back in under a minute.
[personal profile] jaerraeth
Понадобилось мне для дела простенькое предсмертное двустишье одного товарища.

Cowards fear to die; but Courage stout,
Rather than live in Snuff, will be put out.

Среди современников сей товарищ был известен "и как поэт тоже", звездой первой величины не сиял, хотя в когорту достойно входил. Перевода на русский лично я не нашел (причем не только этого двустишья, а вообще его стихотворений). Ладно, думаю, сам сделаю, опыта достаточно.
Нет, опыта и правда достаточно. Сделал.
А теперь выбрать не могу.Read more... )

Profile

nataraj: (Default)
Swami Dhyan Nataraj

July 2024

S M T W T F S
 123456
789 10111213
14151617181920
21222324252627
28293031   

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Mar. 14th, 2026 04:59 pm
Powered by Dreamwidth Studios