This appears in the release notes as a fairly minor change but it significantly boosts the defense against one of the sneakiest problems in data management - silent data corruption.

Let’s dive into what this feature is, what the new default means for you, and how it impacts upgrades.

What is a data checksum?

A data checksum is a simple but powerful technique to verify the integrity of data pages stored on disk. It's like a digital fingerprint for every 8KB block of data (a "page") in your database.

• Creation: When Postgres writes a data page (table and indexes) to disk, it runs an algorithm on the page's contents to calculate a derived, small value—the checksum.
• Storage: This checksum is stored in the page header alongside the data.
• Verification: Whenever Postgres reads that page back from disk, it immediately recalculates the checksum from the data and compares it to the stored value.

If the two values do not match, it means the data page has been altered or corrupted since it was last written. This is important because data corruption can happen silently. By detecting a mismatch, Postgres can immediately raise an error and alert you to a potential problem. Checksums are also an integral part of pgBackRest which uses these checksums to verify backups.

What is initdb and why does it matter?

The initdb command in Postgres is the utility used to create a new Postgres database cluster and initializes the data directory where Postgres stores all the permanent data. When you run initdb, it does things like:

1. create the directory structure
2. create the template databases like template1 and postgres
3. populate the initial system catalog tables
4. create the initial version of the server configuration files
5. enable and start keeping track of checkums

The syntax often looks something like this:

/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

As an end user who uses cloud managed Postgres or even a local tool like Postgres.app, you generally never see the initdb command because it is a one-time administrative setup task.

The new default --data-checksums for initdb

In the past database admins had to manually add the --data-checksums flag when running initdb to enable this feature. If you forgot or didn’t know about this feature, the new cluster was created without these built-in integrity checks.

The default behavior of initdb is now to enable data checksums every time Postgres is initiated.

• old command - checksums OFF by default: initdb -D /data/pg14
• new default command - checksums ON by default: initdb -D /data/pg18

This is generally a win for Postgres best practices. Every new database cluster is now automatically equipped with this corruption defense, requiring no extra effort.

--no-data-checksums

You might have a very specific reason to disable checksums and you can explicitly opt out using the new flag:

initdb --no-data-checksums -D /data/pg18

Checksums and pg_upgrade

While the new default is great, it may introduce a compatibility issue for those doing a major version upgrade using the pg_upgrade utility.

pg_upgrade works by connecting an old data directory to a new data directory and a fundamental requirement is that both clusters must have the same checksum setting—either both ON or both OFF.

If you are upgrading an older Postgres cluster that was created before this change, chances are it has checksums disabled and pg_upgrade will fail because the settings mismatch.

In an upgrade pinch, to upgrade a non-checksum-enabled cluster, you can use the new --no-data-checksums flag when initializing the new cluster to make the settings align.

Upgrading an existing Postgres database to checksums

Instead of continuing forever with no data checksums, the better long term solution is to add checksums to your database before the next upgrade. Sadly, there’s really no way to do this without some downtime and a restart. Adding checksums to an existing database can be a slow process with a large database. There’s a pg_checksums utility to help with this which is well documented.

We have helped a few folks with this issue. For larger no-downtime environments, you can add the checkums on a replica machine and then fail over to that.

Summary

Postgres checksums are a great feature - and will be the default in the future. If you haven’t used checksums in the past, you may want to start planning now for adding them, especially since a self managed major version upgrade will require a bit of extra thinking. ]]> fa1787ed297110b99885d60008c312cb0ebd13f901f1167f84a7af3a4dcf9755 Thu, 11 Dec 2025 08:00:00 EST 2025-12-11T13:00:00.000Z 2025-12-11T13:00:00.000Z https://www.crunchydata.com/blog/postgres-troubleshooting-fixing-duplicate-primary-key-rows Someone recently asked on the Postgres mailing lists about how to remove unwanted duplicate rows from their table. They are “unwanted” in that sense that the same value appears more than once in a column designated as a primary key. We’ve seen an uptick in this problem since glibc was kind enough to change the way they sorted things. This can lead to invalid indexes when one upgrades their OS and modifies the underlying glibc library.

