Re: BUG #18656: "STABLE" function sometimes does not see changes

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> CREATE or replace PROCEDURE stbl_update_state()
> LANGUAGE plpgsql AS
> $$
> declare
> s text;
> begin
> update stbl_states set state='on' where id=1;
> s := stbl_get_state(1);
> call stbl_log(s);
> call stbl_log(stbl_get_state(1));
> insert into stbl_logs(log) values (stbl_get_state(1));
> exception when others then
> s := SQLERRM;
> call stbl_log(s);
> end;
> $$;

> [ the second stbl_get_state call produces the wrong result ]

This seems closely related to 2dc1deaea, but that didn't fix it.
The key difference between this example and the tests added by
2dc1deaea is that the problematic CALL is inside an exception block.

After some study I propose that the correct fix is that
_SPI_execute_plan should act as though we're inside an atomic
context if IsSubTransaction(). We are inside an atomic context
so far as _SPI_commit and _SPI_rollback are concerned: they
will not allow you to COMMIT/ROLLBACK. So it's not very clear
why _SPI_execute_plan should think differently.

The attached draft patch also makes SPI_inside_nonatomic_context
say we're in an atomic context if IsSubTransaction(). That's a
no-op so far as the one extant caller StartTransaction is concerned,
because we won't get there when inside a subtransaction. But it
seems like all the places that consult _SPI_current->atomic ought
to be doing this the same way.

Thoughts?

regards, tom lane