Thread:

From
James Robinson
Date:
 > After reconnecting to database all is ok. Is it supposed behaviour?

Yes. The plpgsql interpreter in the backend directs the backend to  
prepare and cache every sql statement in the function. The planned  
statements reference oids of the tables referenced.

Dropping the connection gets rid of the (now invalid) cached plan.

People have proposed some sort of reparse / replan command, but I  
don't know if they could gain consensus.

It'd be really fancy if plpgsql could sniff into the plan structure  
of each planned query, looking for table oids, and then registering  
itself as being a dependent object of that table, so that upon table  
drop the planned function body could be abandoned, and upon next call  
to the function, hopefully the  table might have been recreated, and  
then the function gets planned successfully again. Or, if the table  
does not exist yet, then it just fails as normal.

----
James Robinson
Socialserve.com



Re:

From
"Larry Rosenman"
Date:
Dragan Zubac wrote:
> Hello
>
> Does anybody knows the Postgres v8.0.3 data directory hierarchy ?
> What is the purpose of the multiply files such as:
>
> 50000
> 50000.1
> 50000.2
> 50000.3
>
> each of the same size ?
>
those are the 1 gigabyte segments of your table/index/relation.

see the storage section of the documentation.

--
Larry Rosenman
Database Support Engineer

PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX  78727-6531

Tel: 512.231.6173
Fax: 512.231.6597
Email: Larry.Rosenman@pervasive.com
Web: www.pervasive.com