One of the main effects of a corrupted unique index is allowing rows to get added which should be caught by the primary key. In other words, for a table with a primary key on a column named “id”, you might observe things like this:

-- Can you spot the problem?
SELECT id FROM mytable ORDER BY id LIMIT 5;

 id
----
  1
  2
  3
  3
  4
(5 rows)

Without knowing anything else about the problem, what’s the first step to solving it? If you said take a backup, you are correct! Make a fresh backup anytime you think something is wrong with your database, or before any attempt to fix such a problem.

Aside: can we simply reindex? No - a unique index cannot be created (or recreated) as long as there are duplicate rows. Postgres will simply refuse to do so, as it violates the uniqueness we are trying to enforce. So we must delete the rows from the table.

Here is one careful recipe for fixing the problem of duplicated primary key entries in your Postgres table. Obviously you need to adjust this as needed for your situation, but just walk through it slowly and make sure you understand each step. Especially if this happens in production (spoiler: it almost always happens in production).

1. Debugging aids

The first thing we want to do may look a little strange:

-- Encourage not using indexes:
set enable_indexscan = 0;
set enable_bitmapscan = 0;
set enable_indexonlyscan = 0;

Because bad indexes are the primary way bad rows like this get into our database, we cannot trust them. These low-level debug aids are a way of telling the Postgres planner to prioritize other ways of getting the data. In our case, that means hitting the table directly and not looking things up in the indexes.

2. Run a quick sanity check

-- Sanity check. This should return a number greater than 1. If not, stop.
set search_path = public;
select count(*) from mytable where id = 3;

Before we begin, we want to make sure we have the correct table. The search_path is a safety measure, as is the lookup on the table. Since the id is the primary key of the table, it should return a count of 1 for each value. In our case, we know this table has multiple entries for id “3”, so this is mostly a sanity check that we are about to operate on the correct patient. We expect to get back a number greater than “1”. For a working primary key, the only values ever returned should be 0 or 1.

3. Create a backup (always 😉)

-- Make a backup:
create table mytable_backup as select * from mytable;

Before we begin, we want to copy all of the existing rows from the table into a new backup table. Again, this does not take the place of a full and complete backup of your entire database (always step 0), but it’s another good safety feature.

4. Make a test table

--  Test out the process on a subset of the data:
create table test_mytable as select * from mytable where id < 30;
create table test_mytable_duperows_20250317 (like mytable);

It’s always a good idea to test things first on a test table. In our case, in a smaller version of the actual table. Because we know that there are problematic rows at id 3, we created a new table that contains those rows. We also create a new empty table called test_mytable_20250317 which is going to hold the duplicate rows that get removed. The date at the end tells future viewers when the table was created.

5. Start the cleanup in a replica session

From here on out, we are going to start the actual cleanup. We start a transaction, and then set our session_replication_role to replica, which is an advanced (and dangerous) command that disables all triggers and rules. Normally this is not a good practice, but we want to do this in case there are any foreign keys that may prevent us from removing the bad rows. In addition, we do this as SET LOCAL instead of just SET which ensures that this setting goes back to normal at the next COMMIT or ROLLBACK.

begin;
set local session_replication_role = 'replica';

Because we just created this test table, we know that it has no triggers and is not linked to any other tables via foreign keys, but we want to make this test as close to possible as the actual table modification, so we leave the session_replication_role modification in place.

6. Cleanup duplicate rows with a function

begin;

set local session_replication_role = 'replica';

with goodrows as (
  select min(ctid) from TEST_mytable group by id
)
,mydelete as (
  delete from TEST_mytable
  where not exists (select 1 from goodrows where min=ctid)
  returning *
)
insert into TEST_mytable_duperows_20250317 select * from mydelete;

reset session_replication_role;

