On Tue, Feb 27, 2018 at 4:18 AM, Tom Kazimiers <[email protected]> wrote: > On Mon, Feb 26, 2018 at 11:15:44PM +1300, Thomas Munro wrote: >> On Sat, Feb 24, 2018 at 4:47 PM, Tom Kazimiers <[email protected]> >> wrote: >> Thanks for the reproducer. Yeah, that seems to be a bug. >> nodeNamedTuplestorescan.c allocates a new read pointer for each >> separate scan of the named tuplestore, but it doesn't call >> tuplestore_select_read_pointer() so that the two scans that appear in >> your UNION ALL plan are sharing the same read pointer. At first >> glance the attached seems to fix the problem, but I'll need to look >> more carefully tomorrow. > > Thanks very much for investigating this. I can confirm that applying your > patch results in the tuples I expected in both my test trigger and my actual > trigger function.
Thanks for testing.
> It would be great if this or a similar fix would make it into the next
> official release.
Here's a new version with tuplestore_select_read_pointer() added in
another place where it was lacking, and commit message. Moving to
-hackers, where patches go.
Here's a shorter repro. On master it prints:
NOTICE: count = 1
NOTICE: count union = 1
With the patch the second number is 2, as it should be.
CREATE TABLE test (i int);
INSERT INTO test VALUES (1);
CREATE OR REPLACE FUNCTION my_trigger_fun() RETURNS trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'count = %', (SELECT COUNT(*) FROM new_test);
RAISE NOTICE 'count union = %', (SELECT COUNT(*)
FROM (SELECT * FROM new_test UNION ALL SELECT * FROM new_test) ss);
RETURN NULL;
END;
$$;
CREATE TRIGGER my_trigger AFTER UPDATE ON test
REFERENCING NEW TABLE AS new_test OLD TABLE as old_test
FOR EACH STATEMENT EXECUTE PROCEDURE my_trigger_fun();
UPDATE test SET i = i;
--
Thomas Munro
http://www.enterprisedb.com
0001-Fix-tuplestore-read-pointer-confusion-in-nodeNamedtu.patch
Description: Binary data
