Re: [HACKERS] How to make @id or $id as parameter name in plpgsql, is it available?
Hello, Michael Fuhr I've changed my clock. Back to future now. ^_^ Thanks & Regards! Arnold.Zhu 2004-11-24 === 2004-11-24 13:52:05 You wrote: === >On Tue, Nov 23, 2004 at 10:46:54PM -0700, Michael Fuhr wrote: > >> On Thu, Nov 23, 2000 at 11:59:58AM +0800, Arnold.Zhu wrote: > >Ummm...did you know your clock was four years behind? > >-- >Michael Fuhr >http://www.fuhr.org/~mfuhr/ > = = = = = = = = = = = = = = = = = = = = ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] How to make @id or $id as parameter name in plpgsql, is it available?
Hello, Michael Fuhr Thank you very much for your reply, I'm looking for a method to port our application with .Net and Sql Server 2000 to linux and mono. Sql server 2000's stored procedure take parameter like @Id, @Name etc. Then in our C# programs, use @Id, @Name as Select, Insert, Delete, Update commands' parameter name. I don't want to change our C# source and stored procedure too much. It contains about 50M of C# source files, and more than 1000 stored procedures. I want to use @id, @name as plpgsql's parameter, then I've no need to change C# source, only change Npgsql driver not to trim "@" and stored procedure to plpgsql. Is my description clear enough to express my thought? Waiting for your further replys. Thanks & Regards! Arnold.Zhu 2004-11-24 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] -V, --version -- deprecated?
The "--help" output for most of the binaries we install does not include the "-V" option (just its alias, --version). Is this intentional? (Note that we still document this option in the reference pages for some commands, and initdb's help output does include "-V".) Speaking of command-line options, "--version" and "--help" aren't documented in a lot of command reference pages. Is there a good reason why? -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] How to make @id or $id as parameter name in plpgsql, is it available?
On Tue, Nov 23, 2004 at 10:46:54PM -0700, Michael Fuhr wrote: > On Thu, Nov 23, 2000 at 11:59:58AM +0800, Arnold.Zhu wrote: Ummm...did you know your clock was four years behind? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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] How to make @id or $id as parameter name in plpgsql, is it available?
On Thu, Nov 23, 2000 at 11:59:58AM +0800, Arnold.Zhu wrote: > Can I change postgresql's source to make the following plpgsql works ? > If could, would you please tell me where can i change the source? > I want to try it. No need -- PostgreSQL 8.0 (currently in beta) already supports argument names in a function's argument list, although I think only PL/pgSQL currently does anything with them. > CREATE FUNCTION users_select_by_id(@id int4) Change @id to be a valid identifier name and it should work. You can keep using @id if you double-quote it as "@id". If that's not what you meant then please be more specific. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Big number of schemas (3500) into a single database
"Constantin Teodorescu" <[EMAIL PROTECTED]> writes: > If I will choose to keep a mirror of every workstation database in a > separate schema in the central database that mean that I will have 3500 > different schemas. > Is there any limit or any barrier that could stop this kind of approach or > make things go slower? Would you need to put them all into "search_path" at once? I'm not sure what the scaling issues might be for long search_paths, but I wouldn't be surprised if it's bad. But as long as you don't do that, I don't believe there will be any problems. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [JDBC] Strange server error with current 8.0beta driver
Tom,
Here is what you requested. (Thanks to Oliver for the good logging in
the jdbc driver).
I also have the test case (in java) down to the bare minimum that
generated the following output (that test case is attached). (Note that
if the FETCH in the test case is not executed then the backend crashes;
with the FETCH you get an error: "ERROR: unrecognized node type: 0")
Thanks,
--Barry
PostgreSQL 8.0devel JDBC3 with SSL (build 308)
Trying to establish a protocol version 3 connection to localhost:5432
FE=> StartupPacket(user=blind, database=fileswfs43,
client_encoding=UNICODE, DateStyle=ISO)
<=BE AuthenticationOk
<=BE ParameterStatus(client_encoding = UNICODE)
<=BE ParameterStatus(DateStyle = ISO, MDY)
<=BE ParameterStatus(integer_datetimes = off)
<=BE ParameterStatus(is_superuser = on)
<=BE ParameterStatus(server_encoding = UNICODE)
<=BE ParameterStatus(server_version = 8.0.0beta4)
<=BE ParameterStatus(session_authorization = blind)
<=BE BackendKeyData(pid=3348,ckey=914259969)
<=BE ReadyForQuery(I)
compatible = 8.0
loglevel = 2
prepare threshold = 1
getConnection returning
driver[className=org.postgresql.Driver,[EMAIL PROTECTED]
simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandl
[EMAIL PROTECTED], maxRows=0, fetchSize=0, flags=0
FE=> Parse(stmt=S_1,query="BEGIN",oids={})
FE=> Bind(stmt=S_1,portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Parse(stmt=S_2,query="DECLARE CUR CURSOR FOR SELECT 1",oids={})
FE=> Bind(stmt=S_2,portal=null)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [S_1]
<=BE BindComplete [null]
<=BE CommandStatus(BEGIN)
<=BE ParseComplete [S_2]
<=BE BindComplete [null]
<=BE NoData
<=BE CommandStatus(DECLARE CURSOR)
<=BE ReadyForQuery(T)
simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandl
[EMAIL PROTECTED], maxRows=0, fetchSize=0, flags=0
FE=> Parse(stmt=S_3,query="FETCH FORWARD 10 FROM CUR",oids={})
FE=> Bind(stmt=S_3,portal=null)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [S_3]
<=BE BindComplete [null]
<=BE RowDescription(1)
<=BE DataRow
<=BE CommandStatus(FETCH)
<=BE ReadyForQuery(T)
simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandl
[EMAIL PROTECTED], maxRows=0, fetchSize=0, flags=0
FE=> Parse(stmt=S_4,query="CLOSE CUR",oids={})
FE=> Bind(stmt=S_4,portal=null)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [S_4]
<=BE BindComplete [null]
<=BE NoData
<=BE CommandStatus(CLOSE CURSOR)
<=BE ReadyForQuery(T)
simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandl
[EMAIL PROTECTED], maxRows=0, fetchSize=0, flags=0
FE=> Bind(stmt=S_2,portal=null)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE BindComplete [null]
<=BE NoData
<=BE ErrorMessage(ERROR: unrecognized node type: 0
Location: File: clauses.c, Routine: expression_tree_mutator, Line:
3220
Server SQLState: XX000)
java.sql.SQLException: ERROR: unrecognized node type: 0
Location: File: clauses.c, Routine: expression_tree_mutator, Line:
3220
Server SQLState: XX000
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecu
torImpl.java:1356)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImp
l.java:1151)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:
166)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stateme
nt.java:363)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdb
c2Statement.java:308)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stateme
nt.java:299)
at test80.main(test80.java:31)
SQLException: SQLState(XX000)
<=BE ReadyForQuery(E)
java.sql.SQLException: ERROR: unrecognized node type: 0
Location: File: clauses.c, Routine: expression_tree_mutator, Line:
3220
Server SQLState: XX000
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 23, 2004 7:10 AM
To: Barry Lind
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] [JDBC] Strange server error with current 8.0beta
driver
"Barry Lind" <[EMAIL PROTECTED]> writes:
> OK, getting closer. The error happens if in jdbc I reuse
> PreparedStatement objects to reexecute the same set of queries
> multiple times.
The TRAP you showed looked like it might have something to do with
trying to execute code outside any transaction. But I dunno how it got
there.
> If you still need a test case, let me know, and I will continue to
> package up what I have been working on.
What I'd actually rather have is a list of the exact sequence of
messages sent to the server.
regards, tom lane
test80.java
Description: test80.java
--
Re: [HACKERS] Plperl Safe version check fails for Safe 2.09
Mark Kirkwood <[EMAIL PROTECTED]> writes: > It seems that the check in src/pl/plperl/plperl.c > eval_pv((safe_version < 2.09 ? safe_bad : safe_ok), FALSE); > is not working quite as expected (CVS HEAD from today): Yah know, I looked at that on Monday and said to myself "Self, that looks like a rounding problem waiting to happen" ... but in the absence of a trouble report didn't want to mess with it. Part of the problem is that Perl NV is double, not float, and so the declaration of safe_version is wrong on its face. But even with it properly declared, exact comparison of double values is playing with fire. I'd be inclined to change it to something like double safe_version; ... if (safe_version < 2.089) ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [Testperf-general] Re: [HACKERS] ExclusiveLock
On Tue, Nov 23, 2004 at 12:04:17AM +, Simon Riggs wrote: > On Mon, 2004-11-22 at 23:37, Greg Stark wrote: > > Simon Riggs <[EMAIL PROTECTED]> writes: > > > > > - Find a way to reduce rotational delay when repeatedly writing last WAL > > > page > > > > > > Currently fsync of WAL requires the disk platter to perform a full > > > rotation to fsync again. One idea is to write the WAL to different > > > offsets that might reduce the rotational delay. > > > > Once upon a time when you formatted hard drives you actually gave them an > > interleave factor for a similar reason. These days you invariably use an > > interleave of 1, ie, store the blocks continuously. Whether that's because > > controllers have become fast enough to keep up with the burst rate or > > because > > the firmware is smart enough to handle the block interleaving invisibly > > isn't > > clear to me. > > > > I wonder if formatting the drive to have an interleave >1 would actually > > improve performance of the WAL log. > > > > It would depend a lot on the usage pattern though. A heavily used system > > might > > be able to generate enough WAL traffic to keep up with the burst rate of the > > drive. And an less used system might benefit but might lose. > > > > Probably now the less than saturated system gets close to the average > > half-rotation-time latency. This idea would only really help if you have a > > system that happens to be triggering pessimal results worse than that due to > > unfortunate timing. > > I was asking whether that topic should be removed, since Tom had said it > had been rejected > > If you could tell me how to instrument the system to (better) show > whether such plans as you suggest are workable, I would be greatly > interested. Anything we do needs to be able to be monitored for > success/failure. > > -- > Best Regards, Simon Riggs > The disk performance has increased so much that the reasons for having an interleave factor other than 1 (no interleaving) have all but disappeared. CPU speed has also increased so much relative to disk speed that using some CPU cycles to improve I/O is a reasonable approach. I have been considering how this might be accomplished. As Simon so aptly pointed out, we need to show that it materially affects the performance or it is not worth doing. The simplest idea I had was to pre-layout the WAL logs in a contiguous fashion on the disk. Solaris has this ability given appropriate FS parameters and we should be able to get close on most other OSes. Once that has happened, use something like the FSM map to show the allocated blocks. The CPU can keep track of its current disk rotational position (approx. is okay) then when we need to write a WAL block start writing at the next area that the disk head will be sweeping. Give it a little leaway for latency in the system and we should be able to get very low latency for the writes. Obviously, there would be wasted space but you could intersperse writes to the granularity of space overhead that you would like to see. As far as implementation, I was reading an interesting article that used a simple theoretical model to estimate disk head position to avoid latency. Yours truly, Ken Marshall ---(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
[HACKERS] How to make @id or $id as parameter name in plpgsql, is it available?
Hello, pgsql-hackers Can I change postgresql's source to make the following plpgsql works ? If could, would you please tell me where can i change the source? I want to try it. --- CREATE FUNCTION users_select_by_id(@id int4) RETURNS SETOF users_set AS ' declare rec record; begin for rec in select * from users where id = @id loop return next rec; end loop; return; end; 'LANGUAGE plpgsql; --- Thanks & Regards Arnold.Zhu 2000-11-23 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Big number of schemas (3500) into a single database
Hello to everybody again, thought you didn’t hear any news from me for a very long time, the news are good J I’m still here and promoting PostgreSQL. I am involved in the developing of a big romanian project for the vets that will put Linux & PostgreSQL on 3500 computers in the whole country, linked together with dial-up connections that will keep track of the animal movements. The central database (also PostgreSLQ) will hold billions of records with animal events (births, movements, slaughter and so on) and my question is: If I will choose to keep a mirror of every workstation database in a separate schema in the central database that mean that I will have 3500 different schemas. Is there any limit or any barrier that could stop this kind of approach or make things go slower? Constantin Teodorescu Ancient PgAccess developer P.S. Please Cc: me at [EMAIL PROTECTED]
[HACKERS] Bitmap index
Hello, I saw discussion about bitmap indexes few weeks ago. I wonder if any of you is working on it (in secret)? I will be chosing subject of my master thesis and thougth about implementing bitmap indexes. -- **Paweł Niewiadomski**, new()foo-baz.com, http://new.foo-baz.com/ Podręcznik Administratora Systemu Linux: http://sag.foo-baz.com/ Podręcznik Programisty Systemu Linux: http://lpg.foo-baz.com/ Virtual Qmail (http://v-q.foo-baz.com), qmail-patches (http://q-p.foo-baz.com) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Plperl Safe version check fails for Safe 2.09
A bit more thinking led me to try: float safe_version; ... eval_pv((safe_version < (float)2.09 ? safe_bad : safe_ok), FALSE); which seems to fix the issue. (after all float *should* be accurate enough in this case) cheers Mark P.s : trivial patch attached Andrew Dunstan wrote: Could be a rounding issue. What happens if you try this instead:? eval_pv((safe_version <= 2.08 ? safe_bad : safe_ok), FALSE); Alternatively, what happens if we make safe_version a double rather than a float? (If nothing else works we might have to fall back on a lexical comparison) cheers andrew --- plperl.c.orig 2004-11-24 17:04:07.0 +1300 +++ plperl.c2004-11-24 17:04:21.0 +1300 @@ -244,7 +244,7 @@ safe_version = SvNV(res); - eval_pv((safe_version < 2.09 ? safe_bad : safe_ok), FALSE); + eval_pv((safe_version < (float)2.09 ? safe_bad : safe_ok), FALSE); plperl_safe_init_done = true; } ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta5 now Available
On Tue, Nov 23, 2004 at 08:43:56PM -0400, Marc G. Fournier wrote: > On Wed, 24 Nov 2004, Thomas Hallgren wrote: > > >Gaetano Mendola wrote: > >>...so the very first client is the real server that must be run > >>24/24. > >> > >I don't think this is correct. You need a tracker for downloaders > >to be able to find each other but no client is more important than > >the others. > > can there be multiple trackers? for instance, if we ran > bt.postgresql.org on two different servers, could they both run > trackers at the same time? I suspect the best thing would be to run the tracker on one server (bt) and seeders elsewhere. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OpenBSD/Sparc status
On Tue, Nov 23, 2004 at 11:34:44AM -0700, Michael Fuhr wrote: > > gcc 3.4.2 on Solaris 9/sparc 64 appears to be okay. But gcc 3.3.2 on Solaris 9/sparc 64 isn't. % gcc -m64 test.c % ./a.out x = 12.3 y = 12.3 % gcc -O -m64 test.c % ./a.out x = 12.3 y = 2.51673e-42 % gcc -O2 -m64 test.c % ./a.out x = 12.3 y = 2.51673e-42 % gcc -O3 -m64 test.c % ./a.out x = 12.3 y = 12.3 % file a.out a.out: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OpenBSD/Sparc status
On Tue, Nov 23, 2004 at 12:47:28PM -0800, Darcy Buskermolen wrote: > I'm guessing we need to add some more configure logic to detect gcc versions > 3.4 on sparc trying to produce 64bit code and disable optimizations, or else > bail out and ask them to upgrade. Shouldn't that be gcc versions 3.3? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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] Plperl Safe version check fails for Safe 2.09
Could be a rounding issue. What happens if you try this instead:? eval_pv((safe_version <= 2.08 ? safe_bad : safe_ok), FALSE); Alternatively, what happens if we make safe_version a double rather than a float? (If nothing else works we might have to fall back on a lexical comparison) cheers andrew Mark Kirkwood wrote: It seems that the check in src/pl/plperl/plperl.c eval_pv((safe_version < 2.09 ? safe_bad : safe_ok), FALSE); is not working quite as expected (CVS HEAD from today): I have Safe.pm at version 2.09, yet any plperl function I run fails with : ERROR: error from function: trusted perl functions disabled - please upgrade perl Safe module to at least 2.09 at (eval 4) line 1. Just to be sure I amended the test code to : elog(INFO, "Safe version = %f", safe_version); eval_pv((safe_version < 2.09 ? safe_bad : safe_ok), FALSE); and I see : INFO: Safe version = 2.09 (Followed by the error) I confess some puzzlement - as the code *looks* like it should work! The platform is Linux 2.4.22 glibc 2.3.2, perl 5.8.0 (Patched Redhat 9) regards Mark ---(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 ---(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] Beta5 now Available
On Wed, 24 Nov 2004, Thomas Hallgren wrote: Gaetano Mendola wrote: ...so the very first client is the real server that must be run 24/24. I don't think this is correct. You need a tracker for downloaders to be able to find each other but no client is more important than the others. can there be multiple trackers? for instance, if we ran bt.postgresql.org on two different servers, could they both run trackers at the same time? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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
[HACKERS] Plperl Safe version check fails for Safe 2.09
It seems that the check in src/pl/plperl/plperl.c eval_pv((safe_version < 2.09 ? safe_bad : safe_ok), FALSE); is not working quite as expected (CVS HEAD from today): I have Safe.pm at version 2.09, yet any plperl function I run fails with : ERROR: error from function: trusted perl functions disabled - please upgrade perl Safe module to at least 2.09 at (eval 4) line 1. Just to be sure I amended the test code to : elog(INFO, "Safe version = %f", safe_version); eval_pv((safe_version < 2.09 ? safe_bad : safe_ok), FALSE); and I see : INFO: Safe version = 2.09 (Followed by the error) I confess some puzzlement - as the code *looks* like it should work! The platform is Linux 2.4.22 glibc 2.3.2, perl 5.8.0 (Patched Redhat 9) regards Mark ---(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] Beta5 now Available
Gaetano Mendola wrote: ...so the very first client is the real server that must be run 24/24. I don't think this is correct. You need a tracker for downloaders to be able to find each other but no client is more important than the others. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Beta5 now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc G. Fournier wrote: | On Mon, 22 Nov 2004, Thomas Hallgren wrote: | |> Marc G. Fournier wrote: |> |>> What about the Java version that Gavin had mentioned? Aegus or |>> something like that? |>> |> http://azureus.sourceforge.net/ | | | There is a FreeBSD port of it also but it says "A BitTorrent client | written in Java" ... does it work as server too, or, by its nature, are | servers == clients in Bittorrent? :) Bittorrent is based on a tracker, the tracker is embedded in the metafile (.torrent file ) and also is based on the "first client" that is launched pointing to the complete file; so the very first client is the real server that must be run 24/24. What do you have against the python implementation ? Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBo8I97UpzwH2SGd4RAiXcAJ4oa5EAN2QpUnM2ajxXVrkpzWCZlwCgpVyT hG8UO4kGUZnYBfJRt+SchTs= =RaCu -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Easy way to download all .torrents
For a while I've been keeping a bittorrent client running with some of the common postgresql torrents that are available, but grabbing the .torrent files is a bit of a pain. Is there an easy way to download all of the appropriate .torrent files that are available? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OpenBSD/Sparc status
On November 23, 2004 11:37 am, Jim Seymour wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: > > Darcy Buskermolen wrote: > > > On November 19, 2004 10:55 am, you wrote: > > >>The answer is: it's a gcc bug. The attached program should print > > >>x = 12.3 > > >>y = 12.3 > > >> > > >>but if compiled with -O or -O2 on Stefan's machine, I get garbage: > > >> > > >>$ gcc -O ftest.c > > >>$ ./a.out > > >>x = 12.3 > > >>y = 1.47203e-39 > > >>$ gcc -v > > >>Reading specs from > > >> /usr/lib/gcc-lib/sparc64-unknown-openbsd3.6/3.3.2/specs Configured > > >> with: > > >>Thread model: single > > >>gcc version 3.3.2 (propolice) > > >>$ > > > > > > I can confirm this behavior on Solaris 8/sparc 64 as well. > > > > some more datapoints: > > > > solaris 2.9 with gcc 3.1 is broken(-O3 does not help here) > > linux/sparc64 (debian) with gcc 3.3.5 is broken too > > > > So it looks like at least gcc 3.1 and gcc 3.3.x are affected on Sparc64 > > on all operating systems. > > Yet Another Datapoint: > > $ uname -a > SunOS jimsun 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine > $ gcc -v > ... > gcc version 3.3.1 > $ gcc -O -m64 test.c > $ a.out > x = 12.3 > y = 2.55036e-42 > > Same on a "real" UltraSparc box, running Solaris 8 and gcc 3.3.1 > at work. > > Looks like it's time for a gcc upgrade. > > Jim The following compilers work fine producing 12.3 at all optimization levels: Sun C 5.5 2003/03/12 and sparc-sun-solaris2.9-gcc (GCC) 3.4.1 I'm guessing we need to add some more configure logic to detect gcc versions 3.4 on sparc trying to produce 64bit code and disable optimizations, or else bail out and ask them to upgrade. > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] another plperl bug
Richard Poole wrote: Indeed. It would be Perlish to have some magic so that when you called one PL/Perl function from another you could return an array ref from the inner one and have it Do What You Mean in the outer one, too. There is no way to have one plperl function call another directly - they are anonymous and a reference to them is not stored anywhere accessible inside the perl interpreter. The only place the reference is stored is in a table on the C side of the plperl glue code. This is an architectural limitation that is not easily overcome. Back to the original suggestion - I would like to have a lot more magic that maps between perl hashrefs and postgres composites, and between perl arrayrefs and postgres arrays. A plperl programmer should ideally never have to construct or deconstruct the text representation of an array or a composite. That will have to be looked at after this release - we only just hit the feature freeze cutoff with what we have now, which is why a few warts are coming to light. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OpenBSD/Sparc status
Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: > > Darcy Buskermolen wrote: > > On November 19, 2004 10:55 am, you wrote: > > > >>The answer is: it's a gcc bug. The attached program should print > >>x = 12.3 > >>y = 12.3 > >> > >>but if compiled with -O or -O2 on Stefan's machine, I get garbage: > >> > >>$ gcc -O ftest.c > >>$ ./a.out > >>x = 12.3 > >>y = 1.47203e-39 > >>$ gcc -v > >>Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd3.6/3.3.2/specs > >>Configured with: > >>Thread model: single > >>gcc version 3.3.2 (propolice) > >>$ > > > > > > I can confirm this behavior on Solaris 8/sparc 64 as well. > > some more datapoints: > > solaris 2.9 with gcc 3.1 is broken(-O3 does not help here) > linux/sparc64 (debian) with gcc 3.3.5 is broken too > > So it looks like at least gcc 3.1 and gcc 3.3.x are affected on Sparc64 > on all operating systems. Yet Another Datapoint: $ uname -a SunOS jimsun 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine $ gcc -v ... gcc version 3.3.1 $ gcc -O -m64 test.c $ a.out x = 12.3 y = 2.55036e-42 Same on a "real" UltraSparc box, running Solaris 8 and gcc 3.3.1 at work. Looks like it's time for a gcc upgrade. Jim ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] another plperl bug
Michael Fuhr <[EMAIL PROTECTED]> writes: > On Tue, Nov 23, 2004 at 11:37:22AM -0500, Tom Lane wrote: >> I would add these test cases to the regression test were it not that the >> addresses are machine-dependent... > I haven't looked into how the regression tests work -- can test > output be post-processed before comparision with expected results? No, it's just a plain "diff". If it seemed worth the trouble, I'd put the hackery right into the SQL: select perl_func()::text ~ 'ARRAY\\(0x[0-9a-f]+\\)'; but it doesn't really seem worth it. regards, tom lane ---(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] another plperl bug
On Tue, Nov 23, 2004 at 11:37:22AM -0500, Tom Lane wrote:
>
> > CREATE FUNCTION test1() RETURNS TEXT AS $$
> > return ["test"];
> > $$ LANGUAGE plperl;
>
> > SELECT test1();
> > test1
> > --
> > ARRAY(0x8427a58)
> > (1 row)
>
> This is exactly what Perl will do if you try to coerce an array to a
> scalar:
>
> $ perl -e 'print ["test 1"], "\n"'
> ARRAY(0xa03ec28)
> $
To go a stage further, there's no array-to-scalar coercion happening
there; the [] syntax gives you a reference to an anonymous array, and
a reference to an array is a scalar, even when evaluated in list
context, as Tom's example is. If you wanted to return a list from
a sub in perl you'd just go return("test 1", "test 2").
> so I don't think a Perl programmer would find it surprising; if anything
> he'd probably complain if we *didn't* do that.
Indeed. It would be Perlish to have some magic so that when you called
one PL/Perl function from another you could return an array ref from
the inner one and have it Do What You Mean in the outer one, too.
Richard
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OpenBSD/Sparc status
Darcy Buskermolen wrote: On November 19, 2004 10:55 am, you wrote: The answer is: it's a gcc bug. The attached program should print x = 12.3 y = 12.3 but if compiled with -O or -O2 on Stefan's machine, I get garbage: $ gcc -O ftest.c $ ./a.out x = 12.3 y = 1.47203e-39 $ gcc -v Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd3.6/3.3.2/specs Configured with: Thread model: single gcc version 3.3.2 (propolice) $ I can confirm this behavior on Solaris 8/sparc 64 as well. some more datapoints: solaris 2.9 with gcc 3.1 is broken(-O3 does not help here) linux/sparc64 (debian) with gcc 3.3.5 is broken too So it looks like at least gcc 3.1 and gcc 3.3.x are affected on Sparc64 on all operating systems. Stefan ---(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] OpenBSD/Sparc status
On Tue, Nov 23, 2004 at 09:57:03AM -0800, Darcy Buskermolen wrote: > I can confirm this behavior on Solaris 8/sparc 64 as well. gcc 3.4.2 on Solaris 9/sparc 64 appears to be okay. % gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.2 % gcc -m64 test.c % ./a.out x = 12.3 y = 12.3 % gcc -O -m64 test.c % ./a.out x = 12.3 y = 12.3 % gcc -O2 -m64 test.c % ./a.out x = 12.3 y = 12.3 % gcc -O3 -m64 test.c % ./a.out x = 12.3 y = 12.3 % file a.out a.out: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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] OpenBSD/Sparc status
Tom Lane wrote: Darcy Buskermolen <[EMAIL PROTECTED]> writes: I can confirm this behavior on Solaris 8/sparc 64 as well. bash-2.03$ gcc -m64 -O2 test.c bash-2.03$ ./a.out x = 12.3 y = 2.51673e-42 bash-2.03$ gcc -m64 -O3 test.c bash-2.03$ ./a.out x = 12.3 y = 12.3 bash-2.03$ Hmm. I hadn't bothered to try -O3 ... interesting that it works correctly again at that level. -O3 works on my box too Anyway, this proves that it is an upstream gcc bug and not something OpenBSD broke. I just tried on solaris9 with gcc 3.4.2 - seems the bug is fixed in this version. Unfortunably it is quite problematic to change the compiler at least on OpenBSD gcc 3.3.2 is quite heavily modified on that platform and switching the base system compiler might screw a boatload of other tools. The actual recommendation I got from the OpenBSD-folks was to add "-mfaster-structs" to the compiler flags with seems to work around the issue - I'm currently doing a full build to verify that though ... Stefan ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] another plperl bug
On Tue, Nov 23, 2004 at 11:37:22AM -0500, Tom Lane wrote: > $ perl -e 'print ["test 1"], "\n"' > ARRAY(0xa03ec28) > $ > > so I don't think a Perl programmer would find it surprising; if anything > he'd probably complain if we *didn't* do that. Understood, which is why I mentioned that such cases might be considered GIGO and therefore not plperl's responsibility. Personally I'd like to see an error or warning since the result is near useless and the construct almost certainly not what the programmer meant, but I recognize that not everybody would. > I would add these test cases to the regression test were it not that the > addresses are machine-dependent... I haven't looked into how the regression tests work -- can test output be post-processed before comparision with expected results? If so, then a filter could normalize patterns like ARRAY(0xa03ec28) into something that would pass regression tests. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OpenBSD/Sparc status
On November 19, 2004 10:55 am, you wrote:
> The answer is: it's a gcc bug. The attached program should print
> x = 12.3
> y = 12.3
>
> but if compiled with -O or -O2 on Stefan's machine, I get garbage:
>
> $ gcc -O ftest.c
> $ ./a.out
> x = 12.3
> y = 1.47203e-39
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd3.6/3.3.2/specs
> Configured with:
> Thread model: single
> gcc version 3.3.2 (propolice)
> $
I can confirm this behavior on Solaris 8/sparc 64 as well.
bash-2.03$ gcc -O -m64 test.c
bash-2.03$ ./a.out
x = 12.3
y = 2.51673e-42
bash-2.03$ file a.out
a.out: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped
bash-2.03$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.3.2
bash-2.03$ gcc -m64 test.c
bash-2.03$ ./a.out
x = 12.3
y = 12.3
bash-2.03$ gcc -m64 -02 test.c
gcc: unrecognized option `-02'
bash-2.03$ gcc -m64 -O2 test.c
bash-2.03$ ./a.out
x = 12.3
y = 2.51673e-42
bash-2.03$ gcc -m64 -O3 test.c
bash-2.03$ ./a.out
x = 12.3
y = 12.3
bash-2.03$
>
> regards, tom lane
>
>
> #include
>
> float
> returnfloat(float *x)
> {
> return *x;
> }
>
> int
> main()
> {
> float x = 12.3;
> union {
> float f;
> char *t;
> } y;
>
> y.f = returnfloat(&x);
>
> printf("x = %g\n", x);
> printf("y = %g\n", y.f);
>
> return 0;
> }
>
> ---(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
--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Beta5 now Available
On Tue, Nov 23, 2004 at 11:06:40AM -0600, Jeff Hoffmann wrote: > Marc G. Fournier wrote: > >>The download servers have enough bandwidth to serve any client > >>faster than the client can take. The traffic on the download > >>servers is not reduced, only distributed differently. I don't see > >>any advantage. > > > > > >Actually, and here is where I exhibit my total lack of knowledge of > >BT internals ... my understanding was that each 'client' becomes a > >'server' by the fact that they have it on their machine and running > >... so, over time, the amount of load on the central server would > >decrease, since new downloads would come from closer "client > >machines" ... essentially, a whole new set of "unofficial mirror > >sites" for the source code ... > > That's not to say that it shouldn't be offered, it's just a niche > thing & is generally time-sensitive (i.e., it does the best when > there a lot of people using it & the time most people use it is when > something is "hot off the presses"). ^^^ The above is precisely the use case I set the thing up for. :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(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] Beta5 now Available
* Marc G. Fournier ([EMAIL PROTECTED]) wrote: > On Tue, 23 Nov 2004, Peter Eisentraut wrote: > >The download servers have enough bandwidth to serve any client faster than > >the client can take. The traffic on the download servers is not reduced, > >only distributed differently. I don't see any advantage. > > Actually, and here is where I exhibit my total lack of knowledge of BT > internals ... my understanding was that each 'client' becomes a 'server' > by the fact that they have it on their machine and running ... so, over > time, the amount of load on the central server would decrease, since new > downloads would come from closer "client machines" ... essentially, a > whole new set of "unofficial mirror sites" for the source code ... > > Is this a wrong understanding? Nope, that's about right, from what I understand. Not only that, but for far-flung people (from the server) it's possible that there are links between the server and the client that are too slow, bt could reduce the bandwidth demands on those links too if other people on the far side are also grabbing the stream. Stephen signature.asc Description: Digital signature
Re: [HACKERS] Beta5 now Available
Marc G. Fournier wrote: The download servers have enough bandwidth to serve any client faster than the client can take. The traffic on the download servers is not reduced, only distributed differently. I don't see any advantage. Actually, and here is where I exhibit my total lack of knowledge of BT internals ... my understanding was that each 'client' becomes a 'server' by the fact that they have it on their machine and running ... so, over time, the amount of load on the central server would decrease, since new downloads would come from closer "client machines" ... essentially, a whole new set of "unofficial mirror sites" for the source code ... This is essentially true, although it makes a lot more sense for things that are a lot larger (full ISO's like Linux distributions) and have a higher desirability than "official" avenues to get to them. That's not to say that it shouldn't be offered, it's just a niche thing & is generally time-sensitive (i.e., it does the best when there a lot of people using it & the time most people use it is when something is "hot off the presses"). PostgreSQL is sufficiently small and has high enough availibility that either you won't have to think twice about downloading through standard avenues or BT won't help you. -- Jeff Hoffmann [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: [HACKERS] patch: plpgsql - access records with rec.(expr)
> What about > for i in ... > ... new.(tg_argv[i]) ... Ooof! Constants or digits or nothing, then > MHO: this is a really ugly wart on the language, and it does not solve > the problems people would want to solve. It might solve *your* problem > but that's not enough to justify a wart of this size. But my warts are beautiful! OK, fair enough. I had to try. > We do need to do something about the fact that EXECUTE can't access > plpgsql variables, though I'm afraid that fixing that is going to > require a rather complete overhaul of plpgsql :-(. But it needs one > anyway. Look forward to seeing it. Matt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Beta5 now Available
On Tue, 23 Nov 2004, Peter Eisentraut wrote: Am Montag, 22. November 2004 17:40 schrieb David Fetter: A much slimmed-down bt.postgresql.org is now serving it. :) Out of curiosity, what purpose does a bittorrent source serve in this case? I've always just seen it as an alternative option for downloading *shrug* just like ftp:// or http:// ... The download servers have enough bandwidth to serve any client faster than the client can take. The traffic on the download servers is not reduced, only distributed differently. I don't see any advantage. Actually, and here is where I exhibit my total lack of knowledge of BT internals ... my understanding was that each 'client' becomes a 'server' by the fact that they have it on their machine and running ... so, over time, the amount of load on the central server would decrease, since new downloads would come from closer "client machines" ... essentially, a whole new set of "unofficial mirror sites" for the source code ... Is this a wrong understanding? This is David's baby though, not mind :) I don't know much about it, and based on what little I've read about it (and original discussions), believe its a more open source 'kazaa/napster', and, as such, works similar ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] another plperl bug
Michael Fuhr <[EMAIL PROTECTED]> writes: > How far do you want to go with checking return types? Some of the > following test cases are approaching "garbage in, garbage out" > territory and I don't know how much effort you want to put into > protecting programmers from themselves. Some of the cases already > raise errors; for consistency I'm inclined to think they all should. I think all these cases are actually OK as-is. > CREATE FUNCTION test1() RETURNS TEXT AS $$ > return ["test"]; > $$ LANGUAGE plperl; > SELECT test1(); > test1 > -- > ARRAY(0x8427a58) > (1 row) This is exactly what Perl will do if you try to coerce an array to a scalar: $ perl -e 'print ["test 1"], "\n"' ARRAY(0xa03ec28) $ so I don't think a Perl programmer would find it surprising; if anything he'd probably complain if we *didn't* do that. I would add these test cases to the regression test were it not that the addresses are machine-dependent... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Beta5 now Available
On Tue, Nov 23, 2004 at 05:33:15PM +0100, Peter Eisentraut wrote: > Am Montag, 22. November 2004 17:40 schrieb David Fetter: > > A much slimmed-down bt.postgresql.org is now serving it. :) > > Out of curiosity, what purpose does a bittorrent source serve in > this case? BitTorrent was designed to take bandwidth load off servers that would otherwise need to be on very large and expensive pipes. It does this by serving mostly information about where other servers are, rather than serving the same (much larger) chunks of data over and over again to clients. You can find more information on what BitTorrent does and how it does it at http://bittorrent.com/introduction.html HTH :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(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] Beta5 now Available
Am Montag, 22. November 2004 17:40 schrieb David Fetter: > A much slimmed-down bt.postgresql.org is now serving it. :) Out of curiosity, what purpose does a bittorrent source serve in this case? The download servers have enough bandwidth to serve any client faster than the client can take. The traffic on the download servers is not reduced, only distributed differently. I don't see any advantage. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Trouble with plpgsql on 7.4.6
On Tue, Nov 23, 2004 at 07:25:17AM -0500, D'Arcy J.M. Cain wrote: > The stderr was in the previous message. No gripes there either other > than in the startup after the failure. > > > Also see about getting a stack trace from one of the core dumps. > > I did look at the core file and here is what I saw: > > #0 0x483cafeb in kill () from /usr/lib/libc.so.12 > #1 0x483cd0af in __libc_mutex_catchall_stub (m=1212478892) > at /usr/src/lib/libc/thread-stub/thread-stub.c:112 > #2 0x4843f0f7 in free (ptr=) > at /usr/src/lib/libc/stdlib/malloc.c:1149 > #3 0x081b3efc in AllocSetDelete (context=) at aset.c:464 > #4 0x081b468a in MemoryContextDelete (context=) at > #mcxt.c:192 Would setting the following environment variable get you an earlier abort / more logging? (pthread(3)) PTHREAD_DIAGASSERT Possible values are any combinations of: A Ignore errors. a Abort on errors, creating a core dump for further debugging. E Do not log errors to stdout. e Log errors to stdout. L Do not log errors via syslogd(8). l Log errors via syslogd(8). Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] patch: plpgsql - access records with rec.(expr)
Matt <[EMAIL PROTECTED]> writes: > It would be a good idea to check that the variable was either a constant > or a trigger arg. This would stop the looping problem, since the type of > the underlying field couldn't change. What about for i in ... ... new.(tg_argv[i]) ... > But I've somehow got the feeling that this sort of thing isn't the > issue. The issue is whether we want to allow dynamic access to columns > in any syntax at all. A simple yes or no would do :) MHO: this is a really ugly wart on the language, and it does not solve the problems people would want to solve. It might solve *your* problem but that's not enough to justify a wart of this size. We do need to do something about the fact that EXECUTE can't access plpgsql variables, though I'm afraid that fixing that is going to require a rather complete overhaul of plpgsql :-(. But it needs one anyway. 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])
Re: [Testperf-general] Re: [HACKERS] ExclusiveLock
Title: RE: [Testperf-general] Re: [HACKERS] ExclusiveLock > From: Doug McNaught [mailto:[EMAIL PROTECTED]] > > "Bort, Paul" <[EMAIL PROTECTED]> writes: > > > One other thought: How does static RAM compare to disk > speed nowadays? > > A 1Gb flash drive might be reasonable for the WAL if it > can keep up. > > Flash RAM "wears out"; it's not suitable for a continuously-updated > application like WAL. > > -Doug > But if it's even 2x faster than a disk, that might be worth wearing them out. Given that they have published write count limits, one could reasonably plan to replace the memory after half of that time and be comfortable with the lifecycle. I saw somewhere that even with continuous writes on USB 2.0, it would take about twelve years to exhaust the write life of a typical flash drive. Even an order-of-magnitude increase in throughput beyond that only calls for a new drive every year. (Or every six months if you're paranoid. If you're that paranoid, you can mirror them, too.) Whether USB 2.0 is fast enought for the WAL is a separate discussion.
Re: [HACKERS] [JDBC] Strange server error with current 8.0beta driver
"Barry Lind" <[EMAIL PROTECTED]> writes: > OK, getting closer. The error happens if in jdbc I reuse > PreparedStatement objects to reexecute the same set of queries multiple > times. The TRAP you showed looked like it might have something to do with trying to execute code outside any transaction. But I dunno how it got there. > If you still need a test case, let me know, and I will continue to > package up what I have been working on. What I'd actually rather have is a list of the exact sequence of messages sent to the server. 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: [Testperf-general] Re: [HACKERS] ExclusiveLock
"Bort, Paul" <[EMAIL PROTECTED]> writes: >One other thought: How does static RAM compare to disk speed nowadays? >A 1Gb flash drive might be reasonable for the WAL if it can keep up. Flash RAM "wears out"; it's not suitable for a continuously-updated application like WAL. -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [Testperf-general] Re: [HACKERS] ExclusiveLock
Title: RE: [Testperf-general] Re: [HACKERS] ExclusiveLock > The impression I had was that disk drives no longer pay the slightest > attention to interleave specs, because the logical model > implied by the > concept is too far removed from modern reality (on-disk buffering, > variable numbers of sectors per track, transparently remapped bad > sectors, yadda yadda). > Entirely true. Interleave was an issue back when the controller wasn't fast enough to keep up with 3600 RPM disks, and is now completely obscured from the bus. I don't know if the ATA spec includes interleave control; I suspect it does not. > And that's just at the hardware level ... who knows where the > filesystem > is putting your data, or what the kernel I/O scheduler is doing with > your requests :-( > > Basically I see the TODO item as a blue-sky research topic, not > something we have any idea how to implement. That doesn't > mean it can't > be on the TODO list ... > I think that if we also take into consideration various hardware and software RAID configurations, this is just too far removed from the database level to be at all practical to throw code at. Perhaps this should be rewritten as a documentation change: recommendations about performance hardware? What we recommend for our highest volume customers (alas, on a proprietary RDBMS, and only x86) is something like this: - Because drive capacity is so huge now, choose faster drives over larger drives. 15K RPM isn't three times faster than 5400, but there is a noticable difference. - More spindles reduce delays even further. Mirroring allows reads to happen faster because they can come from either side of the mirror, and spanning reduces problems with rotational delays. - The ideal disk configuration that we recommend is a 14 drive chassis with a split backplane. Run each backplane to a separate channel on the controller, and mirror the channels. Use the first drive on each channel for the OS and swap, the second drive for transaction logs, and the remaining drives spanned (and already mirrored) for data. With a reasonable write cache on the controller, this has proven to be a pretty fast configuration despite a less than ideal engine. One other thought: How does static RAM compare to disk speed nowadays? A 1Gb flash drive might be reasonable for the WAL if it can keep up.
Re: [HACKERS] patch: plpgsql - access records with rec.(expr)
Just to put in my .02$, I would absolutely love to see this functionality included in plpgsql. With some extra error checking for the know changing datatype failure, and docs that mention that limitation, I'd say this is a great extension to the language. plpgsql feels quicker than the interpreted PLs and it's far easier than C to work with for writing triggers, so this patch makes plpgsql a much more attractive target for general purpose stored procs. And my gut feeling is that an EVALUATE statement would be significantly slower than this. In any case, thanks for the great work, Matt. Please, CORE, include this one! As an alternative, what would be the possibility of creating a new PL as a contrib module, say PLPGSQL_NG, to move forward with extensions like this and perhaps EVALUATE? -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer On 23 Nov 2004 09:03:10 +, Matt <[EMAIL PROTECTED]> wrote: > > > See your point. But what about NEW.($1)? > > > > I don't follow -- what do you mean? > > I want to be able to be able to write a trigger function that accesses a > column passed as an argument to the function in the row that caused the > trigger. This is my use case. > > I guess that would actually written NEW.(TG_ARGV[1]). > > > (BTW, I think my comment also applies to variables of type "text" and > > similar -- I think the patch would be a lot simpler if you just > > implement access to record fields by ordinal position, and don't > > implement access by field name.) > > Yes, it would be marginally simpler: I'd still have to call > exec_eval_datum() on the variable and check whether it could be > evaluated to an integer (trigger args are all text AFAIK). The only > difference would be throwing an error if it wasn't, instead of making > use of the value... and a slightly less readable 'create trigger' > statement. > > It would be a good idea to check that the variable was either a constant > or a trigger arg. This would stop the looping problem, since the type of > the underlying field couldn't change. > > But I've somehow got the feeling that this sort of thing isn't the > issue. The issue is whether we want to allow dynamic access to columns > in any syntax at all. A simple yes or no would do :) > > Matt > > BTW: here's the original post adding the rec.(3) syntax to the TODO: > http://archives.postgresql.org/pgsql-hackers/2003-07/msg00425.php > here's someone else who tried something very similar: > http://archives.postgresql.org/pgsql-hackers/2003-09/msg00533.php > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(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] Trouble with plpgsql on 7.4.6
On Sat, 20 Nov 2004 11:17:48 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > I thought that this would have sent everything to both the log and
> > the screen but I found that the syslog has much more detail. I have
> > attached that output.
>
> We still need to look at the stderr output. All this says is that
> you're getting repeated abort()s. It's unlikely that anything would
> be coded to abort() without emitting any gripe at all --- but the
> gripe is not appearing in syslog output, so stderr is the next place
> to look.
The stderr was in the previous message. No gripes there either other
than in the startup after the failure.
> Also see about getting a stack trace from one of the core dumps.
I did look at the core file and here is what I saw:
#0 0x483cafeb in kill () from /usr/lib/libc.so.12
#1 0x483cd0af in __libc_mutex_catchall_stub (m=1212478892)
at /usr/src/lib/libc/thread-stub/thread-stub.c:112
#2 0x4843f0f7 in free (ptr=)
at /usr/src/lib/libc/stdlib/malloc.c:1149
#3 0x081b3efc in AllocSetDelete (context=) at aset.c:464
#4 0x081b468a in MemoryContextDelete (context=) at
#mcxt.c:192
In fact it is calling the thread stubs but the applicatino is threaded.
At least, that's what I see from this code in NetBSD.
#define CHECK_NOT_THREADED_ALWAYS() \
do {\
if (__isthreaded) \
DIE(); \
} while (/*CONSTCOND*/0)
#if 1
#define CHECK_NOT_THREADED()CHECK_NOT_THREADED_ALWAYS()
#else
#define CHECK_NOT_THREADED()/* nothing */
#endif
I am going to follow up with the NetBSD team but I pass this on in case
it suggests anything. Note that this still only causes problems on
7.4.6 and not under 7.4.3.
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] Open thoughts about updateable views
As somebody already noticed i'm working on view update rules for (currently
SQL92 only) updateable views. There are some issues i would like to hear
the opinion of experienced pgsql-hackers about (and maybe get some pointers
to solve them):
Column DEFAULT values aren't automatically "inherited" from the base
relation. This means somebody has to do the following, to get view updates
with related sequences succeed:
=> Issue an ALTER TABLE view ALTER COLUMN col1 SET DEFAULT nextval('...')
to get an DEFAULT value from a sequence for example. Is it a good idea to
move this into the view update rule code or into the CREATE VIEW command?
Is the possibility to ALTER a view bulletproof or only a side-effect with
the future to be broken someday (because it looks not very intuitive...)?
Here's a short example, what i mean:
[EMAIL PROTECTED]:yomama #= CREATE OR REPLACE VIEW vabteilung_edv AS SELECT
bezeichnung AS c2, abteilungsnummer AS c1 from abteilung where bezeichnung
LIKE 'EDV%' WITH LOCAL CHECK OPTION;
NOTICE: CREATE VIEW will create implicit INSERT/UPDATE/DELETE rules
CREATE VIEW
[EMAIL PROTECTED]:yomama #= \d abteilung
Table "public.abteilung"
Column | Type |Modifiers
--+-+-
abteilungsnummer | integer | not null default
nextval('public.abteilung_abteilungsnummer_seq'::text)
bezeichnung | text| not null
Indexes:
"abteilung_pkey" PRIMARY KEY, btree (abteilungsnummer)
[EMAIL PROTECTED]:yomama #= INSERT INTO vabteilung_edv( c2 ) VALUES ( 'edv
abteilung' );
ERROR: view update commands violates rule condition
[EMAIL PROTECTED]:yomama #= INSERT INTO vabteilung_edv( c2 ) VALUES ( 'EDV
abteilung' );
ERROR: null value in column "abteilungsnummer" violates not-null constraint
==> the error message is confusing.
[EMAIL PROTECTED]:yomama #= ALTER TABLE vabteilung_edv ALTER COLUMN c1 SET
DEFAULT nextval('public.abteilung_abteilungsnummer_seq'::text);
ALTER TABLE
[EMAIL PROTECTED]:yomama #= INSERT INTO vabteilung_edv( c2 ) VALUES ( 'EDV
abteilung' );
INSERT 107905 1
[EMAIL PROTECTED]:yomama #= select * from vabteilung_edv;
c2 | c1
---+
EDV abteilung | 6
(1 row)
Implicit created rules are named _INSERT, _DELETE and _UPDATE and so no
other rules are allowed to live besides them to get the view update code
working. However, this breaks pg_dump restore's likely, but there is
another issue:
=> Views without the CHECK OPTION are intended to be updated in any manner
you can imagine. So, if a view only displays ID's > 5, you are allowed to
update ID's <= 5 according to the SQL92 Standard. With rules only, this is
not possible, since the planner doesn't see the affected tuples through the
view. What should be done in this case? One possibility is to hack the
planner/rewriter to get the specific tuples visible, but i don't think this
is a good idea. The other possibility is to consider views without the
CHECK OPTION read-only, which would help to not break any database dump's
with views, which have user defined update rules.
Any comments, thoughts or opinions?
--
Bernd
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] patch: plpgsql - access records with rec.(expr)
> > See your point. But what about NEW.($1)? > > I don't follow -- what do you mean? I want to be able to be able to write a trigger function that accesses a column passed as an argument to the function in the row that caused the trigger. This is my use case. I guess that would actually written NEW.(TG_ARGV[1]). > (BTW, I think my comment also applies to variables of type "text" and > similar -- I think the patch would be a lot simpler if you just > implement access to record fields by ordinal position, and don't > implement access by field name.) Yes, it would be marginally simpler: I'd still have to call exec_eval_datum() on the variable and check whether it could be evaluated to an integer (trigger args are all text AFAIK). The only difference would be throwing an error if it wasn't, instead of making use of the value... and a slightly less readable 'create trigger' statement. It would be a good idea to check that the variable was either a constant or a trigger arg. This would stop the looping problem, since the type of the underlying field couldn't change. But I've somehow got the feeling that this sort of thing isn't the issue. The issue is whether we want to allow dynamic access to columns in any syntax at all. A simple yes or no would do :) Matt BTW: here's the original post adding the rec.(3) syntax to the TODO: http://archives.postgresql.org/pgsql-hackers/2003-07/msg00425.php here's someone else who tried something very similar: http://archives.postgresql.org/pgsql-hackers/2003-09/msg00533.php ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