commit;

So we issue a begin, set the session_replication_role, run a single SQL statement, reset the session_replication_role, and finally commit. That SQL statement is doing some heavy lifting, so let’s break it down.

select min(ctid) from TEST_mytable group by id The first thing we need to do is figure out a way to ferret out which rows are duplicated. As the id column is supposed to be unique (as all primary key columns are), we know that any ids appearing more than once need a tie-breaker. Each row in Postgres has a hidden column named “ctid” that stands for column tuple identifier, and is basically a pointer to exactly where the actual physical row is located. Therefore, it is always unique. If we group by the id column, we can pull a single ctid for each unique id by asking for the “lowest” ctid (it doesn’t really matter if we use min() or max() or something else, just as long as we pick only one).

We are going to store that information and use it to help with the delete, so we start a cte via the WITH command, and name this one as goodrows .

delete from TEST_mytable
where not exists (select 1 from goodrows where min=ctid)
returning *

The next step is to delete all duplicate rows that do NOT come from our goodrows list which was just created. So each of the duplicated rows will have distinct ctids, and we are going to delete all but one of them for each id. The final RETURNING * bit tells delete to send back complete information about every row that was deleted.

insert into test_mytable_duperows_20250317 select * from mydelete;

Finally, we take the output of the delete and store it into our table. In this way, the rows are deleted, but we still have a complete list of which rows were removed, for debugging and forensics.

At this point, the duplicated rows should be removed, and inside the “duperows” tables. It is probably best to examine both this table and the test_mytable one, to make sure this all worked as expected.

7. Run the function on the live table

When ready, you can re-run the same code, but replace the test table with the actual one:

create table mytable_duperows_20250317 (like mytable);

begin;

set local session_replication_role = 'replica';

with goodrows as (
  select min(ctid) from mytable group by id
)
,mydelete as (
  delete from mytable
  where not exists (select 1 from goodrows where min=ctid)
  returning *
)
insert into mytable_duperows_20250317 select * from mydelete;

reset session_replication_role;

commit;

8. Reindex

As a final step, we want to rebuild those suspect indexes. Even though the duplicated rows are gone, the index may still have wrong information. The REINDEX command is basically a drop and recreate, so we do that for all indexes that may exist in our table:

reindex table mytable;

Now we can also return Postgres to normal plan settings with enable_indexscan, enable_bitmapscan, and enable_indexonlyscan all set to 1.

That’s all the steps! When in doubt, reach out to your local Postgres expert if you are not 100% sure of your steps, as corruption is not something to take lightly. ]]> 274e2c30eb9fb36b07f66770214c20bdb3acb3b0f973ca61f125287b18dd0f75 Wed, 19 Mar 2025 10:00:00 EDT 2025-03-19T14:00:00.000Z 2025-03-19T14:00:00.000Z https://www.crunchydata.com/blog/when-does-alter-table-require-a-rewrite It is rare that a Postgres table keeps the exact same structure year after year. New columns get added. Old columns get dropped. Column data types need to change. Those are all done with the ALTER TABLE command. One big drawback to these changes is that they may force a complete table rewrite. A rewrite means a completely new copy of the table is created, and then the old one is dropped. This can take a very long time for large tables. Worse, everything else is blocked/locked from using the table, so your application may need downtime.

So which commands need a full table rewrite? Which only needs a split-second lock? The alter table documentation has some guidelines, but at the end of the day, you want to know for sure if your production application is going to require major downtime or not. Presented here is a quick recipe for safely determining if a rewrite will happen. In short make a copy of the table, modify that copy, see if the underlying file on disk for that table has changed.

Let’s look at what happens when a table is modified. For this, we will use the good old reliable pgbench_accounts table, which gets created when you run pgbench -i. We can simulate the effects of a long-running table rewrite by putting our statement into a transaction. For this first one, let’s add a new column to it and see what locks are being held:

greg=> begin;
BEGIN

