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.

There has been in the community for a couple of years now a set of patches to support REINDEX CONCURRENTLY, and there have been discussions for having a CLUSTER CONCURRENTLY, but nothing has materialized. Pushing forward into having such patches would make sense. There are many users asking for the possibility to do tuple reordering without holding an exclusive lock on the relations involved.

It would be interesting to have some data like that per country. For example in Japan, I would suspect that the first places are in April and May. The fiscal year beginning on the 2nd of April, couples prefer to be able to put a kid to the daycare in its first year in the 0-year-old class (0歳児) with a kid the maximum older. So if a kid is born on the 2nd of April, he will be able to go to the daycare of 0-year class when he is 11 months and 30 days, while if he is born in March, the kid could just enter the daycare in the 1-year class (1歳児), which is way harder to join because there are less new places in 1-year classes than 0-year classes. Note that the kid can just go to the daycare if older than 6 weeks (I may not recall details correctly here), so it is possible for kids born in February to go to the daycare of 0-year class, but most of his/her classmates would likely be closer to turn 1 once they all join the daycare, which makes for a huge difference at this age.

A patch implementing channel binding has been presented for integration into Postgres 11: https://commitfest.postgresql.org/14/1153/. Two channel types are presented: tls-finish and endpoint. Per the RFC 5802, it is mandatory to use SSL if you want channel binding as the data needed for binding validation is either the TLS finish message which can be found after the SSL handshake between the server and the client (which happens before the password-based authentication), and a hash of the server certificate. All those things are actually supported by a set of APIs in OpenSSL.

Equality operations are also cheaper with hash indexes than btree because less data pages need to be fetched, so this can be a gain for certain columns with a high cardinality. You should really look at if those could be used or not, you may gain in performance with a switch.

You can enforce a portion of that directly in your .gitconfig:

  [alias]
  	# Show top level repository
	root = rev-parse --show-toplevel

I have found that useful over time.

> Mac is not supported this patch, but is in progress

This bit is good to know. As usual Linux support will unlikely happen. You can guess from that as well that SC:R would lack macos support if they are not able to address the existing issues until its release.