From: | Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5798: Some weird error with pl/pgsql procedure |
Date: | 2011-02-22 06:43:10 |
Message-ID: | AANLkTimgJ67tZcG9UBkgtFxSGtYB1TNQdn3KG74O9FzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Feb 22, 2011 at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > Ugh. That quick little "ExecRemoveJunk" is a lot more dangerous than it
> > looks. I had actually looked at this before, but concluded it was OK
> > because I couldn't reproduce the problem with a trigger in place.
> > I guess I wasn't unlucky enough to have the chance pointer equality
> > occur.
>
> On closer inspection, the palloc collision is actually extremely likely,
> because what will happen is we'll pfree the old tuple and immediately
> palloc the new one, and if the new one is of sufficiently similar size
> that it needs the same size of alloc chunk, it's *guaranteed* to get
> that same chunk back, because of the LIFO free-chunk chains in aset.c.
>
> The reason that the problem is hard to reproduce is that most triggers
> (certainly those written in plpgsql) will give back newly allocated
> tuples even when you return the unmodified NEW tuple. The only way to
> expose the problem is for ExecBRUpdateTrigger's trigger-calling loop to
> not replace the "newtuple", and the easiest way for that to happen is if
> all the triggers are disabled. So that's why you're seeing it when
> fooling with the replication-role setting. I was able to reproduce the
> failure by creating a trigger with a false WHEN condition, and of course
> there are other ways to prevent a trigger from being called too.
>
> regards, tom lane
>
Thank you very much for fixing that issue.
I apologize for not providing critical details at start of the discussion
(until yesterday they seems unimportant for me), I will try provide all
possible details in future if I find anything else like that.
Now for me start digging next strange problem described here:
http://archives.postgresql.org/pgsql-admin/2011-01/msg00055.php
--
Maxim Boguk
Senior Postgresql DBA.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2011-02-22 06:43:58 | 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid |
Previous Message | Mark Kirkwood | 2011-02-22 03:43:37 | Hung Vacuum in 8.3 |