Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
-- predictability
|
|
|
|
|
SET synchronous_commit = on;
|
|
|
|
|
SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding');
|
|
|
|
|
?column?
|
|
|
|
|
----------
|
|
|
|
|
init
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- fail because of an already existing slot
|
|
|
|
|
SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding');
|
|
|
|
|
ERROR: replication slot "regression_slot" already exists
|
|
|
|
|
-- fail because of an invalid name
|
|
|
|
|
SELECT 'init' FROM pg_create_logical_replication_slot('Invalid Name', 'test_decoding');
|
|
|
|
|
ERROR: replication slot name "Invalid Name" contains invalid character
|
2015-10-03 15:29:08 +02:00
|
|
|
HINT: Replication slot names may only contain lower case letters, numbers, and the underscore character.
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
-- fail twice because of an invalid parameter values
|
|
|
|
|
SELECT 'init' FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', 'frakbar');
|
|
|
|
|
ERROR: could not parse value "frakbar" for parameter "include-xids"
|
|
|
|
|
CONTEXT: slot "regression_slot", output plugin "test_decoding", in the startup callback
|
2019-06-08 19:12:26 +02:00
|
|
|
SELECT 'init' FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'nonexistent-option', 'frakbar');
|
|
|
|
|
ERROR: option "nonexistent-option" = "frakbar" is unknown
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
CONTEXT: slot "regression_slot", output plugin "test_decoding", in the startup callback
|
|
|
|
|
SELECT 'init' FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', 'frakbar');
|
|
|
|
|
ERROR: could not parse value "frakbar" for parameter "include-xids"
|
|
|
|
|
CONTEXT: slot "regression_slot", output plugin "test_decoding", in the startup callback
|
|
|
|
|
-- succeed once
|
|
|
|
|
SELECT pg_drop_replication_slot('regression_slot');
|
|
|
|
|
pg_drop_replication_slot
|
|
|
|
|
--------------------------
|
|
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- fail
|
|
|
|
|
SELECT pg_drop_replication_slot('regression_slot');
|
|
|
|
|
ERROR: replication slot "regression_slot" does not exist
|
2014-03-05 18:55:43 +01:00
|
|
|
-- check that we're detecting a streaming rep slot used for logical decoding
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
SELECT 'init' FROM pg_create_physical_replication_slot('repl');
|
|
|
|
|
?column?
|
|
|
|
|
----------
|
|
|
|
|
init
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('repl', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
ERROR: cannot use physical replication slot for logical decoding
|
|
|
|
|
SELECT pg_drop_replication_slot('repl');
|
|
|
|
|
pg_drop_replication_slot
|
|
|
|
|
--------------------------
|
|
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding');
|
|
|
|
|
?column?
|
|
|
|
|
----------
|
|
|
|
|
init
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
/* check whether status function reports us, only reproduceable columns */
|
|
|
|
|
SELECT slot_name, plugin, slot_type, active,
|
|
|
|
|
NOT catalog_xmin IS NULL AS catalog_xmin_set,
|
|
|
|
|
xmin IS NULl AS data_xmin_not_set,
|
2017-05-11 17:49:59 +02:00
|
|
|
pg_wal_lsn_diff(restart_lsn, '0/01000000') > 0 AS some_wal
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
FROM pg_replication_slots;
|
|
|
|
|
slot_name | plugin | slot_type | active | catalog_xmin_set | data_xmin_not_set | some_wal
|
|
|
|
|
-----------------+---------------+-----------+--------+------------------+-------------------+----------
|
|
|
|
|
regression_slot | test_decoding | logical | f | t | t | t
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check that changes are handled correctly when interleaved with ddl
|
|
|
|
|
*/
|
|
|
|
|
CREATE TABLE replication_example(id SERIAL PRIMARY KEY, somedata int, text varchar(120));
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO replication_example(somedata, text) VALUES (1, 1);
|
|
|
|
|
INSERT INTO replication_example(somedata, text) VALUES (1, 2);
|
|
|
|
|
COMMIT;
|
|
|
|
|
ALTER TABLE replication_example ADD COLUMN bar int;
|
|
|
|
|
INSERT INTO replication_example(somedata, text, bar) VALUES (2, 1, 4);
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO replication_example(somedata, text, bar) VALUES (2, 2, 4);
|
|
|
|
|
INSERT INTO replication_example(somedata, text, bar) VALUES (2, 3, 4);
|
|
|
|
|
INSERT INTO replication_example(somedata, text, bar) VALUES (2, 4, NULL);
|
|
|
|
|
COMMIT;
|
|
|
|
|
ALTER TABLE replication_example DROP COLUMN bar;
|
|
|
|
|
INSERT INTO replication_example(somedata, text) VALUES (3, 1);
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO replication_example(somedata, text) VALUES (3, 2);
|
|
|
|
|
INSERT INTO replication_example(somedata, text) VALUES (3, 3);
|
|
|
|
|
COMMIT;
|
|
|
|
|
ALTER TABLE replication_example RENAME COLUMN text TO somenum;
|
|
|
|
|
INSERT INTO replication_example(somedata, somenum) VALUES (4, 1);
|
|
|
|
|
-- collect all changes
|
2022-02-12 00:46:07 +01:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1', 'include-sequences', '0');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
---------------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:1 somedata[integer]:1 text[character varying]:'1'
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:2 somedata[integer]:1 text[character varying]:'2'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:3 somedata[integer]:2 text[character varying]:'1' bar[integer]:4
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:4 somedata[integer]:2 text[character varying]:'2' bar[integer]:4
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:5 somedata[integer]:2 text[character varying]:'3' bar[integer]:4
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:6 somedata[integer]:2 text[character varying]:'4' bar[integer]:null
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:7 somedata[integer]:3 text[character varying]:'1'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:8 somedata[integer]:3 text[character varying]:'2'
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:9 somedata[integer]:3 text[character varying]:'3'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:10 somedata[integer]:4 somenum[character varying]:'1'
|
|
|
|
|
COMMIT
|
2014-09-01 13:42:43 +02:00
|
|
|
(22 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
ALTER TABLE replication_example ALTER COLUMN somenum TYPE int4 USING (somenum::int4);
|
2018-03-21 14:13:24 +01:00
|
|
|
-- check that this doesn't produce any changes from the heap rewrite
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT count(data) FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
count
|
|
|
|
|
-------
|
2018-03-21 14:13:24 +01:00
|
|
|
0
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
INSERT INTO replication_example(somedata, somenum) VALUES (5, 1);
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO replication_example(somedata, somenum) VALUES (6, 1);
|
|
|
|
|
ALTER TABLE replication_example ADD COLUMN zaphod1 int;
|
|
|
|
|
INSERT INTO replication_example(somedata, somenum, zaphod1) VALUES (6, 2, 1);
|
|
|
|
|
ALTER TABLE replication_example ADD COLUMN zaphod2 int;
|
|
|
|
|
INSERT INTO replication_example(somedata, somenum, zaphod2) VALUES (6, 3, 1);
|
|
|
|
|
INSERT INTO replication_example(somedata, somenum, zaphod1) VALUES (6, 4, 2);
|
|
|
|
|
COMMIT;
|
|
|
|
|
-- show changes
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:11 somedata[integer]:5 somenum[integer]:1
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:12 somedata[integer]:6 somenum[integer]:1
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:13 somedata[integer]:6 somenum[integer]:2 zaphod1[integer]:1
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:14 somedata[integer]:6 somenum[integer]:3 zaphod1[integer]:null zaphod2[integer]:1
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:15 somedata[integer]:6 somenum[integer]:4 zaphod1[integer]:2 zaphod2[integer]:null
|
|
|
|
|
COMMIT
|
|
|
|
|
(9 rows)
|
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
-- ON CONFLICT DO UPDATE support
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO replication_example(id, somedata, somenum) SELECT i, i, i FROM generate_series(-15, 15) i
|
|
|
|
|
ON CONFLICT (id) DO UPDATE SET somenum = excluded.somenum + 1;
|
|
|
|
|
COMMIT;
|
2015-05-08 06:06:03 +02:00
|
|
|
/* display results */
|
|
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
|
|
|
|
data
|
|
|
|
|
--------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-15 somedata[integer]:-15 somenum[integer]:-15 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-14 somedata[integer]:-14 somenum[integer]:-14 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-13 somedata[integer]:-13 somenum[integer]:-13 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-12 somedata[integer]:-12 somenum[integer]:-12 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-11 somedata[integer]:-11 somenum[integer]:-11 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-10 somedata[integer]:-10 somenum[integer]:-10 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-9 somedata[integer]:-9 somenum[integer]:-9 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-8 somedata[integer]:-8 somenum[integer]:-8 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-7 somedata[integer]:-7 somenum[integer]:-7 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-6 somedata[integer]:-6 somenum[integer]:-6 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-5 somedata[integer]:-5 somenum[integer]:-5 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-4 somedata[integer]:-4 somenum[integer]:-4 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-3 somedata[integer]:-3 somenum[integer]:-3 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-2 somedata[integer]:-2 somenum[integer]:-2 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:-1 somedata[integer]:-1 somenum[integer]:-1 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: INSERT: id[integer]:0 somedata[integer]:0 somenum[integer]:0 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:1 somedata[integer]:1 somenum[integer]:2 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:2 somedata[integer]:1 somenum[integer]:3 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:3 somedata[integer]:2 somenum[integer]:4 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:4 somedata[integer]:2 somenum[integer]:5 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:5 somedata[integer]:2 somenum[integer]:6 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:6 somedata[integer]:2 somenum[integer]:7 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:7 somedata[integer]:3 somenum[integer]:8 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:8 somedata[integer]:3 somenum[integer]:9 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:9 somedata[integer]:3 somenum[integer]:10 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:10 somedata[integer]:4 somenum[integer]:11 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:11 somedata[integer]:5 somenum[integer]:12 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:12 somedata[integer]:6 somenum[integer]:13 zaphod1[integer]:null zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:13 somedata[integer]:6 somenum[integer]:14 zaphod1[integer]:1 zaphod2[integer]:null
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:14 somedata[integer]:6 somenum[integer]:15 zaphod1[integer]:null zaphod2[integer]:1
|
|
|
|
|
table public.replication_example: UPDATE: id[integer]:15 somedata[integer]:6 somenum[integer]:16 zaphod1[integer]:2 zaphod2[integer]:null
|
|
|
|
|
COMMIT
|
|
|
|
|
(33 rows)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
CREATE TABLE tr_unique(id2 serial unique NOT NULL, data int);
|
|
|
|
|
INSERT INTO tr_unique(data) VALUES(10);
|
|
|
|
|
ALTER TABLE tr_unique RENAME TO tr_pkey;
|
|
|
|
|
ALTER TABLE tr_pkey ADD COLUMN id serial primary key;
|
2022-02-12 00:46:07 +01:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1', 'include-rewrites', '1', 'include-sequences', '0');
|
2018-03-21 14:13:24 +01:00
|
|
|
data
|
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_unique: INSERT: id2[integer]:1 data[integer]:10
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_pkey: INSERT: id2[integer]:1 data[integer]:10 id[integer]:1
|
|
|
|
|
COMMIT
|
|
|
|
|
(6 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
INSERT INTO tr_pkey(data) VALUES(1);
|
|
|
|
|
--show deletion with primary key
|
|
|
|
|
DELETE FROM tr_pkey;
|
|
|
|
|
/* display results */
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_pkey: INSERT: id2[integer]:2 data[integer]:1 id[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_pkey: DELETE: id[integer]:1
|
|
|
|
|
table public.tr_pkey: DELETE: id[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
(7 rows)
|
|
|
|
|
|
|
|
|
|
/*
|
2016-04-06 11:05:41 +02:00
|
|
|
* check that disk spooling works (also for logical messages)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
*/
|
|
|
|
|
BEGIN;
|
|
|
|
|
CREATE TABLE tr_etoomuch (id serial primary key, data int);
|
|
|
|
|
INSERT INTO tr_etoomuch(data) SELECT g.i FROM generate_series(1, 10234) g(i);
|
2016-04-06 11:05:41 +02:00
|
|
|
SELECT 'tx logical msg' FROM pg_logical_emit_message(true, 'test', 'tx logical msg');
|
|
|
|
|
?column?
|
|
|
|
|
----------------
|
|
|
|
|
tx logical msg
|
|
|
|
|
(1 row)
|
|
|
|
|
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
DELETE FROM tr_etoomuch WHERE id < 5000;
|
|
|
|
|
UPDATE tr_etoomuch SET data = - data WHERE id > 5000;
|
Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.
When re-reading an update involving both an old tuple and a new tuple from
disk, reorderbuffer.c was careless about whether the new tuple is suitably
aligned for direct access --- in general, it isn't. We'd missed seeing
this in the buildfarm because the contrib/test_decoding tests exercise this
code path only a few times, and by chance all of those cases have old
tuples with length a multiple of 4, which is usually enough to make the
access to the new tuple's t_len safe. For some still-not-entirely-clear
reason, however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?
The lack of previous field reports is probably because you need all of
these conditions to trigger a crash: an alignment-picky platform (not
Intel), a transaction large enough to spill to disk, an update within
that xact that changes a primary-key field and has an odd-length old tuple,
and of course logical decoding tracing the transaction.
Avoid the alignment assumption by using memcpy instead of fetching t_len
directly, and add a test case that exposes the crash on picky platforms.
Back-patch to 9.4 where the bug was introduced.
Discussion: <20160413094117.GC21485@msg.credativ.de>
2016-04-15 01:42:21 +02:00
|
|
|
CREATE TABLE tr_oddlength (id text primary key, data text);
|
|
|
|
|
INSERT INTO tr_oddlength VALUES('ab', 'foo');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
COMMIT;
|
|
|
|
|
/* display results, but hide most of the output */
|
|
|
|
|
SELECT count(*), min(data), max(data)
|
2022-02-12 00:46:07 +01:00
|
|
|
FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1', 'include-sequences', '0')
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
GROUP BY substring(data, 1, 24)
|
2014-03-29 05:31:44 +01:00
|
|
|
ORDER BY 1,2;
|
2016-04-06 11:05:41 +02:00
|
|
|
count | min | max
|
|
|
|
|
-------+-----------------------------------------------------------------------+------------------------------------------------------------------------
|
|
|
|
|
1 | BEGIN | BEGIN
|
|
|
|
|
1 | COMMIT | COMMIT
|
|
|
|
|
1 | message: transactional: 1 prefix: test, sz: 14 content:tx logical msg | message: transactional: 1 prefix: test, sz: 14 content:tx logical msg
|
Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.
When re-reading an update involving both an old tuple and a new tuple from
disk, reorderbuffer.c was careless about whether the new tuple is suitably
aligned for direct access --- in general, it isn't. We'd missed seeing
this in the buildfarm because the contrib/test_decoding tests exercise this
code path only a few times, and by chance all of those cases have old
tuples with length a multiple of 4, which is usually enough to make the
access to the new tuple's t_len safe. For some still-not-entirely-clear
reason, however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?
The lack of previous field reports is probably because you need all of
these conditions to trigger a crash: an alignment-picky platform (not
Intel), a transaction large enough to spill to disk, an update within
that xact that changes a primary-key field and has an odd-length old tuple,
and of course logical decoding tracing the transaction.
Avoid the alignment assumption by using memcpy instead of fetching t_len
directly, and add a test case that exposes the crash on picky platforms.
Back-patch to 9.4 where the bug was introduced.
Discussion: <20160413094117.GC21485@msg.credativ.de>
2016-04-15 01:42:21 +02:00
|
|
|
1 | table public.tr_oddlength: INSERT: id[text]:'ab' data[text]:'foo' | table public.tr_oddlength: INSERT: id[text]:'ab' data[text]:'foo'
|
2016-04-06 11:05:41 +02:00
|
|
|
20467 | table public.tr_etoomuch: DELETE: id[integer]:1 | table public.tr_etoomuch: UPDATE: id[integer]:9999 data[integer]:-9999
|
Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.
When re-reading an update involving both an old tuple and a new tuple from
disk, reorderbuffer.c was careless about whether the new tuple is suitably
aligned for direct access --- in general, it isn't. We'd missed seeing
this in the buildfarm because the contrib/test_decoding tests exercise this
code path only a few times, and by chance all of those cases have old
tuples with length a multiple of 4, which is usually enough to make the
access to the new tuple's t_len safe. For some still-not-entirely-clear
reason, however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?
The lack of previous field reports is probably because you need all of
these conditions to trigger a crash: an alignment-picky platform (not
Intel), a transaction large enough to spill to disk, an update within
that xact that changes a primary-key field and has an odd-length old tuple,
and of course logical decoding tracing the transaction.
Avoid the alignment assumption by using memcpy instead of fetching t_len
directly, and add a test case that exposes the crash on picky platforms.
Back-patch to 9.4 where the bug was introduced.
Discussion: <20160413094117.GC21485@msg.credativ.de>
2016-04-15 01:42:21 +02:00
|
|
|
(5 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
2016-03-06 03:02:20 +01:00
|
|
|
-- check updates of primary keys work correctly
|
|
|
|
|
BEGIN;
|
|
|
|
|
CREATE TABLE spoolme AS SELECT g.i FROM generate_series(1, 5000) g(i);
|
|
|
|
|
UPDATE tr_etoomuch SET id = -id WHERE id = 5000;
|
Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.
When re-reading an update involving both an old tuple and a new tuple from
disk, reorderbuffer.c was careless about whether the new tuple is suitably
aligned for direct access --- in general, it isn't. We'd missed seeing
this in the buildfarm because the contrib/test_decoding tests exercise this
code path only a few times, and by chance all of those cases have old
tuples with length a multiple of 4, which is usually enough to make the
access to the new tuple's t_len safe. For some still-not-entirely-clear
reason, however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?
The lack of previous field reports is probably because you need all of
these conditions to trigger a crash: an alignment-picky platform (not
Intel), a transaction large enough to spill to disk, an update within
that xact that changes a primary-key field and has an odd-length old tuple,
and of course logical decoding tracing the transaction.
Avoid the alignment assumption by using memcpy instead of fetching t_len
directly, and add a test case that exposes the crash on picky platforms.
Back-patch to 9.4 where the bug was introduced.
Discussion: <20160413094117.GC21485@msg.credativ.de>
2016-04-15 01:42:21 +02:00
|
|
|
UPDATE tr_oddlength SET id = 'x', data = 'quux';
|
|
|
|
|
UPDATE tr_oddlength SET id = 'yy', data = 'a';
|
2016-03-06 03:02:20 +01:00
|
|
|
DELETE FROM spoolme;
|
|
|
|
|
DROP TABLE spoolme;
|
|
|
|
|
COMMIT;
|
|
|
|
|
SELECT data
|
|
|
|
|
FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1')
|
|
|
|
|
WHERE data ~ 'UPDATE';
|
|
|
|
|
data
|
|
|
|
|
-------------------------------------------------------------------------------------------------------------
|
|
|
|
|
table public.tr_etoomuch: UPDATE: old-key: id[integer]:5000 new-tuple: id[integer]:-5000 data[integer]:5000
|
Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.
When re-reading an update involving both an old tuple and a new tuple from
disk, reorderbuffer.c was careless about whether the new tuple is suitably
aligned for direct access --- in general, it isn't. We'd missed seeing
this in the buildfarm because the contrib/test_decoding tests exercise this
code path only a few times, and by chance all of those cases have old
tuples with length a multiple of 4, which is usually enough to make the
access to the new tuple's t_len safe. For some still-not-entirely-clear
reason, however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?
The lack of previous field reports is probably because you need all of
these conditions to trigger a crash: an alignment-picky platform (not
Intel), a transaction large enough to spill to disk, an update within
that xact that changes a primary-key field and has an odd-length old tuple,
and of course logical decoding tracing the transaction.
Avoid the alignment assumption by using memcpy instead of fetching t_len
directly, and add a test case that exposes the crash on picky platforms.
Back-patch to 9.4 where the bug was introduced.
Discussion: <20160413094117.GC21485@msg.credativ.de>
2016-04-15 01:42:21 +02:00
|
|
|
table public.tr_oddlength: UPDATE: old-key: id[text]:'ab' new-tuple: id[text]:'x' data[text]:'quux'
|
|
|
|
|
table public.tr_oddlength: UPDATE: old-key: id[text]:'x' new-tuple: id[text]:'yy' data[text]:'a'
|
|
|
|
|
(3 rows)
|
2016-03-06 03:02:20 +01:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
-- check that a large, spooled, upsert works
|
|
|
|
|
INSERT INTO tr_etoomuch (id, data)
|
|
|
|
|
SELECT g.i, -g.i FROM generate_series(8000, 12000) g(i)
|
|
|
|
|
ON CONFLICT(id) DO UPDATE SET data = EXCLUDED.data;
|
|
|
|
|
SELECT substring(data, 1, 29), count(*)
|
2016-10-13 03:31:45 +02:00
|
|
|
FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1') WITH ORDINALITY
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
GROUP BY 1
|
2016-10-13 03:31:45 +02:00
|
|
|
ORDER BY min(ordinality);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
substring | count
|
|
|
|
|
-------------------------------+-------
|
|
|
|
|
BEGIN | 1
|
|
|
|
|
table public.tr_etoomuch: UPD | 2235
|
|
|
|
|
table public.tr_etoomuch: INS | 1766
|
|
|
|
|
COMMIT | 1
|
|
|
|
|
(4 rows)
|
|
|
|
|
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
/*
|
|
|
|
|
* check whether we decode subtransactions correctly in relation with each
|
|
|
|
|
* other
|
|
|
|
|
*/
|
|
|
|
|
CREATE TABLE tr_sub (id serial primary key, path text);
|
|
|
|
|
-- toplevel, subtxn, toplevel, subtxn, subtxn
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('1-top-#1');
|
|
|
|
|
SAVEPOINT a;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('1-top-1-#1');
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('1-top-1-#2');
|
|
|
|
|
RELEASE SAVEPOINT a;
|
|
|
|
|
SAVEPOINT b;
|
|
|
|
|
SAVEPOINT c;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('1-top-2-1-#1');
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('1-top-2-1-#2');
|
|
|
|
|
RELEASE SAVEPOINT c;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('1-top-2-#1');
|
|
|
|
|
RELEASE SAVEPOINT b;
|
|
|
|
|
COMMIT;
|
2022-02-12 00:46:07 +01:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1', 'include-sequences', '0');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:1 path[text]:'1-top-#1'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:2 path[text]:'1-top-1-#1'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:3 path[text]:'1-top-1-#2'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:4 path[text]:'1-top-2-1-#1'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:5 path[text]:'1-top-2-1-#2'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:6 path[text]:'1-top-2-#1'
|
|
|
|
|
COMMIT
|
2014-09-01 13:42:43 +02:00
|
|
|
(8 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
-- check that we handle xlog assignments correctly
|
|
|
|
|
BEGIN;
|
|
|
|
|
-- nest 80 subtxns
|
|
|
|
|
SAVEPOINT subtop;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;SAVEPOINT a;
|
|
|
|
|
-- assign xid by inserting
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('2-top-1...--#1');
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('2-top-1...--#2');
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('2-top-1...--#3');
|
|
|
|
|
RELEASE SAVEPOINT subtop;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('2-top-#1');
|
|
|
|
|
COMMIT;
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:7 path[text]:'2-top-1...--#1'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:8 path[text]:'2-top-1...--#2'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:9 path[text]:'2-top-1...--#3'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:10 path[text]:'2-top-#1'
|
|
|
|
|
COMMIT
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
-- make sure rollbacked subtransactions aren't decoded
|
|
|
|
|
BEGIN;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('3-top-2-#1');
|
|
|
|
|
SAVEPOINT a;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('3-top-2-1-#1');
|
|
|
|
|
SAVEPOINT b;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('3-top-2-2-#1');
|
|
|
|
|
ROLLBACK TO SAVEPOINT b;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('3-top-2-#2');
|
|
|
|
|
COMMIT;
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
-----------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:11 path[text]:'3-top-2-#1'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:12 path[text]:'3-top-2-1-#1'
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:14 path[text]:'3-top-2-#2'
|
|
|
|
|
COMMIT
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
-- test whether a known, but not yet logged toplevel xact, followed by a
|
|
|
|
|
-- subxact commit is handled correctly
|
|
|
|
|
BEGIN;
|
2020-04-07 01:33:56 +02:00
|
|
|
SELECT pg_current_xact_id() != '0'; -- so no fixed xid apears in the outfile
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
?column?
|
|
|
|
|
----------
|
|
|
|
|
t
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
SAVEPOINT a;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('4-top-1-#1');
|
|
|
|
|
RELEASE SAVEPOINT a;
|
|
|
|
|
COMMIT;
|
|
|
|
|
-- test whether a change in a subtransaction, in an unknown toplevel
|
|
|
|
|
-- xact is handled correctly.
|
|
|
|
|
BEGIN;
|
|
|
|
|
SAVEPOINT a;
|
|
|
|
|
INSERT INTO tr_sub(path) VALUES ('5-top-1-#1');
|
|
|
|
|
COMMIT;
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
---------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:15 path[text]:'4-top-1-#1'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_sub: INSERT: id[integer]:16 path[text]:'5-top-1-#1'
|
|
|
|
|
COMMIT
|
|
|
|
|
(6 rows)
|
|
|
|
|
|
2019-02-12 22:42:37 +01:00
|
|
|
-- check that DDL in aborted subtransactions handled correctly
|
|
|
|
|
CREATE TABLE tr_sub_ddl(data int);
|
|
|
|
|
BEGIN;
|
|
|
|
|
SAVEPOINT a;
|
|
|
|
|
ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE text;
|
|
|
|
|
INSERT INTO tr_sub_ddl VALUES ('blah-blah');
|
|
|
|
|
ROLLBACK TO SAVEPOINT a;
|
|
|
|
|
ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE bigint;
|
|
|
|
|
INSERT INTO tr_sub_ddl VALUES(43);
|
|
|
|
|
COMMIT;
|
|
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
|
|
|
|
data
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.tr_sub_ddl: INSERT: data[bigint]:43
|
|
|
|
|
COMMIT
|
|
|
|
|
(3 rows)
|
|
|
|
|
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
/*
|
|
|
|
|
* Check whether treating a table as a catalog table works somewhat
|
|
|
|
|
*/
|
|
|
|
|
CREATE TABLE replication_metadata (
|
|
|
|
|
id serial primary key,
|
|
|
|
|
relation name NOT NULL,
|
|
|
|
|
options text[]
|
|
|
|
|
)
|
|
|
|
|
WITH (user_catalog_table = true)
|
|
|
|
|
;
|
|
|
|
|
\d+ replication_metadata
|
2016-11-03 17:00:00 +01:00
|
|
|
Table "public.replication_metadata"
|
|
|
|
|
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
|
|
|
|
|
----------+---------+-----------+----------+--------------------------------------------------+----------+--------------+-------------
|
|
|
|
|
id | integer | | not null | nextval('replication_metadata_id_seq'::regclass) | plain | |
|
|
|
|
|
relation | name | | not null | | plain | |
|
|
|
|
|
options | text[] | | | | extended | |
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
Indexes:
|
|
|
|
|
"replication_metadata_pkey" PRIMARY KEY, btree (id)
|
|
|
|
|
Options: user_catalog_table=true
|
|
|
|
|
|
|
|
|
|
INSERT INTO replication_metadata(relation, options)
|
|
|
|
|
VALUES ('foo', ARRAY['a', 'b']);
|
|
|
|
|
ALTER TABLE replication_metadata RESET (user_catalog_table);
|
|
|
|
|
\d+ replication_metadata
|
2016-11-03 17:00:00 +01:00
|
|
|
Table "public.replication_metadata"
|
|
|
|
|
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
|
|
|
|
|
----------+---------+-----------+----------+--------------------------------------------------+----------+--------------+-------------
|
|
|
|
|
id | integer | | not null | nextval('replication_metadata_id_seq'::regclass) | plain | |
|
|
|
|
|
relation | name | | not null | | plain | |
|
|
|
|
|
options | text[] | | | | extended | |
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
Indexes:
|
|
|
|
|
"replication_metadata_pkey" PRIMARY KEY, btree (id)
|
|
|
|
|
|
|
|
|
|
INSERT INTO replication_metadata(relation, options)
|
|
|
|
|
VALUES ('bar', ARRAY['a', 'b']);
|
|
|
|
|
ALTER TABLE replication_metadata SET (user_catalog_table = true);
|
|
|
|
|
\d+ replication_metadata
|
2016-11-03 17:00:00 +01:00
|
|
|
Table "public.replication_metadata"
|
|
|
|
|
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
|
|
|
|
|
----------+---------+-----------+----------+--------------------------------------------------+----------+--------------+-------------
|
|
|
|
|
id | integer | | not null | nextval('replication_metadata_id_seq'::regclass) | plain | |
|
|
|
|
|
relation | name | | not null | | plain | |
|
|
|
|
|
options | text[] | | | | extended | |
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
Indexes:
|
|
|
|
|
"replication_metadata_pkey" PRIMARY KEY, btree (id)
|
|
|
|
|
Options: user_catalog_table=true
|
|
|
|
|
|
|
|
|
|
INSERT INTO replication_metadata(relation, options)
|
|
|
|
|
VALUES ('blub', NULL);
|
|
|
|
|
-- make sure rewrites don't work
|
|
|
|
|
ALTER TABLE replication_metadata ADD COLUMN rewritemeornot int;
|
|
|
|
|
ALTER TABLE replication_metadata ALTER COLUMN rewritemeornot TYPE text;
|
|
|
|
|
ERROR: cannot rewrite table "replication_metadata" used as a catalog table
|
|
|
|
|
ALTER TABLE replication_metadata SET (user_catalog_table = false);
|
|
|
|
|
\d+ replication_metadata
|
2016-11-03 17:00:00 +01:00
|
|
|
Table "public.replication_metadata"
|
|
|
|
|
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
|
|
|
|
|
----------------+---------+-----------+----------+--------------------------------------------------+----------+--------------+-------------
|
|
|
|
|
id | integer | | not null | nextval('replication_metadata_id_seq'::regclass) | plain | |
|
|
|
|
|
relation | name | | not null | | plain | |
|
|
|
|
|
options | text[] | | | | extended | |
|
|
|
|
|
rewritemeornot | integer | | | | plain | |
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
Indexes:
|
|
|
|
|
"replication_metadata_pkey" PRIMARY KEY, btree (id)
|
|
|
|
|
Options: user_catalog_table=false
|
|
|
|
|
|
|
|
|
|
INSERT INTO replication_metadata(relation, options)
|
|
|
|
|
VALUES ('zaphod', NULL);
|
2022-02-12 00:46:07 +01:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1', 'include-sequences', '0');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_metadata: INSERT: id[integer]:1 relation[name]:'foo' options[text[]]:'{a,b}'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_metadata: INSERT: id[integer]:2 relation[name]:'bar' options[text[]]:'{a,b}'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_metadata: INSERT: id[integer]:3 relation[name]:'blub' options[text[]]:null
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.replication_metadata: INSERT: id[integer]:4 relation[name]:'zaphod' options[text[]]:null rewritemeornot[integer]:null
|
|
|
|
|
COMMIT
|
2014-09-01 13:42:43 +02:00
|
|
|
(12 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* check whether we handle updates/deletes correct with & without a pkey
|
|
|
|
|
*/
|
|
|
|
|
/* we should handle the case without a key at all more gracefully */
|
|
|
|
|
CREATE TABLE table_without_key(id serial, data int);
|
|
|
|
|
INSERT INTO table_without_key(data) VALUES(1),(2);
|
|
|
|
|
DELETE FROM table_without_key WHERE data = 1;
|
|
|
|
|
-- won't log old keys
|
|
|
|
|
UPDATE table_without_key SET data = 3 WHERE data = 2;
|
|
|
|
|
UPDATE table_without_key SET id = -id;
|
|
|
|
|
UPDATE table_without_key SET id = -id;
|
|
|
|
|
-- should log the full old row now
|
|
|
|
|
ALTER TABLE table_without_key REPLICA IDENTITY FULL;
|
|
|
|
|
UPDATE table_without_key SET data = 3 WHERE data = 2;
|
|
|
|
|
UPDATE table_without_key SET id = -id;
|
|
|
|
|
UPDATE table_without_key SET id = -id;
|
2015-06-27 18:49:00 +02:00
|
|
|
-- ensure that FULL correctly deals with new columns
|
|
|
|
|
ALTER TABLE table_without_key ADD COLUMN new_column text;
|
|
|
|
|
UPDATE table_without_key SET id = -id;
|
|
|
|
|
UPDATE table_without_key SET id = -id, new_column = 'someval';
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
DELETE FROM table_without_key WHERE data = 3;
|
|
|
|
|
CREATE TABLE table_with_pkey(id serial primary key, data int);
|
|
|
|
|
INSERT INTO table_with_pkey(data) VALUES(1), (2);
|
|
|
|
|
DELETE FROM table_with_pkey WHERE data = 1;
|
|
|
|
|
-- should log the old pkey
|
|
|
|
|
UPDATE table_with_pkey SET data = 3 WHERE data = 2;
|
|
|
|
|
UPDATE table_with_pkey SET id = -id;
|
|
|
|
|
UPDATE table_with_pkey SET id = -id;
|
|
|
|
|
-- check that we log nothing despite having a pkey
|
|
|
|
|
ALTER TABLE table_without_key REPLICA IDENTITY NOTHING;
|
|
|
|
|
UPDATE table_with_pkey SET id = -id;
|
|
|
|
|
-- check that we log everything despite having a pkey
|
|
|
|
|
ALTER TABLE table_without_key REPLICA IDENTITY FULL;
|
|
|
|
|
UPDATE table_with_pkey SET id = -id;
|
|
|
|
|
DELETE FROM table_with_pkey WHERE data = 3;
|
|
|
|
|
CREATE TABLE table_with_unique_not_null(id serial unique, data int);
|
|
|
|
|
ALTER TABLE table_with_unique_not_null ALTER COLUMN id SET NOT NULL; --already set
|
|
|
|
|
-- won't log anything, replica identity not setup
|
|
|
|
|
INSERT INTO table_with_unique_not_null(data) VALUES(1), (2);
|
|
|
|
|
DELETE FROM table_with_unique_not_null WHERE data = 1;
|
|
|
|
|
UPDATE table_with_unique_not_null SET data = 3 WHERE data = 2;
|
|
|
|
|
UPDATE table_with_unique_not_null SET id = -id;
|
|
|
|
|
UPDATE table_with_unique_not_null SET id = -id;
|
|
|
|
|
DELETE FROM table_with_unique_not_null WHERE data = 3;
|
|
|
|
|
-- should log old key
|
|
|
|
|
ALTER TABLE table_with_unique_not_null REPLICA IDENTITY USING INDEX table_with_unique_not_null_id_key;
|
|
|
|
|
INSERT INTO table_with_unique_not_null(data) VALUES(1), (2);
|
|
|
|
|
DELETE FROM table_with_unique_not_null WHERE data = 1;
|
|
|
|
|
UPDATE table_with_unique_not_null SET data = 3 WHERE data = 2;
|
|
|
|
|
UPDATE table_with_unique_not_null SET id = -id;
|
|
|
|
|
UPDATE table_with_unique_not_null SET id = -id;
|
|
|
|
|
DELETE FROM table_with_unique_not_null WHERE data = 3;
|
2020-08-26 13:42:27 +02:00
|
|
|
-- check tables with dropped indexes used in REPLICA IDENTITY
|
|
|
|
|
-- table with primary key
|
|
|
|
|
CREATE TABLE table_dropped_index_with_pk (a int PRIMARY KEY, b int, c int);
|
|
|
|
|
CREATE UNIQUE INDEX table_dropped_index_with_pk_idx
|
|
|
|
|
ON table_dropped_index_with_pk(a);
|
|
|
|
|
ALTER TABLE table_dropped_index_with_pk REPLICA IDENTITY
|
|
|
|
|
USING INDEX table_dropped_index_with_pk_idx;
|
|
|
|
|
DROP INDEX table_dropped_index_with_pk_idx;
|
|
|
|
|
INSERT INTO table_dropped_index_with_pk VALUES (1,1,1), (2,2,2), (3,3,3);
|
|
|
|
|
UPDATE table_dropped_index_with_pk SET a = 4 WHERE a = 1;
|
|
|
|
|
UPDATE table_dropped_index_with_pk SET b = 5 WHERE a = 2;
|
|
|
|
|
UPDATE table_dropped_index_with_pk SET b = 6, c = 7 WHERE a = 3;
|
|
|
|
|
DELETE FROM table_dropped_index_with_pk WHERE b = 1;
|
|
|
|
|
DELETE FROM table_dropped_index_with_pk WHERE a = 3;
|
|
|
|
|
DROP TABLE table_dropped_index_with_pk;
|
|
|
|
|
-- table without primary key
|
|
|
|
|
CREATE TABLE table_dropped_index_no_pk (a int NOT NULL, b int, c int);
|
|
|
|
|
CREATE UNIQUE INDEX table_dropped_index_no_pk_idx
|
|
|
|
|
ON table_dropped_index_no_pk(a);
|
|
|
|
|
ALTER TABLE table_dropped_index_no_pk REPLICA IDENTITY
|
|
|
|
|
USING INDEX table_dropped_index_no_pk_idx;
|
|
|
|
|
DROP INDEX table_dropped_index_no_pk_idx;
|
|
|
|
|
INSERT INTO table_dropped_index_no_pk VALUES (1,1,1), (2,2,2), (3,3,3);
|
|
|
|
|
UPDATE table_dropped_index_no_pk SET a = 4 WHERE a = 1;
|
|
|
|
|
UPDATE table_dropped_index_no_pk SET b = 5 WHERE a = 2;
|
|
|
|
|
UPDATE table_dropped_index_no_pk SET b = 6, c = 7 WHERE a = 3;
|
|
|
|
|
DELETE FROM table_dropped_index_no_pk WHERE b = 1;
|
|
|
|
|
DELETE FROM table_dropped_index_no_pk WHERE a = 3;
|
|
|
|
|
DROP TABLE table_dropped_index_no_pk;
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
-- check toast support
|
|
|
|
|
BEGIN;
|
|
|
|
|
CREATE SEQUENCE toasttable_rand_seq START 79 INCREMENT 1499; -- portable "random"
|
|
|
|
|
CREATE TABLE toasttable(
|
|
|
|
|
id serial primary key,
|
|
|
|
|
toasted_col1 text,
|
|
|
|
|
rand1 float8 DEFAULT nextval('toasttable_rand_seq'),
|
|
|
|
|
toasted_col2 text,
|
|
|
|
|
rand2 float8 DEFAULT nextval('toasttable_rand_seq')
|
|
|
|
|
);
|
|
|
|
|
COMMIT;
|
|
|
|
|
-- uncompressed external toast data
|
|
|
|
|
INSERT INTO toasttable(toasted_col1) SELECT string_agg(g.i::text, '') FROM generate_series(1, 2000) g(i);
|
|
|
|
|
-- compressed external toast data
|
|
|
|
|
INSERT INTO toasttable(toasted_col2) SELECT repeat(string_agg(to_char(g.i, 'FM0000'), ''), 50) FROM generate_series(1, 500) g(i);
|
|
|
|
|
-- update of existing column
|
|
|
|
|
UPDATE toasttable
|
|
|
|
|
SET toasted_col1 = (SELECT string_agg(g.i::text, '') FROM generate_series(1, 2000) g(i))
|
|
|
|
|
WHERE id = 1;
|
2022-02-12 00:46:07 +01:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1', 'include-sequences', '0');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: INSERT: id[integer]:1 data[integer]:1
|
|
|
|
|
table public.table_without_key: INSERT: id[integer]:2 data[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: UPDATE: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: UPDATE: id[integer]:-2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: UPDATE: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: UPDATE: old-key: id[integer]:2 data[integer]:3 new-tuple: id[integer]:-2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: UPDATE: old-key: id[integer]:-2 data[integer]:3 new-tuple: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
2015-06-27 18:49:00 +02:00
|
|
|
table public.table_without_key: UPDATE: old-key: id[integer]:2 data[integer]:3 new-tuple: id[integer]:-2 data[integer]:3 new_column[text]:null
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: UPDATE: old-key: id[integer]:-2 data[integer]:3 new-tuple: id[integer]:2 data[integer]:3 new_column[text]:'someval'
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_without_key: DELETE: id[integer]:2 data[integer]:3 new_column[text]:'someval'
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: INSERT: id[integer]:1 data[integer]:1
|
|
|
|
|
table public.table_with_pkey: INSERT: id[integer]:2 data[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: DELETE: id[integer]:1
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: UPDATE: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: UPDATE: old-key: id[integer]:2 new-tuple: id[integer]:-2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: UPDATE: old-key: id[integer]:-2 new-tuple: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: UPDATE: old-key: id[integer]:2 new-tuple: id[integer]:-2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: UPDATE: old-key: id[integer]:-2 new-tuple: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_pkey: DELETE: id[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: INSERT: id[integer]:1 data[integer]:1
|
|
|
|
|
table public.table_with_unique_not_null: INSERT: id[integer]:2 data[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: UPDATE: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: UPDATE: id[integer]:-2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: UPDATE: id[integer]:2 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: INSERT: id[integer]:3 data[integer]:1
|
|
|
|
|
table public.table_with_unique_not_null: INSERT: id[integer]:4 data[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: DELETE: id[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: UPDATE: id[integer]:4 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: UPDATE: old-key: id[integer]:4 new-tuple: id[integer]:-4 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: UPDATE: old-key: id[integer]:-4 new-tuple: id[integer]:4 data[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_with_unique_not_null: DELETE: id[integer]:4
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
2020-08-26 13:42:27 +02:00
|
|
|
table public.table_dropped_index_with_pk: INSERT: a[integer]:1 b[integer]:1 c[integer]:1
|
|
|
|
|
table public.table_dropped_index_with_pk: INSERT: a[integer]:2 b[integer]:2 c[integer]:2
|
|
|
|
|
table public.table_dropped_index_with_pk: INSERT: a[integer]:3 b[integer]:3 c[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_with_pk: UPDATE: a[integer]:4 b[integer]:1 c[integer]:1
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_with_pk: UPDATE: a[integer]:2 b[integer]:5 c[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_with_pk: UPDATE: a[integer]:3 b[integer]:6 c[integer]:7
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_with_pk: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_with_pk: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_no_pk: INSERT: a[integer]:1 b[integer]:1 c[integer]:1
|
|
|
|
|
table public.table_dropped_index_no_pk: INSERT: a[integer]:2 b[integer]:2 c[integer]:2
|
|
|
|
|
table public.table_dropped_index_no_pk: INSERT: a[integer]:3 b[integer]:3 c[integer]:3
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_no_pk: UPDATE: a[integer]:4 b[integer]:1 c[integer]:1
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_no_pk: UPDATE: a[integer]:2 b[integer]:5 c[integer]:2
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_no_pk: UPDATE: a[integer]:3 b[integer]:6 c[integer]:7
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_no_pk: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.table_dropped_index_no_pk: DELETE: (no-tuple-data)
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
table public.toasttable: INSERT: id[integer]:1 toasted_col1[text]:'1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.toasttable: INSERT: id[integer]:2 toasted_col1[text]:null rand1[double precision]:3077 toasted_col2[text]:'00010002000300040005000600070008000900100011001200130014001500160017001800190020002100220023002400250026002700280029003000310032003300340035003600370038003900400041004200430044004500460047004800490050005100520053005400550056005700580059006000610062006300640065006600670068006900700071007200730074007500760077007800790080008100820083008400850086008700880089009000910092009300940095009600970098009901000101010201030104010501060107010801090110011101120113011401150116011701180119012001210122012301240125012601270128012901300131013201330134013501360137013801390140014101420143014401450146014701480149015001510152015301540155015601570158015901600161016201630164016501660167016801690170017101720173017401750176017701780179018001810182018301840185018601870188018901900191019201930194019501960197019801990200020102020203020402050206020702080209021002110212021302140215021602170218021902200221022202230224022502260227022802290230023102320233023402350236023702380239024002410242024302440245024602470248024902500251025202530254025502560257025802590260026102620263026402650266026702680269027002710272027302740275027602770278027902800281028202830284028502860287028802890290029102920293029402950296029702980299030003010302030303040305030603070308030903100311031203130314031503160317031803190320032103220323032403250326032703280329033003310332033303340335033603370338033903400341034203430344034503460347034803490350035103520353035403550356035703580359036003610362036303640365036603670368036903700371037203730374037503760377037803790380038103820383038403850386038703880389039003910392039303940395039603970398039904000401040204030404040504060407040804090410041104120413041404150416041704180419042004210422042304240425042604270428042904300431043204330434043504360437043804390440044104420443044404450446044704480449045004510452045304540455045604570458045904600461046204630464046504660467046804690470047104720473047404750476047704780479048004810482048304840485048604870488048904900491049204930494049504960497049804990500000100020003000400050006000700080009001000110012001300140015001600170018001900200021002200230024002500260027002800290030003100320033003400350036003700380039004000410042004300440045004600470048004900500051005200530054005500560057005800590060006100620063006400650066006700680069007000710072007300740075007600770078007900800081008200830084008500860087008800890090009100920093009400950096009700980099010001010102010301040105010601070108010901100111011201130114011501160117011801190120012101220123012401250126012701280129013001310132013301340135013601370138013901400141014201430144014501460147014801490150015101520153015401550156015701580159016001610162016301640165016601670168016901700171017201730174017501760177017801790180018101820183018401850186018701880189019001910192019301940195019601970198019902000201020202030204020502060207020802090210021102120213021402150216021702180219022002210222022302240225022602270228022902300231023202330234023502360237023802390240024102420243024402450246024702480249025002510252025302540255025602570258025902600261026202630264026502660267026802690270027102720273027402750276027702780279028002810282028302840285028602870288028902900291029202930294029502960297029802990300030103020303030403050306030703080309031003110312031303140315031603170318031903200321032203230324032503260327032803290330033103320333033403350336033703380339034003410342034303440345034603470348034903500351035203530354035503560357035803590360036103620363036403650366036703680369037003710372037303740375037603770378037903800381038203830384038503860387038803890390039103920393039403950396039703980399040004010402040304040405040604070408040904100411041204130414041504160417041804190420042104220423042404250426042704280429043004310432043304340435043604370438043904400441044204430444044504460447044804490450045104520453045404550456045704580459046004610462046304640465046604670468046904700471047204730474047504760477047804790480048104820483048404850486048704880489049004910492049304
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.toasttable: UPDATE: id[integer]:1 toasted_col1[text]:'1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312
|
|
|
|
|
COMMIT
|
2020-08-26 13:42:27 +02:00
|
|
|
(143 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
INSERT INTO toasttable(toasted_col1) SELECT string_agg(g.i::text, '') FROM generate_series(1, 2000) g(i);
|
|
|
|
|
-- update of second column, first column unchanged
|
|
|
|
|
UPDATE toasttable
|
|
|
|
|
SET toasted_col2 = (SELECT string_agg(g.i::text, '') FROM generate_series(1, 2000) g(i))
|
|
|
|
|
WHERE id = 1;
|
|
|
|
|
-- make sure we decode correctly even if the toast table is gone
|
|
|
|
|
DROP TABLE toasttable;
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.toasttable: INSERT: id[integer]:3 toasted_col1[text]:'1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312
|
|
|
|
|
COMMIT
|
|
|
|
|
BEGIN
|
|
|
|
|
table public.toasttable: UPDATE: id[integer]:1 toasted_col1[text]:unchanged-toast-datum rand1[double precision]:79 toasted_col2[text]:'12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612
|
|
|
|
|
COMMIT
|
2014-09-01 13:42:43 +02:00
|
|
|
(6 rows)
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
|
|
|
|
|
-- done, free logical replication slot
|
2014-09-01 13:42:43 +02:00
|
|
|
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
data
|
|
|
|
|
------
|
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
|
|
SELECT pg_drop_replication_slot('regression_slot');
|
|
|
|
|
pg_drop_replication_slot
|
|
|
|
|
--------------------------
|
|
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
2014-05-16 10:23:17 +02:00
|
|
|
/* check that the slot is gone */
|
2020-03-31 21:37:24 +02:00
|
|
|
\x
|
2014-05-16 10:23:17 +02:00
|
|
|
SELECT * FROM pg_replication_slots;
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
(0 rows)
|
|
|
|
|
|
2020-03-31 21:37:24 +02:00
|
|
|
\x
|
