| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Something is wrong with wal_compression |
| Date: | 2023-01-28 04:11:38 |
| Message-ID: | 20230128041138.nmgfkg2uhoiep74g@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-01-27 19:49:17 -0800, Andres Freund wrote:
> It's quite commonly used as part of trigger based replication tools (IIRC
> that's its origin), monitoring, as part of client side logging, as part of
> snapshot management.
Forgot one: Queues.
The way it's used for trigger based replication, queues and also some
materialized aggregation tooling, is that there's a trigger that inserts into
a "log" table. And that log table has a column into which txid_current() will
be inserted. Together with txid_current_snapshot() etc that's used to get a
(at least semi) "transactional" order out of such log tables.
I believe that's originally been invented by londiste / skytool, later slony
migrated to it. The necessary C code was added as contrib/txid in 1f92630fc4e
2007-10-07 and then moved into core a few days later in 18e3fcc31e7.
For those cases making txid_current() flush would approximately double the WAL
flush rate.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2023-01-28 04:17:46 | Re: recovery modules |
| Previous Message | houzj.fnst@fujitsu.com | 2023-01-28 04:06:26 | RE: Deadlock between logrep apply worker and tablesync worker |