greg=*> alter table pgbench_accounts add chocolates int;
ALTER TABLE

greg=*> select locktype, mode from pg_locks
        where relation::regclass::text = 'pgbench_accounts';
 locktype |        mode
----------+---------------------
 relation | AccessExclusiveLock

The AccessExclusiveLock is on the entire table, and is a very, very strong lock that blocks almost all other access to the table from other processes. Let’s start another process and see what happens:

-- Without the lock_timeout, this update would hang forever,
-- or until the other transaction commits:
greg=> set lock_timeout TO '5s';
SET
greg=> update pgbench_accounts set bid = bid;
ERROR:  canceling statement due to lock timeout
LINE 1: update pgbench_accounts set bid = bid;

-- This lock also stops SELECT statements as well!
-- (another way to not wait forever is with a statement_timeout)
greg=> set statement_timeout = '500ms';
SET
greg=> select * from pgbench_accounts limit 10;
ERROR:  canceling statement due to statement timeout

This confirms that ALTER TABLE can prevent your application from accessing the table. Yet, all is not lost, watch what happens when we run it without a commit:

greg=> \timing on
Timing is on.
greg=> alter table pgbench_accounts add chocolates bigint;
ALTER TABLE
Time: 2.149 ms

Two milliseconds is quite fast. Most applications should be able to easily deal with that. One caveat is that the lock still needs to be acquired. To do this, it needs to have complete solo control of the table for a split second. For a very busy table, this may take some coordination with your application. The table rewrite may require that your application be blocked for hours, or even days!

Create a test table with CREATE TABLE LIKE

To start, we always want to work on a simulacrum of your important production table. In other words, a copy of the table structure, but without all the table data. Postgres provides a handy way to do this with the LIKE clause of the CREATE TABLE command. You may specify which optional parts of the table to copy over. For our purposes, we only need the column defaults, so we can write this:

CREATE UNLOGGED TABLE gregtest (LIKE pgbench_accounts INCLUDING defaults)

Might as well make this an unlogged table, as this will be a very temporary construct. If we compare the two tables, their structure is identical:

greg=> \d pgbench_accounts
              Table "public.pgbench_accounts"
  Column  |     Type      | Collation | Nullable | Default
----------+---------------+-----------+----------+---------
 aid      | integer       |           | not null |
 bid      | integer       |           |          |
 abalance | integer       |           |          |
 filler   | character(84) |           |          |

 greg=> \d gregtest
             Unlogged table "public.gregtest"
  Column  |     Type      | Collation | Nullable | Default
----------+---------------+-----------+----------+---------
 aid      | integer       |           | not null |
 bid      | integer       |           |          |
 abalance | integer       |           |          |
 filler   | character(84) |           |          |

Was a table rewritten?

Now, we can ALTER our new table. But how do we determine if the table was rewritten? As this table has no rows, we need another way to detect it rather than seeing how long it takes. Every table in Postgres is mapped to one or more physical files in the Postgres data directory. We can see the file for the table with the pg_relation_filenode function. If the output changes, we know that it has been rewritten. First, let’s add a simple BIGINT column with no default, which should not cause a rewrite:

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495135
greg=> alter table gregtest add monkeys bigint;
ALTER TABLE

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495135

Notice that our filenode has not changed. So we still need the Access Exclusive lock, but a rewrite did not happen. Let’s run an example that does rewrite the table:

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495135

greg=> alter table gregtest add foobar4 bigint default random(1,10);
ALTER TABLE

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495140

Per the documentation, a non-static default will force a rewrite. In this case, all the existing rows will have a random number from 1 to 10 inserted into them. Although this table has zero rows, the rewrite happened anyway.

Another common use case is changing the data type of an existing column. As I know from bitter experience, changing from an int to a bigint always requires a rewrite:

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495140
greg=> alter table gregtest alter column bid type bigint;
ALTER TABLE

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495144

There are a few data type changes that do not require a rewrite, so you should always TIAS ("try it and see"). Does going from an 8-byte bigint to a 4-byte force a rewrite?

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495144

