Re: [HACKERS] COPY vs. transition tables
> "Andrew" == Andrew Gierth writes: > "Thomas" == Thomas Munro writes: Thomas> Here it is. Added to open items. Andrew> On it. Committed. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] COPY vs. transition tables
> "Thomas" == Thomas Munro writes: Thomas> Here it is. Added to open items. On it. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] COPY vs. transition tables
On Sun, Jul 9, 2017 at 11:46 AM, Thomas Munro wrote: > On Sat, Jul 8, 2017 at 8:42 PM, David Fetter 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 copy-with-indexes-and-transitions-v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] COPY vs. transition tables
On Sun, Jul 09, 2017 at 11:46:03AM +1200, Thomas Munro wrote: > On Sat, Jul 8, 2017 at 8:42 PM, David Fetter 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 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
Re: [HACKERS] COPY vs. transition tables
On Sat, Jul 8, 2017 at 8:42 PM, David Fetter 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 copy-with-indexes-and-transitions.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[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 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
logging_infra.sql
Description: copy_oddity.sql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
