Re: Can't find relation oid

Lists: pgsql-generalpgsql-hackers
From: ntinos(at)aueb(dot)gr
To: pgsql-hackers(at)postgresql(dot)org
Subject: "bogus aset link"
Date: 2005-01-02 21:44:23
Message-ID: courier.41D86B37.0000230D@red.servers.aueb.gr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers

Hi everybody!

While writting some code for the backend (some SPI-like functions for a
project) I saw this message:

"WARNING: problem in alloc set ExecutorState: bogus aset link in block
0x8301270, chunk 0x8304458"

I think there is something wrong with some of the memory allocations I do,
but this message is not helping me much in finding the exact error. I read
the source code comments but I couldn't understand what this is.

What is this about?

Thanks in advance,
Ntinos Katsaros


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ntinos(at)aueb(dot)gr
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "bogus aset link"
Date: 2005-01-03 02:29:16
Message-ID: 14376.1104719356@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers

ntinos(at)aueb(dot)gr writes:
> While writting some code for the backend (some SPI-like functions for a
> project) I saw this message:

> "WARNING: problem in alloc set ExecutorState: bogus aset link in block
> 0x8301270, chunk 0x8304458"

> I think there is something wrong with some of the memory allocations I do,
> but this message is not helping me much in finding the exact error.

The most likely bet is that your code wrote past the end of a memory
chunk it had palloc'd, and thereby clobbered the bookkeeping info for
the next physically adjacent chunk.

You could home in on the location of the clobber by sprinkling
"MemoryContextCheck(TopMemoryContext)" calls through your code.

regards, tom lane


From: ntinos(at)aueb(dot)gr
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "bogus aset link"
Date: 2005-01-03 08:43:04
Message-ID: courier.41D90598.0000666C@red.servers.aueb.gr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers

Thanks!
Your advice helped me find what caused the problem immediately. It was a
wrong 'palloc' as you suspected (and as usual for me ;-) ).

Ntinos Katsaros

Tom Lane writes:

> ntinos(at)aueb(dot)gr writes:
>> While writting some code for the backend (some SPI-like functions for a
>> project) I saw this message:
>
>> "WARNING: problem in alloc set ExecutorState: bogus aset link in block
>> 0x8301270, chunk 0x8304458"
>
>> I think there is something wrong with some of the memory allocations I do,
>> but this message is not helping me much in finding the exact error.
>
> The most likely bet is that your code wrote past the end of a memory
> chunk it had palloc'd, and thereby clobbered the bookkeeping info for
> the next physically adjacent chunk.
>
> You could home in on the location of the clobber by sprinkling
> "MemoryContextCheck(TopMemoryContext)" calls through your code.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster


From: ntinos(at)aueb(dot)gr
To: pgsql-general(at)postgresql(dot)org
Subject: Can't find relation oid
Date: 2005-01-03 12:32:44
Message-ID: courier.41D93B6C.000055F6@red.servers.aueb.gr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers

Hi,

I have the following problem:

I use libpq inside SRF functions (like in dblink) and I create some tables
to store results coming from remotly executed queries. (These tables are not
temporary cause I want to use them later as a form of cache.) Then I try to
open these tables to get the results. Actually I modify an already available
Query to refer to these new tables instead of the correspoding local tables.
To do so I need the Oids of theses new tables which I get using the
following query:

select oid from pg_class where relname='foo'

The problem is that when the new tables are created for the first time, the
above query returns no results and the whole thing fails.Everything works
fine if they have already been created by a previous attempt to run my SRF.

I tried to isolate each step (creating tables, retrieving results) in a new
transaction block (like in testlibpq.c example in the documentation) but
with no result. Maybe the whole process described above runs in a sigle
transaction block i.e. that of my SRF(?). I'm a little confused here.

Any ideas?

Regards,
Ntinos Katsaros


From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: ntinos(at)aueb(dot)gr
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Can't find relation oid
Date: 2005-01-03 21:05:47
Message-ID: 20050103210543.GC11443@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers


On Mon, Jan 03, 2005 at 02:32:44PM +0200, ntinos(at)aueb(dot)gr wrote:
> Hi,
>
> I have the following problem:
>
> I use libpq inside SRF functions (like in dblink) and I create some tables
> to store results coming from remotly executed queries. (These tables are
> not temporary cause I want to use them later as a form of cache.) Then I
> try to open these tables to get the results. Actually I modify an already
> available Query to refer to these new tables instead of the correspoding
> local tables. To do so I need the Oids of theses new tables which I get
> using the following query:
>
> select oid from pg_class where relname='foo'

What language? What version of postgresql?

It's not exactly clear from your description but is there a reason you
are using libpq and not the SPI interface? If you create a connection
using libpq to the same database then the queries executed through that
connection will not be able to see the transaction of the SRF you are
writing. The SPI interface is for executing queries within the same
transaction.

http://www.postgresql.org/docs/current/static/spi.html

If this doesn't help maybe you should post an example (with code) of
what your problem actually is.

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.


From: ntinos(at)aueb(dot)gr
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Can't find relation oid
Date: 2005-01-03 21:18:19
Message-ID: courier.41D9B69B.0000426E@red.servers.aueb.gr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general pgsql-hackers

Martijn van Oosterhout writes:

>
> On Mon, Jan 03, 2005 at 02:32:44PM +0200, ntinos(at)aueb(dot)gr wrote:
>> Hi,
>>
>> I have the following problem:
>>
>> I use libpq inside SRF functions (like in dblink) and I create some tables
>> to store results coming from remotly executed queries. (These tables are
>> not temporary cause I want to use them later as a form of cache.) Then I
>> try to open these tables to get the results. Actually I modify an already
>> available Query to refer to these new tables instead of the correspoding
>> local tables. To do so I need the Oids of theses new tables which I get
>> using the following query:
>>
>> select oid from pg_class where relname='foo'
>
> What language? What version of postgresql?

I'm using C on PostgreSQL 7.4.2

> It's not exactly clear from your description but is there a reason you
> are using libpq and not the SPI interface?
>If you create a connection
> using libpq to the same database then the queries executed through that
> connection will not be able to see the transaction of the SRF you are
> writing. The SPI interface is for executing queries within the same
> transaction.

Now I think I understand what happens. You see, I used libpq to create the
tables and SPI to retrieve the Oids ($%&^#$%&!!). When I tried to also
retrieve the Oid using libp it worked. I suppose using SPI both to create
the tables and retrieve the Oids will be the right solution. I'll try it!

> Hope this helps,

It did help to understand what was going on!
Thanks!!
Ntinos Katsaros