ioltas

There has been a patch to extend the COPY code with pluggable APIs, adding callbacks at start, end, and for each row processed: https://commitfest.postgresql.org/49/4681/.

I'd guess that this may fit your purpose to add a custom format without having to fork upstream.

The bar to merge a patch that would break on-disk format is so high that it’s really impossible to reach it ;)

More seriously, we care a lot about the format of the 8k pages to ease upgrade paths as much as possible.

I’ve met Simon for the first time in Tokyo in 2009 for a birthday related to JPUG (Japan PostgreSQL User Group) when hot standby was getting integrated into the upstream project. I saw him last time in Prague three months ago, and we have joked about a few things while discussing about life and how things were going on as I did not go to the Postgres Europe conference for 6~7 years.

The community has lost a member, and many people have lost a friend. That’s so sudden. My thoughts go to his family and people who knew him. I’m so sad. RIP, Simon.

I’ll try to do something about that tomorrow, saw your ticket.

There are hooks for the planner and the executor, so you could force their hand quite easily with a plan extracted from a previous EXPLAIN. Being able to pass a plan at protocol level would be more efficient, for sure. I’ve worked on Postgres-XC and somewhat Postgres-XL, and that’s something that we wanted to do to generate a plan on one node, and push down the compiled plan down to other nodes to avoid the overhead of the plan computation. This stuff did that for snapshots and a few more things with an extension of the protocol.

Thanks, glad to hear some good feedback.

There are many Postgres internals that people are usually not aware of, with more than one way to develop your module. I have a repo that’s a set of plugin templates here, that should be handy for your studies: https://github.com/michaelpq/pg_plugins

I’ve been doing maintenance and bug fixes for this module for over 18 months now (last commit on HEAD seems to be mine), managing the last two releases. If you have questions and/or feedback, feel free.

Note that this one mentions 借地料, meaning that you are not an owner of the land, but the government is lending it to you for a yearly fee of 220,000 yens.

It's been argued a few times that we should have the possibility to make an index invalid on sight with a proper ALTER INDEX command, yes.

FWIW, amcheck can be useful but I am not 100% sure that it can detect all the broken cases either.

Looking at their code tree, this is based on 11.2 (https://www.postgresql.org/docs/11/release-11-2.html): https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/maste...

So this is code from two years ago missing stability fixes from upstream up to 11.12, at short sight.

mutt + mbsync with a local copy is also a nice combination.

Discussions within the core team are done on a private mailing list, so we'll know the status of things with a public announcement. Committers and contributors have no view of what gets discussed there, except if you are of course directly attached in CC of a given thread, and of course except if you are a committer also part of the core team. Four members of the current core team are committers.

When it comes to backup, the time it takes for the backup to complete is not a property that matters the most in my opinion. The time it takes to restore the backup matters, and being sure that the backup is able to restore and is not corrupted matters even more.

Here are some slides from a presentation of Andres Freud on the matter: https://anarazel.de/talks/2018-10-25-pgconfeu-pluggable-stor...

Slides 4 and 5 give some insight about the architecture changes which have been done.

An advantage of REINDEX CONCURRENTLY is that it becomes much easier to handle dependencies of a rebuilt index with constraints, as what the feature roughly does it to add a swapping phase between the creation and the drop portions which switches the dependencies from the old index to the new fresh one. Table-level reindex also makes life easier.

The feature is equivalent to external tools like pg_repack (formerly pg_reorg) in more performant, and has a couple of limitations to be aware of: https://www.postgresql.org/docs/12/sql-reindex.html#SQL-REIN...

I am not sure, but doesn't it make also sense financially for some parents to send their kids to soroban classes because that's actually cheaper and more frequent in a week than other alternatives when they cannot go anymore to the public after-school services (I speak about gakudo/学童 here)?

If that was not clear, the root comment mentioned that Dimitri was a committer, and it got edited afterwards. Regarding the book, I have a copy of the first edition close by (with a dedication from the author), and for application developers I think that it provides good insight about various aspects.

Dimitri is a major contributor of Postgres for a very long time, still he is no committer: https://wiki.postgresql.org/wiki/Committers

Saying that, the man is really cool and his book is very good, so that's a must-have for developers in my opinion.

> This is true. In fact, by far the fastest route to permanent residence in Japan is marriage. You can get PR in 3 years if you are married to a Japanese national vs 10 years if you aren't.

More details on that. Getting a wedding visa the first time gives 1 year. At the second application one year later, one gets once again 1 year. At the third application one year later, you get 3 three. At this point, you could ask for permanent residency. So the first three years after the wedding are a hell of paperwork, but after that there is no need to go to the immigration office (入国管理局) which is close to Shinagawa in Tokyo.

Postgres 12, whose development has reached feature freeze and is in a stability period, has added some support for JSON path as of SQL:2016: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

The release is planned for roughly next September/October.

There is a range of interesting problems here for Postgres. One is related to the costly way snapshots are built which needs to scan all entries in PGPROC to get back a list of transaction IDs. So even idle connections come at a cost. There have been proposed patches to improve the scalability in this area, one being called CSN (Commit Sequence Number) which I think is rather promising: https://www.postgresql.org/message-id/CA+CSw_tEpJ=md1zgxPkjH...

The most productive language of Gilles, well-known in the Postgres community by the way, is perl, and he can do completely crazy things with it. See for example pgbadger (https://github.com/darold/pgbadger), one of his other projects.