Re: [BUGS] Re: Bug with STABLE function using the wrong snapshot (probably during planning)
On May 13, 2011, at 12:46 AM, Tom Lane wrote: > Noah Misch writes: >>> Some initial debugging by RhodiumToad on #postgresql led to the following >>> observation: The error occurs only when the "SELECT ... WHERE i = a_bar();" >>> is being planned, not when it is being executed, with the snapshot being >>> used to plan the query apparently being too old to see the result of the >>> preceding insert. > >> The simplest fix I can see is to have _SPI_prepare_plan() push/pop a new >> snapshot when analyze_requires_snapshot() returns true on the raw parse tree. >> That strategy can break down in the other direction if the caller is STABLE; >> consider this example: > > Yes. I'm of the opinion that we should not change this. In general, > marking functions STABLE that have major side effects (such as throwing > errors) is not a good idea, and putting such things into WHERE clauses > is a worse one. We explicitly do not guarantee anything about timing or > order of evaluation in WHERE clauses, because to do so would cripple the > planner's ability to optimize them. So I think this is a "don't do > that" case rather than "we should try to make planning happen with the > same snapshot that will be used at execution" case. First of all, thanks to both of you for your replies to my email; at least now I understand a bit more of what went wrong. As I know almost nothing about the internals, I am not one to argue about whether or not to change the current behavior. It would however perhaps be nice to have the documentation of the volatility categories mention explicitly that throwing an error is also considered a (major) side-effect. In particular: apparently not only are modifications to the database itself considered side-effects, but so is "irregular" control flow within a procedural language... Based on the current documentation, I thought that as my function made no changes to the database and returns the same results given the same arguments for all rows within a single statement, it could safely be marked as STABLE. Regards, Matthijs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5984: Got FailedAssertion("!(opaque->btpo_prev == target)", File: "nbtpage.c", Line: 1166)
Hi Robert,
Sorry for the late reply, I was not here last week.
About your question: "That's kind of surprising, but I can't help wondering if
it's a bug in what virtualization tool you are using."I noticed the problem
FIRST on VM. And by pausing/stopping/launching a VM it was easy to get these
error back.
But since some weeks, I also had duplicates on real server. And same result if
I try to launch a VACUUM: crash with the same assertion.Which "stack trace on
the assertion failure" do you want to have ?
Regards,
Pascal BORSCHNECK
Arfy's blog http://www.arfy.fr
> Date: Wed, 11 May 2011 15:48:29 -0400
> Subject: Re: [BUGS] BUG #5984: Got FailedAssertion("!(opaque->btpo_prev ==
> target)", File: "nbtpage.c", Line: 1166)
> From: robertmh...@gmail.com
> To: borschn...@hotmail.com
> CC: pgsql-bugs@postgresql.org
>
> On Mon, Apr 18, 2011 at 5:16 AM, BORSCHNECK Pascal
> wrote:
> > Because I noticed that doing a pause to a VM (to make a VM copy for example)
> > often creates duplicates key problems error in the logs.
>
> That's kind of surprising, but I can't help wondering if it's a bug in
> what virtualization tool you are using.
>
> Any way to get a stack trace on the assertion failure?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
Re: [BUGS] BUG #6026: redundant sentences?
KOIZUMI Satoru wrote: > > The following bug has been logged online: > > Bug reference: 6026 > Logged by: KOIZUMI Satoru > Email address: koizumi...@minos.ocn.ne.jp > PostgreSQL version: 9.1beta1 > Operating system: MacOSX > Description:redundant sentences? > Details: > > In 5.6. Privileges, there are sentences "There are several different kinds > of privilege:...see the GRANT reference page. " in the first paragraph. > But in the second paragraph, there are similar sentences "There are several > different privileges:... refer to the GRANT reference page." > This would be redundant (except the sentence "The privileges applicable to > ..." in the second paragraph). Agreed. This was my mistake when I merged our privilege sections. Applied patch attached. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml new file mode 100644 index 03c1fa0..9709dd6 *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** ALTER TABLE products RENAME TO items; *** 1419,1436 (or a superuser) can do anything with the object. To allow other roles to use it, privileges must be granted. -There are several different kinds of privilege: SELECT, -INSERT, UPDATE, DELETE, -TRUNCATE, REFERENCES, TRIGGER, -CREATE, CONNECT, TEMPORARY, -EXECUTE, and USAGE. -For more information on the different types of privileges supported by -PostgreSQL, see the - reference page. !There are several different privileges: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, --- 1419,1428 (or a superuser) can do anything with the object. To allow other roles to use it, privileges must be granted. !There are different kinds of privileges: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Plperl trigger variables no longer global
On Sun, May 15, 2011 at 14:02, Robert Haas wrote:
>> Fixed in the attached plus added regression tests for both issues (use
>> strict; && Global symbol "$_TD" requires explicit package name, test
>> recursive trigger calls). Although Ill admit, given the point we are
>> in the release I could see a revert also being justified.
>>
>> Greg, big thanks for testing! keep it up! :)
>
> Do we need to apply this patch?
Only if we want use strict and trigger functions to work in 9.1 :). I
realize I did a poor job of explaining the problem and the solution,
that probably made it hard for a -commiter to pick up. Here is a stab
at that.
[ pgcon is spinning up so I won't hold my breath waiting for a response ]
Problem:
CREATE FUNCTION wheredidmytdgo()
RETURNS TRIGGER
LANGUAGE plperlu
AS
$bc$
use strict;
my $new = $_TD->{new};
return;
$bc$;
fails with ERROR: Global symbol "$_TD" requires explicit package name
at line 3.
Analysis:
The above fails due to
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=ef19dc6d39dd2490ff61489da55d95d6941140bf.
It moved declaring of $_TD from plperl_create_sub to
plperl_call_perl_trigger_func(). Before it was always declared even
for non trigger functions. This broke CREATE FUNCTION validation as
$_TD has not been declared. Assuming you could get past the validator
things would still not work, plperl_call_trigger_func() tried to
declare it using get_sv("_TD", GV_ADD) which seems like it should
work, but does not[1].
We (I) failed to notice this during review as it only shows when
running under "use strict", which apparently is uncommon.
Fix:
My proposed fix is instead of declaring $_TD in
plperl_call_perl_trigger_func(), just declare it as a global the same
way we declare %_SHARED. It keeps things simple and we should get to
keep any performance benefits from the patch.
While playing with it I also noticed it was failing to be local()ized
properly meaning nested trigger functions would clobber $_TD, also fix
that.
Also added regression tests for both issues.
--
(1) If it was working and creating a global correctly you should be
able to call a trigger function so that $_TD gets declared and then
create a new trigger function that uses strict and references $_TD
without any problems. But it doesn't work...
# create or replace function td() returns trigger language plperlu as
$bc$ return; $bc$;
CREATE FUNCTION
# create table trig_test(a int);
CREATE TABLE
# create trigger test_trig after insert on trig_test execute procedure td();
CREATE TRIGGER
# insert into trig_test values (1);
INSERT 0 1
# CREATE or replace FUNCTION wheredidmytdgo()
RETURNS TRIGGER
LANGUAGE plperlu
AS
$bc$
use strict;
my $new = $_TD->{new};
return;
$bc$;
ERROR: Global symbol "$_TD" requires explicit package name at line 3.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