greg=> alter table gregtest alter bid type integer;
ALTER TABLE

greg=> select pg_relation_filenode('gregtest');
 pg_relation_filenode
----------------------
              1495147

Yep! Even though anything we put into a bigint can “fit” inside an integer, they are represented differently on disk and thus need a table rewrite.

Summary

Hopefully this helps you to learn if a rewrite is needed or not, without actually messing with your production table! Don’t forget to drop that test table when you are done. If you need to make a change that requires a table rewrite, but cannot afford the downtime, there are more complex options - such as using logical replication - that can help.

There are a few other operations that can cause a full table rewrite, but they are mostly things you probably will not encounter very often:

• VACUUM FULL
• CLUSTER
• REFRESH MATERIALIZED VIEW
• Changing a table from LOGGED to UNLOGGED, or vice-versa.

You may have missed it if you were scanning the release notes, but after the end of each specific item in the release note is a small “section” symbol which looks like this: §. Each of these symbols is a link leading to the relevant commit for that item. Here’s what it looks like on the Postgres 17 release notes page:

Clicking the section symbol will send you to the GIT link for each individual patch, for example, this one:

Note that there’s a “Discussion” link in each commit linking back to the full thread on the hackers channel.

Writing the release notes is hard work, and involves a good bit of debate in the community. We have to make sure we list all the changes, in a concise yet comprehensible manner, and decide what level of detail to include. Oftentimes, this level is not sufficient for people interested in learning about this feature. That’s where these new commit links are invaluable. They link to the git commit, which not only lets you see the exact code changes that were made, but show the actual commit message, which has more detail than what can be provided in the release notes.

Postgres Notes in Lots of Places

Postgres release notes appear in lots of different places so this addition will surely make its way into other downstream projects. This new link also now appears on “postgres all versions” - a project that I maintain that collates the information from all of the release notes for every version of Postgres (over 500 now!) into a single page. To make the link more visible and easier to use, I converted it to a larger Unicode scroll symbol, then added some tooltip tech to make it show information about the link like so:

There was some community debate about including this, and about how prominent to make it. I think we ended up a little too cryptic and subtle with this section mark, but I welcome the addition and find it extraordinarily useful. I’d love to see the www Postgres project adopt a bigger symbol and tooltips in the future too!

The Postgres project takes the quality of its code very seriously, and that extends to the git commit messages as well. You will find them quite detailed; they not only describe the change that has been made, but have a link back to the mailing list discussion, as well as giving credit to the people who authored the change, discovered the bug, or otherwise helped out. A great new addition to the release notes! ]]> fe2e381fe3d770d3ce23b77158ba10800b5b32895408db4affbd897f334bd59c Wed, 09 Oct 2024 17:30:00 EDT 2024-10-09T21:30:00.000Z 2024-10-09T21:30:00.000Z https://www.crunchydata.com/blog/understanding-the-postgres-hackers-mailing-list The Postgres hackers mailing list (pgsql-hackers@postgresql.org) is an invaluable resource for anyone wanting to contribute to the PostgreSQL code. The Postgres project does not use PRs (pull requests) or GitHub issues. So if you want to contribute an idea, or help with code reviews, the hackers mailing list is the canonical way to do so. More information on contributing is on the Postgres wiki at: https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer? My colleague Elizabeth Christensen has short primer talk on contributing to Postgres as well.

HOWEVER...the -hackers mailing list is busy. Very, very busy. And dense. And filled with jargon and obscure terms. In short, it does not make for light reading. But here's the most important rule: you don't have to read everything. You don't even have to read every subject line. Just do your best.

Do not worry if you do not understand everything you read. Very few people (hello to my colleague Tom! ) know the code so well they can easily figure out what every post on -hackers is talking about. I am not one of those people. You will not be either, and that is perfectly okay. Focus on the parts of Postgres that are of interest to you. Over time, you will be able to understand more and more.

