Mike Mascari <[EMAIL PROTECTED]> writes:
> Would it make sense to also have a nice little global function and/or
> macro available for the author of C-language recursive functions to
> perform a depth test before recursing?
Yeah, I envision presenting this as a nice little macro along the lines
Bruce Momjian wrote:
Sounds like a great approach to me. If it doesn't work, we will find
out during beta testing.
Would it make sense to also have a nice little global function and/or
macro available for the author of C-language recursive functions to
perform a depth test before recursing?
Sounds like a great approach to me. If it doesn't work, we will find
out during beta testing.
---
Tom Lane wrote:
> We've had a couple of complaints in the past about recursive functions
> crashing the server by overflowing
We have been discussing this patch on the patches list:
ftp://candle.pha.pa.us/pub/postgresql/mypatches/fmtId
In short, the patch removes quoting from \d displays when quotes is not
required (e.g. identifier is all lower case and has no embedded spaces).
The patch changes this current ou
On Sunday 28 December 2003 09:03 am, Gaetano Mendola wrote:
> Sander Steffann wrote:
> > This is because when I built the RPMs for RedHat there were little
> > differences between the different RedHat releases that caused the builds
> > to fail. I had to make minor adjustments for each platform, wh
On Saturday 27 December 2003 08:02 pm, Gaetano Mendola wrote:
> I'm founding little messy the RPM condition for redhat:
Yes, it is a litle messy. My apologies. There will hopefully not be that
with the 7.4.1 set that I hope to release when I get back from vacation
(Saturday or Monday, dependin
We've had a couple of complaints in the past about recursive functions
crashing the server by overflowing the C execution stack. There is a
GUC variable max_expr_depth that is intended to prevent this sort of
problem for the particular case of overly complex arithmetic
expressions, but it's diffic
as new know plpgsql has special cache which remember too long (event
non-existing tables (i mean old oid)) so i suggest to create same function
only in plpgsql which would clear this cache, or sth like this ?
for ie, where i drop table i would do plpgsql_clear_cache ();
and when i will create on
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Are there strategies that do not rely on a global lock? The Linux kernel
uses a lazy LRU with referenced bits: on access, the referenced bit is
set. The freespace logic takes pages from the end of a linked list, and
checks that bit: if
I've hacked my dbt2-pgsql test on STP so that patches can be applied to
PostgreSQL 7.4 in a limited fashion by taking advantage of PLM. I have some
instructions on how this can be done at the bottom of this web page:
http://developer.osdl.org/markw/stp_dbt2_howto.html
Let me know if you h
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> 1. What objects can possibly appear in the pg_temp* schemas? Is it just
> tables, views and sequences?
Indexes ... row types for tables ...
> 2. As above, but the pg_toast schema. Tables only here?
Ditto.
> 3. Am I guaranteed that a temp
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Are there strategies that do not rely on a global lock? The Linux kernel
> uses a lazy LRU with referenced bits: on access, the referenced bit is
> set. The freespace logic takes pages from the end of a linked list, and
> checks that bit: if it's set,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> If we can't eliminate the global lock, and we reduce its duration?
It'd be a big win even if we could just arrange that ReadBuffer and
ReleaseBuffer don't *both* grab the same global lock.
Can we logically separate the buffer lookup hashtable from the f
Jan Wieck wrote:
Moving the Cache Directory Block (cdb) on a hit to the MRU position of
the appropriate queue "is the bookkeeping" of this strategy. The whole
algorithm is based on it, and I don't see yet how to avoid that without
opening a huge can of worms that look like deadlocks. But I'll thin
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I wrote:
>> There are a couple of other places where [select()] is used for small
>> sleeps (storage/lmgr/s_lock.c and access/transam/xact.c) -
> What is the preferred way to handle these 2 cases? We could handle them
> with #ifdef'd code inline, or
Jan Wieck wrote:
> Manfred Spraul wrote:
> > Bruce Momjian wrote:
> >
> >>>Anyone see an attack path here?
> >>>
> >>>
> >>
> >>Should we have one lock per hash bucket rather than one for the entire
> >>hash?
> >>
> >>
> > That's the simple part. The problem is the aging strategy: we need a
Hi, quick questions related to phpPgAdmin development.
1. What objects can possibly appear in the pg_temp* schemas? Is it just
tables, views and sequences?
2. As above, but the pg_toast schema. Tables only here?
3. Am I guaranteed that a temp schema is 'pg_temp_*' and a toast one is
'pg_toas
I cannot get rid of a sequence:
gis=# drop sequence geopol.geology_gid_seq;
ERROR: cache lookup of relation 8511697 failed
Yes, geology_gid_seq have been created as a consequence of a
geology.gid attribute of type serial.
And.. yes, I've removed the relation with a delete on pg_cl
strk <[EMAIL PROTECTED]> writes:
> I cannot get rid of a sequence:
> gis=# drop sequence geopol.geology_gid_seq;
> ERROR: cache lookup of relation 8511697 failed
> Yes, geology_gid_seq have been created as a consequence of a
> geology.gid attribute of type serial.
> And.. yes, I've rem
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
>>>Anyone see an attack path here?
>>>
>>>
>>
>>Should we have one lock per hash bucket rather than one for the entire
>>hash?
>>
>>
> That's the simple part. The problem is the aging strategy: we need a
> strategy that doesn't rely on a global
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I can use NSN (node sequence number) and I find recommendation to use
> LSN (WAL log sequence number) as NSN. NSN must be stored in page and I
> found that page (PageHeaderData struct) already has XLogRecPtr for
> storing LSN. My question is: who is manag
I wrote:
There are a couple of other places where [select()] is used for small
sleeps (storage/lmgr/s_lock.c and access/transam/xact.c) - those
should possibly be abstracted out (Windows doesn't behave well there
anyway, I believe - with 0 FDs I read somewhere it returns immediately
regardles
Bruce Momjian wrote:
>>Anyone see an attack path here?
>>
>>
>
>Should we have one lock per hash bucket rather than one for the entire
>hash?
>
>
That's the simple part. The problem is the aging strategy: we need a
strategy that doesn't rely on a global list that's updated after every
lookup
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> >> That's irrelevant to the problem, though. Unless the ARC code uses data
> >> structures that are more amenable to localized locking than the old
> >> global buffer freelist. (Jan?)
>
> > the strategy itself does no locking at all. Like
I cannot get rid of a sequence:
gis=# drop sequence geopol.geology_gid_seq;
ERROR: cache lookup of relation 8511697 failed
Yes, geology_gid_seq have been created as a consequence of a
geology.gid attribute of type serial.
And.. yes, I've removed the relation with a delete on pg_
Hi!
I'll have time and wish to work on concurrence GiST during january.
Now I am reading some paper about this and looking into code of postgres for
lock management. As I see, postgres doesn't support intentional lock. Is it
right? or I missed something...
I can use NSN (node sequence number) a
Could certainly do that - a scalar function that returns reltuples from
pg_class. I was hoping to do 2 additional things:
i) provide better accuracy than the last ANALYZE
ii) make it behave like an aggregate
So I wanted to be able to use estimated_count as you would use count, i.e:
SELECT estima
27 matches
Mail list logo
