Re: [HACKERS] Spinlock support for linux-hppa?
On Thu, 2004-01-01 at 22:20, Tom Lane wrote: My object is to get 7.4.1 working on all the Debian architectures. I'd have been more willing to buy into that goal if you'd been working on it during the 7.4 beta test cycle. I gather from what you are saying that you couldn't, because Debian provides essentially no infrastructure for testing package portability in advance of official releases. That seems like a rather serious misjudgement on their part ... maybe you could lobby to get it corrected? It isn't as bad as that normally. If I put a package in unstable, it will (in the absence of a later upgrade) eventually make its way into a stable release. Therefore it would be inappropriate for me to put anything less than a later beta release of PostgreSQL there. This time, there was a long-standing blockage in moving from unstable to testing caused by the interaction of several fundamental packages (such as libc6 and perl) with release-critical bugs, so we were asked not to do uploads that might compound the problem by (potentially) introducing new RC bugs. Therefore all the 7.4 releases went to experimental instead. The logjam only cleared in time for me to put 7.4.1 in unstable. Unfortunately, this meant that packages didn't get built for other architectures unless someone using those architectures did a build from source, which apparently didn't happen with hppa. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Verily, verily, I say unto you, He that heareth my word, and believeth on him that sent me, hath everlasting life, and shall not come into condemnation; but is passed from death unto life. John 5:24 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/Java issues
Where is the standard, I for one would be interested in seeing it? Dave On Fri, 2004-01-02 at 01:09, Andrew Dunstan wrote: Jan Wieck wrote: The basic question is the definition of the lifetime of an object and it's identificaition when doing nested calls in this context. In the OO world, ideally a real world object is translated into one instance of a class. And complex structures are trees of instances, possibly of different classes. As an example, a sales order consists of the order header and a variable number of order lines. Therefore, per order we have one OH instance and several OL's. So far so good. Naturally, one Java object instance would correspond to one row in a database. It's not clear to me that this object -- row mapping is workable. It looks like Oracle, by allowing only static methods, has basically abandoned any possibility of it. ISTM that if you want to live in the object world, you have to take care of marshalling and unmarshalling the data yourself - either by manual methods or using some of the increasingly sophisticated automated tools that are available. OTOH, if you want to live in the table world, you have to live without the hard ties between data in different tables that the object world wants. PL/Java must surely live in the table world. IOW, the Java interface would probably need to function in a fairly similar way to the way the current C interface does. Or have I missed something? Also, what does the Standard say about all this? Has anyone actually seen it? cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Dave Cramer 519 939 0336 ICQ # 1467551 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PL/Java issues
Dave Cramer said: Where is the standard, I for one would be interested in seeing it? AFAIK it is not available except for $$$. It looks like the relevant standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded SQL). cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cache in plpgsql
Jan Wieck [EMAIL PROTECTED] writes: Tom Lane wrote: Another little problem is that plpgsql doesn't really have any mechanism for invalidating cached stuff at all; it will leak memory like there's no tomorrow if we start dropping cached subplans. Everyone seems to look at it as a PL/pgSQL specific problem. It is not! No, of course not, but plpgsql has issues of its own that (IMHO) should be solved along with the SPI-level problem. As said, the idea is neither bad, nor new. And please let's not forget to add temp object detection into the dependency collector so that SPI automagically will handle temp tables used in PL/pgSQL by NOT storing prepared plans at all. Why shouldn't we cache plans for temp tables? They are good as long as the temp table exists. AFAICS the same dependency mechanism will work fine for temp and regular tables. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cache in plpgsql
Jan Wieck [EMAIL PROTECTED] writes: Tom Lane wrote: No, of course not, but plpgsql has issues of its own that (IMHO) should be solved along with the SPI-level problem. Not sure what you mean by that. I'm referring to the fact that plpgsql's internal data structures are all built with malloc and cannot be effectively reclaimed when the function definition is invalidated. I'd also like to get rid of its ad-hoc method of detecting function definition changes (viz, looking at the pg_proc row's xmin) in favor of hooking it into the same cache invalidation mechanism as SPI would be using. These are perhaps not essential changes, but they should happen eventually. Why shouldn't we cache plans for temp tables? They are good as long as the temp table exists. AFAICS the same dependency mechanism will work fine for temp and regular tables. Good point. So you mean to call the SPI functionality to mark plans for recompile at temp object destruction as well. I think it would be difficult to avoid. Temp objects are not very magic in themselves, they just live in particular schemas that happen to be a little bit magic. 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] cache in plpgsql
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: Tom Lane wrote: Another little problem is that plpgsql doesn't really have any mechanism for invalidating cached stuff at all; it will leak memory like there's no tomorrow if we start dropping cached subplans. Everyone seems to look at it as a PL/pgSQL specific problem. It is not! No, of course not, but plpgsql has issues of its own that (IMHO) should be solved along with the SPI-level problem. Not sure what you mean by that. Is it the execution plan shortcut stuff for simple expressions (you know, the faked econtext to evaluate just a function call) that you want to move into SPI as well? As said, the idea is neither bad, nor new. And please let's not forget to add temp object detection into the dependency collector so that SPI automagically will handle temp tables used in PL/pgSQL by NOT storing prepared plans at all. Why shouldn't we cache plans for temp tables? They are good as long as the temp table exists. AFAICS the same dependency mechanism will work fine for temp and regular tables. Good point. So you mean to call the SPI functionality to mark plans for recompile at temp object destruction as well. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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: Postgres + Xapian (was Re: [HACKERS] fulltext searching via a custom index type )
On Thu, Jan 01, 2004 at 11:19:07PM -0500, Eric B.Ridge wrote: I couldn't think of a way to create a whole new database type for Xapian that could deal with managing 5 btree indexes inside of Postgres (other than using tables w/ standard postgres btree index on certain fields), so instead, I dug into Xapian and abstracted out it's filesystem i/o (open, read, write, etc). (as an aside, I did spend some time pondering ways to adapt Postgres' nbtree AM to handle this, but I just don't understand how it works) I think your approach is too ugly. You will have tons of problems the minute you start thinking about concurrency (unless you want to allow only a single user accessing the index) and recovery (unless you want to force users to REINDEX when the system crashes). I think one way of attacking the problem would be using the existing nbtree by allowing it to store the five btrees. First read the README in the nbtree dir, and then poke at the metapage's only structure. You will see that it has a BlockNumber to the root page of the index. Try modifying that to make it have a BlockNumber to every index's root page. You will have to provide ways to access each root page and maybe other nonstandard things (such as telling the root split operation what root page are you going to split), but you will get recovery and concurrency (at least to a point) for free. Hope this helps, -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La espina, desde que nace, ya pincha (Proverbio africano) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] [HACKERS] PL/Java issues
Dave Cramer wrote: Barry, Ok, so if we drop this limitation then we leave it up to the architect to manage the caching problem themselves. Maybe I don't understand enough about Java, but isn't this limitation (only static methods callable) exactly what avoids having to deal with the call-instance association in the PL framework? I think we still want to go a little further in the framework and provide at least the object caches. Since we don't have any ON COMMIT or ON ROLLBACK triggers, it'd be hard for the PL programmer to deal with cleanup and object dereferencing, especially in the case of transaction abort. The class loader issue is interesting, this would mean that each object static or otherwise would not be able to overwrite others data. I think if we would create one thread per backend (on the first call of any PL/Java proc of course), and also have one class loader per thread, that'd be sufficient at least from a security point of view. Jan --dc-- On Wed, 2003-12-31 at 19:34, Barry Lind wrote: Jan, In Oracle a call from sql into java (be it trigger, stored procedure or function), is required to be a call to a static method. Thus in Oracle all the work is left for the programmer to manage object instances and operate on the correct ones. While I don't like this limitation in Oracle, I can't see a better way of implementing things. Therefore if you want to operate on object instances you (in Oracle) need to code up object caches that can hold the instances across function calls so that two or more functions can operate on the same instance as necessary. What this implies to the implementation is that in order to be possible the multiple function calls need to run inside the same jvm (so you can access the static caches across the different calls). If every call created a new jvm instance in Oracle you couldn't do very much. The Oracle jvm essentially gives you one jvm per connection (although technically it is somewhere between one jvm for the whole server and one per connection - i.e. it has the memory and process footprint of a single jvm for the entire server, but appears to the user as a jvm per connection). Having one jvm per connection is important to limit multiple connections ability to stomp on each others data. Something similar could probably a done for postgres by having one jvm running, by having each postgres connection having a unique thread in that jvm and having each connection thread run with its own class loader instance so that separate classes (and thus static members) are loaded for each connection. thanks, --Barry Jan Wieck wrote: I have included the JDBC mailing list since I guess most Java developers are around here, but not necessarily on Hackers. Dave Cramer and I where discussing a few issues about the PL/Java implementation last night and would like to get more input and suggestions on the matter. The basic question is the definition of the lifetime of an object and it's identificaition when doing nested calls in this context. In the OO world, ideally a real world object is translated into one instance of a class. And complex structures are trees of instances, possibly of different classes. As an example, a sales order consists of the order header and a variable number of order lines. Therefore, per order we have one OH instance and several OL's. So far so good. Naturally, one Java object instance would correspond to one row in a database. If we now implement a stored procedure in PL/Java, that means that a pg_proc entry corresponds to a specific method of a specific class (its signature). But there is no obvious relationship between functions and tables or other objects. Because of that it is not implicitly clear if an incoming call to a method is meant for an existing instance or if a new one should be created. As an example, if a PL/Java trigger on the order header executes an SPI query on the order lines, a trigger on the order line (also in PL/Java) might now want to call a method on it's parent object (the order header that is waiting for the SPI result set). This should NOT result in another OH instance being created for the same logical OH. Probably it is not possible to map these things automatically while keeping the system flexible enough to be usefull. But is it feasable to require the programmer to provide glue code for every procedure that does all these things? How does Oracle attack this problem? Jan ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [HACKERS] PL/Java issues
Andrew Dunstan wrote: AFAIK it is not available except for $$$. It looks like the relevant standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded SQL). For working drafts try: http://www.wiscorp.com/sql/sql_2003_standard.zip (5WD-13-JRT-2003-09.pdf) http://www.wiscorp.com/sql/sqljrout.zip (SQLJ Part 1--SQL Routines) http://www.wiscorp.com/sql/sqljtype.zip (SQLJ Part 2--SQL Types) Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] time format
Create table with type TIMESTAMP(0) Chris ivan wrote: how can i change default time format because now i have for example 2004-01-01 16:51:46.995927 but i want only 2004-01-01 16:51:46, with out millisec. a tryed with Data-Style but there arent custom style :/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