Here are my rules for staying sane while reading the Postgres hackers mailing list:

• Do not try to read everything; skim the subject lines
• Use a good email client that does proper threading
• Set a routine - if you are reading even a small portion of the messages, you likely need to do it at least once a day
• Be willing to let threads go
• If your backlog gets too big, just "mark all read”!

Jargon

The mailing lists are full of acronyms and jargon that might not be familiar to younger people who did not grow up on email (although text messages have inherited many of the abbreviations). If you are a non-native English speaker, or under the age of 30, or not steeped in the world of tech, I offer some solutions below.

To do this, I downloaded the last year's worth of hackers email, wrote a program to strip out all the non-human stuff (headers, code blocks, attachments, etc.), and then did some data analysis on the results.

VERSION CONTROL

Postgres uses the git version control system, which means there is quite a bit of assumed git knowledge and git-related phrases, such as:

• diff = the output of a "diff" or "git diff" command, showing what has changed "Looking at the diffs of these, I wonder if …"
• 1f47afd8 = reference to a git object / commit ID Always at least a 7 digit hexadecimal, often 9, or 12, or sometimes longer "30e7c175b81 removed support for dumping..."
• HEAD - the current main, active branch within git "patch was not applying on top of HEAD because"
• rebase - the process of using 'git rebase' to create a new version of a patch, which takes into account code changes since the time the patch was created "Please find attached v2, mandatory rebase due to cd312adc56"

BUILDING, TESTING, and PATCHING

Making a patch means compiling Postgres with your changes, submitting one or more patches to the mailing list, entering it in the commitfest app, and having it go through the CI (continuous integration) system. Here are some related terms:

