Thread: [HACKERS] COPY vs. transition tables
Folks,
Using the script attached, I'm getting this very odd result set below.
Audit records from COPY to the "foo bar" table aren't getting
recorded, but audit records from COPY to the baz table are.
Best,
David.
\i copy_oddity.sql
CREATE TABLE
COMMENT
CREATE FUNCTION
CREATE FUNCTION
CREATE EVENT TRIGGER
COMMENT
psql:logging_infra.sql:165: NOTICE: Adding log table(s) for public.foo bar
CREATE TABLE
INSERT 0 1
UPDATE 1
DELETE 1
COPY 5
timestamp | user | action | table_schema | table_name | old_row
| new_row
-------------------------------+---------+-------------------------------+--------------+------------+-----------------------+-----------------------
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | foo bar |
| {"t": null, "id": 1}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | foo bar | {"t": null,
"id":1} | {"t": "baz", "id": 1}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | foo bar | {"t": "baz",
"id":1} |
(3 rows)
psql:logging_infra.sql:180: NOTICE: Adding log table(s) for public.baz
psql:logging_infra.sql:180: NOTICE: relation "public_log" already exists, skipping
CREATE TABLE
COPY 5
timestamp | user | action | table_schema | table_name | old_row |
new_row
-------------------------------+---------+-------------------------------+--------------+------------+---------+------------
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | baz | | {"t":
"a"}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | baz | | {"t":
"b"}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | baz | | {"t":
"c"}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | baz | | {"t":
"d"}
2017-07-08 01:36:52.368228-07 | shackle | 2017-07-08 01:36:52.368228-07 | public | baz | | {"t":
"e"}
(5 rows)
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On Sat, Jul 8, 2017 at 8:42 PM, David Fetter <david@fetter.org> wrote: > Using the script attached, I'm getting this very odd result set below. > > Audit records from COPY to the "foo bar" table aren't getting > recorded, but audit records from COPY to the baz table are. Thanks for the bug report. I think it's the presence of the index on "foo bar", not the space in its name (but thanks for that curve ball!), that causes these tuples not to be captured. CopyFromInsertBatch takes a different path depending on whether there are any indexes, and mistakenly passes NULL for transition_capture. The attached seems to fix it, but I'll look more closely and send a version with a regression test on Monday. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On Sun, Jul 09, 2017 at 11:46:03AM +1200, Thomas Munro wrote: > On Sat, Jul 8, 2017 at 8:42 PM, David Fetter <david@fetter.org> wrote: > > Using the script attached, I'm getting this very odd result set below. > > > > Audit records from COPY to the "foo bar" table aren't getting > > recorded, but audit records from COPY to the baz table are. > > Thanks for the bug report. I think it's the presence of the index on > "foo bar", not the space in its name (but thanks for that curve > ball!), that causes these tuples not to be captured. Thanks for getting this fixed, and apologies for not trimming this down to a minimal repro. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Sun, Jul 9, 2017 at 11:46 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Sat, Jul 8, 2017 at 8:42 PM, David Fetter <david@fetter.org> wrote: >> Using the script attached, I'm getting this very odd result set below. >> >> Audit records from COPY to the "foo bar" table aren't getting >> recorded, but audit records from COPY to the baz table are. > > Thanks for the bug report. I think it's the presence of the index on > "foo bar", not the space in its name (but thanks for that curve > ball!), that causes these tuples not to be captured. > CopyFromInsertBatch takes a different path depending on whether there > are any indexes, and mistakenly passes NULL for transition_capture. > The attached seems to fix it, but I'll look more closely and send a > version with a regression test on Monday. Here it is. Added to open items. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
>>>>> "Thomas" == Thomas Munro <thomas.munro@enterprisedb.com> writes: Thomas> Here it is. Added to open items. On it. -- Andrew (irc:RhodiumToad)
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes: >>>>> "Thomas" == Thomas Munro <thomas.munro@enterprisedb.com> writes: Thomas> Here it is. Added to open items. Andrew> On it. Committed. -- Andrew (irc:RhodiumToad)