Merlin Moncure writes:
> I bumped into the 'virtual tuple' error on 9.0.3 on a completely
> unrelated query:
> create table foo(a int, b int);
> insert into foo select 1, 1 where not exists (select 1 from foo where
> a = 1 for update);
> 9.0.4 got rid of the error, but as there are no triggers o
On Mon, Feb 21, 2011 at 6:31 PM, Tom Lane 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
On Tue, Feb 22, 2011 at 1:31 PM, Tom Lane 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 wa
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
> occ
I wrote:
> [ theory about cause of bug #5798 ]
Attached is a proposed patch against HEAD to fix this problem. It's a
bit hard to *prove* that it fixes the problem, since there's no easy way
to force the collision of palloc addresses. But I think it will.
The patch changes the signature of ExecB
Maxim Boguk writes:
> Yes here is one BEFORE UPDATE trigger on relation
> ...
> However that trigger should not fire at all because storable procedure work
> with set local session_replication_role to 'replica';
Would be nice if you'd provided those sorts of details earlier, instead
of us having
Hi
Yes here is one BEFORE UPDATE trigger on relation
(
Triggers:
_billing_main_denyaccess_71 BEFORE INSERT OR DELETE OR UPDATE ON
ctrl_servers FOR EACH ROW EXECUTE PROCEDURE
_billing_main.denyaccess('_billing_main')
)
However that trigger should not fire at all because storable procedure work
Maxim Boguk writes:
> I tracked virtual tuple from heaptuple.c::slot_getattr down to
> execMain.c::ExecUpdate and I think somewhere in this way virtual tuple
> should be need to be "materialized" into physical tuple.
That happens at the top of ExecUpdate:
/*
* get the heap tuple out of
Today I perfomed some more digging with code and gdb.
I not sure, but may be I have an idea what happens here:
RETURNING ctid fails when code implementing returning happened to get a
"Virtual" tuple as input.
And that ofcourse fail because "virtual tuple does not have any "system
columns" (such a
On Sun, Feb 20, 2011 at 5:08 AM, Tom Lane wrote:
> Maxim Boguk writes:
> > I finally managed create working slave server with non-stripped
> Postgresql
> > 8.4.7 and working gdb.
> > (sorry for such long delay).
> > And i can reproduce situation quite easy now, so i managed get stack
> > backtra
Maxim Boguk writes:
> I finally managed create working slave server with non-stripped Postgresql
> 8.4.7 and working gdb.
> (sorry for such long delay).
> And i can reproduce situation quite easy now, so i managed get stack
> backtrace with that error.
> What i need to do now? I have some expirien
Just an idea from code examination:
I think problem in
" RETURNING ctid"
part of query
and next comment in slot_getattr:
/*
* system attributes are handled by heap_getsysattr
*/
So, may be RETURNING implementation somehow incorrectely handle system
attributes in returing
Hi all and Hi Robert
I finally managed create working slave server with non-stripped Postgresql
8.4.7 and working gdb.
(sorry for such long delay).
And i can reproduce situation quite easy now, so i managed get stack
backtrace with that error.
What i need to do now? I have some expirience with gbd
On Wed, Dec 22, 2010 at 4:53 PM, Maxim Boguk wrote:
> About stack backtrace I not sure how to get it (and even worse the
> database is heavily loaded production DB so I not sure creating core
> dump would be good idea).
> Still I would like to receive any help with creating a stack backtrace.
Wel
It happened again in much simpler case (no slony or deadlock message
involved... no slony at all on the database).
The same error
DBD::Pg::db selectall_arrayref failed: ERROR: cannot extract system
attribute from virtual tuple
CONTEXT: PL/pgSQL function "__clear_table_tail" line 50 at FOR over
E
On Mon, Dec 20, 2010 at 9:48 PM, Maxim Boguk wrote:
> Anyone can enlighten me what happens here?
That does look weird, but without a simple test case I think it's
going to be hard to investigate this. Installing Slony and your code
and building a 130GB is more effort than I'm willing to put in..
The following bug has been logged online:
Bug reference: 5798
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.4
Operating system: FreeBSD 7.2
Description:Some weird error with pl/pgsql procedure
Details:
While I testing my table c
17 matches
Mail list logo