• +1 = a general stamp of approval for someone's idea or patch. Sometimes seen as disapproval via -1
• meson = a program used to build Postgres. The successor to the old "configure" system
• gcc, clang = two main compilers used to build Postgres. There are others.
• backpatching = the process of taking a patch and applying the changes to older (but still supported) major versions of Postgres. Not everything can be backpatched - the default is to NOT backpatch unless it is deemed important enough.
• 0001, 0002 = refers to the patch attached in the email thread. Most people create patches using "git format-patch", which creates one file per commit, and numbers them as 0001, 0002, 0003, etc.
• commitfest - An external site that lives here: https://commitfest.postgresql.org/ It's job is to store the current state of all patches, and it contains many links back to the mailing lists.
• CF = commitfest
• CFM = commitfest manager
• RMT = release management team
• buildfarm - An external site that lives here: https://buildfarm.postgresql.org/ This is a distributed CI (continuous integration) system, run by volunteers all over the world, that tests Postgres after each commit.
• curculio wrasse lorikeet - every server in the buildfarm gets assigned a unique animal name, so you may see some obscure animals mentioned on the lists.
• cfbot - an automated system that creates git threads based on the commitfest entries, and gathers the results of CI testing (http://cfbot.cputube.org/)
• Coverity = an external tool used to try and detect problems with the code
• s/This/That/ = someone is suggesting changing the text to replace "This" with "That"
• OOM = out of memory

Acronyms Used in Postgres Development

These are acronyms that are often used by people on the mailing list. The more common ones are at the top. Each has a sample usage as actually used on the list in the last year. The most common acronym is IMO aka "in my opinion". This proves that us hackers are a very opinionated bunch!

• IMO = in my opinion "IMO there should be some simple test cases"
• FWIW = for what it's worth "FWIW I think it's a fairly serious issue"
• IIUC = if I understand correctly "IIUC what you're saying is that we should"
• BTW = by the way "BTW some drivers also send Describe even before Bind"
• IMHO = in my humble opinion. A slightly politer way to say IMO "IMHO, this is not a good direction"
• LGTM = looks good to me (especially in regards to a patch) "Did a quick check and still LGTM"
• PFA / PSA = please find attached / please see attached "PFA the small patch that implements this"
• AFAICT = as far as I can tell "AFAICT, this world target doesn't include the man target"
• OTOH = on the other hand "OTOH, maybe the current code is more readable"
• IIRC = if I recall correctly "IIRC, we have some similar issues in other hooks"
• AFAICS = as far as I can see "AFAICS, only assert-enabled LLVM builds crash"
• WIP = work in progress "Here's a new WIP version of the patch”
• ISTM = it seems to me "ISTM that the fix here is to not use a spinlock"
• AFAIK = as far as I know "AFAIK that guarantees it happens after"
• TBH = to be honest "TBH, I am wondering what is the purpose of this sentence"
• FYI = for your information "FYI, I also ran the patch"
• WFM = works for me "Both suggestions WFM"
• IMV = in my view "You really need diagrams for something like this IMV"
• IOW = in other words "IOW, search path is a bandaid for this kind of thing”
• POV = point of view "From my POV the idea seems reasonable"
• OP = original poster (the person who started the email thread) "The OP suggests archiving the timeline history file"
• AFAIU = as far as I understand "AFAIU currently we do not add Memoize nodes"
• YMMV = your mileage may vary "I find it easy to read if the GUC parameters are quoted, but YMMV"
• FTR = for the record. Also JFTR = "just for the record"* "FTR this has been discussed in the past"
• IME = in my experience "often that's hard, and IME is rarely done"
• AFAIR = as far as I recall "AFAIR, we don't prevent similar invalidations"
• ASAP = as soon as possible "something merged that fixes the bug ASAP"
• AIUI = as I understand it "which AIUI has never been committed"
• TBD = to be determined ”something TBD at time of implementation"
• WRT = with regards to "discussion about this WRT renaming macros"
• WDYT? = what do you think? "I expanded that into the following. WDYT?"
• IDK = I don't know "IDK, to me something like this seems to promise more than we can actually use"

Common Postgres Acronyms

While this is far from a canonical list, here are some of the more common Postgres-related terms you might run across. Again, these are in order of frequency:

• WAL = write-ahead log
• GUC = grand unified configuration. Basically, a configuration variable
• LSN = log sequence number, a specific address in the WAL stream
• API = application programming interface
• OID = object identifier
• TOAST = the oversized attribute storage technique
• FSM = free space map
• SAOP = scalar array operator (note: not a misspelling of SOAP!)
• ABI = application binary interface
• RLS = row-level security
• DSM = dynamic shared memory
• TPS = transactions per second
• TLI = timeline ID
• EOL = end of life
• 2PC = two-part commit
• LRU = least recently used strategy
• PITR = point-in-time recovery
• CTAS = create table as select
• CIC = concurrent index creation
• TAM = table access method
• RNG = random number generator
• LTO = link time optimization
• POLA = principle of least astonishment
• LR = logical replication

FUNNY PHRASES

Finally, there are some phrases that might not have a direct translation from English, but are common on the list:

• spitballing = throwing ideas out without much concern of feasibility or correctness.
• footgun = something dangerous that might cause you to shoot your own foot off, in other words, something that may cause serious problems too easily
• paint into a corner = getting into a difficult situation with no way out
• bikeshedding = focusing on minor details of something (such as the color of a bike shed) rather than focusing on the larger, more important details (such as the material to use, how sturdy the shed is, etc.)
• firehose = a strong, excessive amount of information that can be hard to consume. Such as the pgsql-hackers mailing list!

That’s my collection! Again, this is not meant to be a canonical list, but I hope it is useful for those that may not be familiar with some of the terms above. If you are posting to the list, consider limiting the use of acronyms and jargon to only the most popular ones, or eschew them completely. TIA! (thanks in advance) ]]> 3d4af8f33df143e8f207c0f3952fd08ee89d9a196d79bbdc67f1eb570ac71eda Thu, 29 Aug 2024 15:30:00 EDT 2024-08-29T19:30:00.000Z 2024-08-29T19:30:00.000Z