Re: [HACKERS] PlPython
Tom Lane kirjutas E, 30.06.2003 kell 06:39: Hannu Krosing [EMAIL PROTECTED] writes: Tom Lane kirjutas E, 30.06.2003 kell 01:21: Who's still using 1.5, I guess is the question? And are they likely to be updating their PG installation when they're not updating Python? I guess that anyone who needs safe Restricted Execution will be using 1.5 at least for that purpose until RExec is fixed in 2.x. I don't find that real compelling ... The bottom line is that this has to get done. I have the time to convert plpython to untrusted status tomorrow. I do not have the time, the infrastructure, nor the interest to build a conditional setup. Unless someone else wants to volunteer to make it happen in a timely fashion, untrusted is what it will be. Fine with me. Just don't put in any hacks to pretend it is trusted. --- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Is Patch Ok for deferred trigger disk queue?
Hi, I noticed the patch: http://archives.postgresql.org/pgsql-patches/2003-06/msg00366.php isn't in the patch queue. Is the patch OK? If not please say what is wrong with it. Thank you, - Stuart ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] When will table partitioning be available..
On Fri, 27 Jun 2003, Bruno Wolff III wrote: On Thu, Jun 26, 2003 at 09:27:23 -0700, Shirish Reddy [EMAIL PROTECTED] wrote: Hi, One of the issues that is preventing us from migrating from an Oracle DB to Postgres is that Table Partitioning is not available in Postgres yet. Partitioning is still listed as a TO DO. Any ideas when this will be available in Postgres? Approximate time frame will be good enough for now. I haven't heard of anyone actually working on it right now, so it would be hard to give any kind of time frame other than it won't be in 7.4 unless someone jumps out of the woodwork in the next couple of days. Are partial indexes a possible solution for your problem? This last sentence makes a very valid point. Just because you solve a problem in Oracle-land one way does not mean the most effective means to solve it in Postgresql-land is by the same methodology. Many solutions in one of these domains will not, and usually should not, have a direct 1 to 1 mapping. It's often better to post what problems you're having in Postgresql and ask the list for advice. The solution may be much simpler than you'd imagine, but without know what the problem is, it's hard to suggest a solution to Shirish Reddy. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Question about array read using protocol 3.0 implementation
Hello: Thanks another wuestion in this case about oidvector i'm reviewing oidvectorsend() at backend/utils/adt/oid.c and seems that for this datatype the server sends only array data, i'm rigth ??, i think yes but i want to be sure ;) ( and i think the same can be applied to int2vector ?? ) -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Question about array read using protocol 3.0 implementation
Carlos Guzman Alvarez [EMAIL PROTECTED] writes: Thanks another wuestion in this case about oidvector i'm reviewing oidvectorsend() at backend/utils/adt/oid.c and seems that for this datatype the server sends only array data, i'm rigth ??, i think yes but i want to be sure ;) ( and i think the same can be applied to int2vector ?? ) Right, the fixed-length array types are a whole 'nother critter. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Question about array read using protocol 3.0 implementation
Hello: Right, the fixed-length array types are a whole 'nother critter. Thanks -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch for adding DATACUBE operator
Moving to pgsql-hackers@
On Mon, 2003-06-30 at 12:03, sumit wrote:
Thanks for letting know. Could you also let me know the exact
syntax, I mean, we are not sure whether GROUP BY CUBE(...) is followed by
a HAVING clause. Kindly inform us soon so that we can make the changes and
send you the updated patch and files.
Sources of the SQL Spec
http://developer.postgresql.org/readtext.php?src/FAQ/FAQ_DEV.html+Developers-FAQ#1.12
The relevent syntax appears to be in section 7.9, and is a part of the
GROUP BY clause, so is potentially followed by a HAVING clause.
7.9 group by clause
Function
Specify a grouped table derived by the application of the
group by
clause to the result of the previously specified clause.
Format
group by clause ::=
GROUP BY grouping specification
grouping specification ::=
grouping column reference
| rollup list
| cube list
| grouping sets list
| grand total
| concatenated grouping
rollup list ::=
ROLLUP left paren grouping column reference list
right paren
cube list ::=
CUBE left paren grouping column reference list right
paren
grouping sets list ::=
GROUPING SETS left paren grouping set list right
paren
grouping set list ::=
grouping set [ { comma grouping set }... ]
concatenated grouping ::=
grouping set comma grouping set list
grouping set ::=
ordinary grouping set
| rollup list
| cube list
| grand total
ordinary grouping set ::=
grouping column reference
| left paren grouping column reference list right
paren
grand total ::= left paren right paren
grouping column reference list ::=
grouping column reference
[ { comma grouping column reference }... ]
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
Re: [HACKERS] Is Patch Ok for deferred trigger disk queue?
On Mon, 30 Jun 2003, deststar wrote: Hi, I noticed the patch: http://archives.postgresql.org/pgsql-patches/2003-06/msg00366.php isn't in the patch queue. Is the patch OK? I think it was just that Bruce hasn't gotten to it. If not please say what is wrong with it. I just checked out a new cvs copy and applied the patch, and did something like the following: create table a1(a int unique, b int, c int, unique(b,c)); insert into a1 values (1,1,1); create table a2(a int references a1(a), b int, c int, foreign key(b,c) references a1(b,c) initially deferred ); begin; insert into a2 values (1,1,1); insert into a2 select * from a2; [repeated a bunch of times until it'd be inserting 64k rows] and got an error on writing the disk event handle and a signal 11: ERROR: Can not open first disk event file handle for /usr/local/pgsql/data/base/17139/pgsql_tmp/pgsql_tmpdeftrig_555-1 The connection to the server was lost. Attempting reset: LOG: server process (pid 32125) was terminated by signal 11 The backtrace from the core looked like: #0 0x42062867 in fclose@@GLIBC_2.1 () from /lib/i686/libc.so.6 #1 0x080d61a8 in deferredTriggerClean () at trigger.c:1864 #2 0x080d728e in DeferredTriggerAbortXact () at trigger.c:2642 #3 0x0808c214 in AbortTransaction () at xact.c:1042 #4 0x08141332 in PostgresMain (argc=4, argv=0x826a2f0, username=0x826a2c0 sszabo) at postgres.c:2610 #5 0x0812320e in BackendFork (port=0x8277080) at postmaster.c:2471 #6 0x08122d1e in BackendStartup (port=0x8277080) at postmaster.c:2118 #7 0x081218ab in ServerLoop () at postmaster.c:1090 #8 0x08121358 in PostmasterMain (argc=3, argv=0x82693e0) at postmaster.c:872 #9 0x080f9e30 in main (argc=3, argv=0xba94) at main.c:211 #10 0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6 looks like it was passing a NULL file handle if it couldn't be opened. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PlPython
Hannu Krosing writes: Tom Lane kirjutas E, 23.06.2003 kell 01:29: Kevin Jacobs [EMAIL PROTECTED] writes: Attached is a patch that removes all of the RExec code from plpython from the current PostgreSQL CVS. In addition, plpython needs to be changed to an untrusted language in createlang. I am inclined to rename plpython to plpythonu, by analogy to pltclu. ... Comments? could we not just make sure that plpython uses python ver 2.x and use plpythonu for python versions = 2.x until a secure regex solution comes from Guido and folks ? I guess most plpython users would be much happier with plpython with some minor limitations due to older version than with being forced to use an untrusted pl altogether. Actually, there are also people (me, for example :-), who would love to see an untrusted PlPython to use the full Python power as Pl. So I'd be very happy with a solution, where I could choose between plpython and plpythonu. But I don't know if that means having twice the effort compared to only having plpython _or_ plpythonu. Regards, Tilo ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Is Patch Ok for deferred trigger disk queue?
On Mon, 30 Jun 2003, Stephan Szabo wrote: On Mon, 30 Jun 2003, deststar wrote: Hi, I noticed the patch: http://archives.postgresql.org/pgsql-patches/2003-06/msg00366.php isn't in the patch queue. Is the patch OK? I think it was just that Bruce hasn't gotten to it. If not please say what is wrong with it. I just checked out a new cvs copy and applied the patch, and did something like the following: create table a1(a int unique, b int, c int, unique(b,c)); insert into a1 values (1,1,1); create table a2(a int references a1(a), b int, c int, foreign key(b,c) references a1(b,c) initially deferred ); begin; insert into a2 values (1,1,1); insert into a2 select * from a2; [repeated a bunch of times until it'd be inserting 64k rows] and got an error on writing the disk event handle and a signal 11: ERROR: Can not open first disk event file handle for /usr/local/pgsql/data/base/17139/pgsql_tmp/pgsql_tmpdeftrig_555-1 The connection to the server was lost. Attempting reset: LOG: server process (pid 32125) was terminated by signal 11 The backtrace from the core looked like: #0 0x42062867 in fclose@@GLIBC_2.1 () from /lib/i686/libc.so.6 #1 0x080d61a8 in deferredTriggerClean () at trigger.c:1864 #2 0x080d728e in DeferredTriggerAbortXact () at trigger.c:2642 #3 0x0808c214 in AbortTransaction () at xact.c:1042 #4 0x08141332 in PostgresMain (argc=4, argv=0x826a2f0, username=0x826a2c0 sszabo) at postgres.c:2610 #5 0x0812320e in BackendFork (port=0x8277080) at postmaster.c:2471 #6 0x08122d1e in BackendStartup (port=0x8277080) at postmaster.c:2118 #7 0x081218ab in ServerLoop () at postmaster.c:1090 #8 0x08121358 in PostmasterMain (argc=3, argv=0x82693e0) at postmaster.c:872 #9 0x080f9e30 in main (argc=3, argv=0xba94) at main.c:211 #10 0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6 looks like it was passing a NULL file handle if it couldn't be opened. The open error seems to have been errno=13 (EACCES). I was able to get past that by changing pgsql_tmp's permissions to 700 rather than 600. The 64k insert one worked, but the next insert ... select failed with: ERROR: Attempt to read from disk deferred trigger queue before initialisation. --- As a side question, it looks to me that the code stores the first trigger records in memory and then after some point starts storing all new records on disk. Is this correct? I'd wonder if that's really what you want in general, since I'd think that the earliest ones are the ones you're least likely to need until end of transaction (or set constraints in the fk case) whereas the most recent ones are possibly going to be immediate triggers which you're going to need as soon as the statement is done. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Is Patch Ok for deferred trigger disk queue?
Stephan Szabo [EMAIL PROTECTED] writes: As a side question, it looks to me that the code stores the first trigger records in memory and then after some point starts storing all new records on disk. Is this correct? I'd wonder if that's really what you want in general, since I'd think that the earliest ones are the ones you're least likely to need until end of transaction (or set constraints in the fk case) whereas the most recent ones are possibly going to be immediate triggers which you're going to need as soon as the statement is done. Good point. It would be better to push out stuff from the head of the queue, hoping that stuff near the end might never need to be written at all. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Share state ( allocated memory ) across two C functions...
Hi, I have interesting question that stops me now. Suppose I have 2 functions 1. preparestate 2. doajob first allocates some state using MemoryContextAlloc(TopTransactionContext) or something, another function using that memory. question is how I lookup that memory in second function doajob? Of cause I can return a handle from first function, pointer and accept that pointer in second function, but in this case I have to check that pointer on validity and so on... Is there any good practice ( some way to do so ) for that? Thank you. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Share state ( allocated memory ) across two C functions...
Maksim Likharev wrote: Of cause I can return a handle from first function, pointer and accept that pointer in second function, but in this case I have to check that pointer on validity and so on... Is there any good practice ( some way to do so ) for that? Best way I've come up with to do this is by using a hash table based on a name lookup. See the way it's done in dblink now (as of a week or so ago) for named persistent connections. HTH, Joe ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Dllist public/private part
I'm improving the Dllist in these direction:
1) Avoid if statements in insertion/remove phase, for instance now the
AddHeader appear like this:
void
DLAddHead(Dllist *l, Dlelem *e)
{
Dlelem *where = l-dll_master_node-dle_next;
e-dle_next = where;
e-dle_prev = where-dle_prev;
where-dle_prev-dle_next = e;
where-dle_prev = e;
e-dle_list = l;
}
2) Not using a malloc but using a special malloc that not perform
a malloc for each request but do a BIG malloc at first request...
In the file dllist.h is not clear what is the public part and the private
part
of the implementation in particulary I see that somewhere in the code
there is the assumption that an Empty dllist is zeroed instead of
use DLInitList, for example this is the way to initialize a struct that
contain a Dllist itself:
cp = (CatCache *) palloc0(sizeof(CatCache) + NCCBUCKETS * sizeof(Dllist));
this break my optimization because in my implementation a
dllist is
typedef struct Dllist
{
Dlelem *dll_master_node;
} Dllist;
and not anymore:
typedef struct Dllist
{
Dlelem *dll_head;
Dlelem *dll_tail;
} Dllist;
and is empty if list-dll_master_node-dle_next and
list-master_node-dle_prev are pointing to
list-master_node ( previously allocated in DLInitList).
What should I do ? Forget the point 1) ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dllist public/private part
Mendola Gaetano [EMAIL PROTECTED] writes: I'm improving the Dllist in these direction: AFAIR, catcache.c is the *only* remaining backend customer for Dllist, and so any improvement for Dllist that breaks catcache is hardly an improvement, no? 1) Avoid if statements in insertion/remove phase, for instance now the AddHeader appear like this: shrug ... unless you can convert DLAddHead into a inline macro, I doubt there'll be any visible performance difference. 2) Not using a malloc but using a special malloc that not perform a malloc for each request but do a BIG malloc at first request... It would make more sense to migrate Dllist to use palloc. That's not compatible with its use in frontend libpq; I've been speculating about splitting off libpq to have a separate implementation instead of trying to share code. I believe libpq only uses Dllist for the pending-notify-events list, for which the code is poorly optimized anyway (we don't need a doubly-linked list for that). regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] INDEX_MAX_KEYS to 64?
I just noticed that the OSDL benchmarks for PostgreSQL appear to require PostgreSQL be compiled with INDEX_MAX_KEYS as 64 rather than the default of 32. Any chance the default could be bumped for the 7.4 release? Does it cause a significant performance issue? -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] INDEX_MAX_KEYS to 64?
Rod Taylor [EMAIL PROTECTED] writes: I just noticed that the OSDL benchmarks for PostgreSQL appear to require PostgreSQL be compiled with INDEX_MAX_KEYS as 64 rather than the default of 32. Which one? I've been testing dbt3 here and not seen that. Any chance the default could be bumped for the 7.4 release? Not without evidence that it doesn't cause performance penalties. ISTM we have been through this discussion recently, and concluded that 32 was the place to set it. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] INDEX_MAX_KEYS to 64?
On Tue, 2003-07-01 at 01:25, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I just noticed that the OSDL benchmarks for PostgreSQL appear to require PostgreSQL be compiled with INDEX_MAX_KEYS as 64 rather than the default of 32. Which one? I've been testing dbt3 here and not seen that. It's in the directions for dbt2, though I haven't found the specific function(s) that requires it at this point -- can't quite run it on my system yet for various reasons. Any chance the default could be bumped for the 7.4 release? Not without evidence that it doesn't cause performance penalties. ISTM we have been through this discussion recently, and concluded that 32 was the place to set it. Yes, I was digging through that discussion. The test used shows a 4% difference between 32 and 64. do 100 times select 2+2+2+2+2+2+ ... iterated 9901 times #define INDEX_MAX_KEYS 16, 32, 64, 128 #define FUNC_MAX_ARGS INDEX_MAX_KEYS make all make install initdb The results were as follows: INDEX_MAX_KEYS1632 64 128 -+---+--+ Time in seconds 4849 51 55 -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] INDEX_MAX_KEYS to 64?
Rod Taylor wrote: On Tue, 2003-07-01 at 01:25, Tom Lane wrote: Not without evidence that it doesn't cause performance penalties. ISTM we have been through this discussion recently, and concluded that 32 was the place to set it. Yes, I was digging through that discussion. The test used shows a 4% difference between 32 and 64. do 100 times select 2+2+2+2+2+2+ ... iterated 9901 times There was also this, on disk usage - about 25% penalty going from 32 to 64 (at least for small databases). Joe Conway wrote: Tom Lane wrote: Did you happen to make any notes about the disk space occupied by the database? One thing I was worried about was the bloat that'd occur in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from costing disk space, this would indirectly slow things down due to more I/O to read these tables --- an effect that probably your test couldn't measure, since it wasn't touching very many entries in any of those tables. #define INDEX_MAX_KEYS16 #define FUNC_MAX_ARGSINDEX_MAX_KEYS du -h --max-depth=1 /opt/data/pgsql/data/base/ 2.7M/opt/data/pgsql/data/base/1 2.7M/opt/data/pgsql/data/base/16862 2.7M/opt/data/pgsql/data/base/16863 2.7M/opt/data/pgsql/data/base/16864 3.2M/opt/data/pgsql/data/base/16865 2.7M/opt/data/pgsql/data/base/16866 17M /opt/data/pgsql/data/base #define INDEX_MAX_KEYS32 #define FUNC_MAX_ARGSINDEX_MAX_KEYS du -h --max-depth=1 /opt/data/pgsql/data/base/ 3.1M/opt/data/pgsql/data/base/1 3.1M/opt/data/pgsql/data/base/16862 3.1M/opt/data/pgsql/data/base/16863 3.1M/opt/data/pgsql/data/base/16864 3.6M/opt/data/pgsql/data/base/16865 3.1M/opt/data/pgsql/data/base/16866 19M /opt/data/pgsql/data/base #define INDEX_MAX_KEYS64 #define FUNC_MAX_ARGSINDEX_MAX_KEYS du -h --max-depth=1 /opt/data/pgsql/data/base/ 3.9M/opt/data/pgsql/data/base/1 3.9M/opt/data/pgsql/data/base/16862 3.9M/opt/data/pgsql/data/base/16863 3.9M/opt/data/pgsql/data/base/16864 4.4M/opt/data/pgsql/data/base/16865 3.9M/opt/data/pgsql/data/base/16866 24M /opt/data/pgsql/data/base #define INDEX_MAX_KEYS128 #define FUNC_MAX_ARGSINDEX_MAX_KEYS du -h --max-depth=1 /opt/data/pgsql/data/base/ 5.7M/opt/data/pgsql/data/base/1 5.7M/opt/data/pgsql/data/base/16862 5.7M/opt/data/pgsql/data/base/16863 5.7M/opt/data/pgsql/data/base/16864 6.3M/opt/data/pgsql/data/base/16865 5.7M/opt/data/pgsql/data/base/16866 35M /opt/data/pgsql/data/base Here's the thread: http://archives.postgresql.org/pgsql-hackers/2002-08/msg00258.php Joe Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Missing array support
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
So array[] should produce '{}' of (an array) type determined by the
context? OK -- seems easy enough.
Is it? I think we'd decided that this could only reasonably be handled
by creating a datatype representing array-of-UNKNOWN. I'm afraid to do
that because I think it might allow the parser's type resolution
algorithms to follow paths we will not like. Perhaps it can be made to
work, but I think it will require some careful study.
I took a closer look -- yeah, without array-of-UNKNOWN I don't think we
can make this work.
I got something working by forcing the element type to UNKNOWN when the
elements list is empty in transformExpr(), but then select_common_type()
turns around and turns UNKNOWN into TEXT, so you wind up with an empty
text[].
I won't bother sending that patch in because I *know* it will get
rejected ;-)
I guess we should put array-of-UNKNOWN on the list of things to look at
for 7.5.
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Missing array support
Peter Eisentraut wrote: * Using an array as a table source using UNNEST, something like: select * from unnest(test.b); (Check the exact spec to be sure; clause 7.6.) select * from unnest(array['a','b']); ?column? -- a b select * from unnest(array['a','b']) WITH ORDINALITY; ?column? | ?column? --+-- 1| a 2| b select * from unnest(array['a','b']) as t(f1, f2) WITH ORDINALITY; f1 | f2 + 1 | a 2 | b The WITH ORDINALITY goes before the AS clause. The reason it is defined in terms of the LATERAL clause is that that allows you to refer to column aliases defined in FROM items to its left. This is the way variable arguments of function calls as table sources can be resolved. (At least this is my interpretation. I found some examples on the web a few months ago about this.) If I can get this done *without* supporting LATERAL by the end of the evening (i.e. just implement the examples), would it possibly be accepted? Or should UNNEST wait until we get LATERAL? Joe ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] dblink for Oracle - question ...
A few days ago I have posted a pre-beta version of dblink_ora which is supposed to solve some problems we had here at Cybertec (getting data from an Oracle DB and merge it with PostgreSQL). I have implemented a simple piece of code (more proof of concept than production). Since I have not got too much response (just one posting off list) I expect that there are not too many people who are in need of this feature. Am I right or is there somebody out there who wants to see it in contrib? If there is serious interest in this feature we'd make it work with PostgreSQL's build system and we'd add some documentation as well as some more code. If not we will keep using it for internal purposes. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Core dump on HP
Hi, folks; We're running Postgres 7.3.2 and we have a core dump on HP-11. This does not seem reproducible on Solaris or Linux. Working with debugger we get this stack: #0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2 (gdb) where #0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2 #1 0xc01821c0 in __thread_callback_np+0x894 () from /usr/lib/libc.2 #2 0xc0187fa4 in realloc+0x1c4 () from /usr/lib/libc.2 #3 0xc018f420 in putenv+0xe8 () from /usr/lib/libc.2 It looks that problem occurs when we releasing TCL interpreter, also the problem can be avoided if in pgtcl.c this code is commented out: if (tclversion = 8.1) putenv(PGCLIENTENCODING=UNICODE); I found another report on putenv problem: http://archives.postgresql.org/pgsql-bugs/1999-11/msg7.php Are we're dealing with essentially same root cause? Is there a recommended solution? Thank you, Michael. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] dblink_ora - a first shot on Oracle ...
Joe Conway wrote: Bruce Momjian wrote: OK, can you take ownership of it? You mean a TODO entry? Sure, as long as Hans is OK with it. Joe I am ok with it. The only problem I have at the moment is that I don't know how to build properly and to check for the libs needed by Oracle. The entire code is built on a library by a German developer because the OCI interface itself is more than just insane (you will need 1 lines of code to establish a connection to the server). As soon as I have all I need it should not be a huge task to finish the code. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] 2PC: discussion in comp.arch
Curious bit of synchronicity, related discussion going on in comp.arch on same topic, lurkers like me might appreciate the explanation given in http://groups.google.com/groups?selm=svudnRBY5twrXG6jXTWJkQ%40metrocast.net ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] some questions about buffer management
hi all, i'm progressing with my implementation of ARC to try to replace LRU. I have the following questions: - When do we know we have a page fault ? i've found AddBufferToFreelist() to be one. but are there other places as well ? - What variable holds the number of our cache capacity ? i'm guessing on NBuffers for now. -How do we know we had a cache hit ? i'm guessing ReadBuffer for know. Are there other calls as well ? -How do i wait for a buffer tot get undirty ? ok hope to hear from someone soon ;) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 datatype patch
ftp://ftp.kame.net/pub/kame/misc/ has IPv6 datatype patch (makes inet type handle both IPv4 and IPv6) for 7.3.2. let me know how i can proceed/help. There already is a patch in cvs head that does the same except it doesn't handle the scope. It would probably be useful to look at the other differences. that's good to hear! tnx. itojun ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] lru cache replacement
I was researching on cache replacement strategy as well. 2Q has one disadvantage see this exellent paper: http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper ARC: A Self-Tuning, Low Overhead Replacement Cache for theory and One Up on LRU for implementation details. ARC requires no tuning and can switch fast between chaging patterns. Best of all is it is resistant to a sequential scan pattern. and i think it's even easier to implement then 2q :) does pgbench test with relatively large sequential scans? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] PlPython
For 7.4 (which I expect is the patch's target) it might be best to make both names point to the same thing with a clear release note that says that they are the same thing and that plpython[u] is now untrusted. That will give people a bit a time to reload their existing functions. elein On Sunday 22 June 2003 15:29, Tom Lane wrote: Kevin Jacobs [EMAIL PROTECTED] writes: Attached is a patch that removes all of the RExec code from plpython from the current PostgreSQL CVS. In addition, plpython needs to be changed to an untrusted language in createlang. I am inclined to rename plpython to plpythonu, by analogy to pltclu. The advantage of doing so is that (a) the name change makes it somewhat more obvious that there's a fundamental behavioral change, and (b) assuming that the Python folk someday figure out a secure version of RExec, we'd want to reinstitute the trusted version of plpython, but perhaps not take away the untrusted one. On the other hand, this would create headaches for people who are trying to load dump files that declare plpython or contain plpython-language functions. I can't think of any non-kluge solution to this (kluge solutions would include putting special-case code into CREATE FUNCTION to change 'plpython' to 'plpythonu' ...) Comments? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- = [EMAIL PROTECTED] Database Consulting www.varlena.com PostgreSQL General Bitshttp:/www.varlena.com/GeneralBits/ Free your mind the rest will follow -- en vogue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PlPython
I thought there would be a relatively clear way to alias them both to the same language library for a release or two. But I see your point on transitioning. Clear notice is really important. plpython should be phased out if it is not replaced within a release or two. If only the change could be transparent to those people who are not using any untrusted features. Maybe it is better to break everyone's plpython functions in 7.4. That would certainly make sure everyone heard of the change from trusted to untrusted. But explanations of what exactly that means should also be included in the release notes. elein PS: I've built and tested the plpython patch against 7.3.2 and am happy it does not affect the features I count on. I'd do it against the development release but I can't get it to build (for other reasons). On Monday 23 June 2003 13:53, Tom Lane wrote: elein [EMAIL PROTECTED] writes: For 7.4 (which I expect is the patch's target) it might be best to make both names point to the same thing with a clear release note that says that they are the same thing and that plpython[u] is now untrusted. I don't know any way to actually do that, though. If we put two entries in pg_language then functions created in plpython will stay associated with that entry. That'd probably be the worst of all possible worlds, since a person looking at pg_language would quite reasonably assume that plpython was still trusted and the untrusted plpythonu was just an addition. (Especially if he happened to know that such an addition was planned long ago.) You could shoot yourself in the foot pretty badly with such a misunderstanding :-( The behavior that I think would be most useful would be to automatically transpose CREATE FUNCTION ... LANGUAGE plpython into CREATE FUNCTION ... LANGUAGE plpythonu. Which we could do with an ugly hack in CREATE FUNCTION (ugly, but no worse than things we've done to index opclass names, for example). But it could be too confusing. regards, tom lane -- = [EMAIL PROTECTED] Database Consulting www.varlena.com PostgreSQL General Bitshttp:/www.varlena.com/GeneralBits/ Free your mind the rest will follow -- en vogue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters - AllocSetAlloc(128)?
Excellent -- thanks so much for your help. I just tried the function with the right arguments, and it worked just fine. Yet more proof of named parameters being a good thing... Reuven ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PlPython
On 30 Jun 2003, Hannu Krosing wrote: Tom Lane kirjutas E, 30.06.2003 kell 01:21: Hannu Krosing [EMAIL PROTECTED] writes: The version with patch which removes RExec (as Python 2.x is not supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is no reason to remove safe execution when using python 1.5.x. Who's still using 1.5, I guess is the question? And are they likely to be updating their PG installation when they're not updating Python? Python is designed such that one can install and use different versions in parallel - for example the deafult directopries for libraries are /usr/lib/python1.5/ and /usr/lib/python2.2/ if you have installed python 1.5.x and 2.2.x, also executables are python2, python2.2 and python1.5, with plain python being a link to one of these. I guess that anyone who needs safe Restricted Execution will be using 1.5 at least for that purpose until RExec is fixed in 2.x. Unless a someone steps forward to actively maintain such a configuration, then trusted PlPython is not going to exist anymore. The cost of getting even the most minute detail wrong is just too high tobe left to chance. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: [EMAIL PROTECTED] Fax: (216) 986-0714 WWW:http://www.theopalgroup.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
