[HACKERS] Javascript support in the backend, i.e. PL/JS
Hi All,
I've been writing some code[1] to support Javascript in the backend.
I've got the basic bits working, the next job for me is implementing
SPI support. Currently, it runs simple bits of code like the
following:
CREATE FUNCTION jsinc(n INTEGER) RETURNS INTEGER LANGUAGE pljs AS $$
return n+1;
$$;
It knows to compile the code inside a javascript function, passing the
parameters with the specified names. If no names are specified, $n
style naming is used--Javascript nicely deviates from C syntax in
respect of allowing $ in parameter names. It knows how to handle
boolean and numeric (int[248], float[48] and numeric) types are known
about at the moment. Javascript has only one numeric type, so
everything behaves as a double.
For SPI, I'm thinking that I'd currently like to attempt some object
orientated style interface. In simplest terms, it would look a bit
like this:
portal = {
next : function () { return {} }
close : function () { }
}
plan = {
query : function (args,readonly) { return portal; }
execute : function (args) { }
close : function () { }
}
spi = {
prepare : function (sql,argtypes) { return plan; }
}
So running some SQL would probably look something like:
for (row in spi.prepare(SELECT 1 AS n).query()) {
print(row.n);
}
The spi object would be passed into the javascript function as an extra
parameter, maybe with the name __spi to avoid name clashes.
I may put some shortcuts in if things turn out to be too slow later
on, but I'd prefer not to. Most other languages seem to expose the
SPI functions directly, but that seems like a bit of a waste in a
language that should be able to do OO stuff. PL/Java seems to have
its hands tied with JDBC, so I can't look there for much inspiration.
Are there any other OO languages that do things well?
Let me know what you think!
Sam
p.s. the main reason for doing this is because I think Javascript is a
nice language!. Having said that, Nulls are handled very badly by
javascript, so (1+null = 1) and (_+null+_ = _null_)!
[1] http://xen.samason.me.uk/~sam/repos/pljs/
It's definitely work in progress! I have fun with header
clashes between Postgres and Spidermonkey---hence the split
into C files.
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
On Fri, Nov 16, 2007 at 09:20:37AM +0100, Pavel Stehule wrote: On 16/11/2007, Sam Mason [EMAIL PROTECTED] wrote: Hi All, I've been writing some code[1] to support Javascript in the backend. I've got the basic bits working, the next job for me is implementing SPI support. Currently, it runs simple bits of code like the following: CREATE FUNCTION jsinc(n INTEGER) RETURNS INTEGER LANGUAGE pljs AS $$ return n+1; $$; nice It obviously runs much more complicated bits of javascript, but the main point is that it can't touch the outside world in any way. Functions are (as far as I understand the javascript implementation) completely deterministic (IMMUTABLE, in PG speak). Sam ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
On Fri, Nov 16, 2007 at 10:32:13AM +0100, Peter Eisentraut wrote: Am Freitag, 16. November 2007 schrieb Magnus Hagander: Last time it was flex (or was it bison). This time autoconf (which I beleive has happened before as well). It *will* happen again. Just download autoconf, bison, flex from GNU and do a source install. That should cover the problem. Yes. It's easy to do. But unless we want to get bitten by this again, it has to live in a controlled environment. IMHO, of course ;-) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Freitag, 16. November 2007 schrieb Marc G. Fournier: I know right now we have three different versions 'required', just can't recall which fall under which ... You just look into the files to see what was used last time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Freitag, 16. November 2007 schrieb Tom Lane: [ digs for a moment... ] According to my notes we are using autoconf 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13 is already out of the picture. It might be that 2.53 to 2.59 to 2.61 is not all that big a jump in reality, but I've got to say that it scares me when I read commit-log entries that report ten thousand lines worth of diffs in a 20K-line script ... Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't hard at all. We have been doing it for years. (Hint: ./configure; make; make install) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Problem with pg_dump -n schemaname
Hi,
we came across a problem when you want to dump only one schema.
The ASCII output when loaded with psql into an empty database
doesn't produce an identical schema to the original.
The problem comes from this statement ordering:
SET ... -- some initial DB parameters
...
SET search_path = schemaname , pg_catalog;
-- the above fails because no schema with this name exists
-- as a consequence, the original search_path (e.g. $user,
public)
-- is not modified
DROP INDEX schemaname.index1;
...
DROP TABLE schemaname.table1;
DROP SCHEMA schemaname;
CREATE SCHEMA schemaname;
ALTER SCHEMA schemaname OWNER TO schemaowner;
CREATE TABLE table1; -- note that it was DROPped with full name
schemaname.table1
...
So, because search_path is ' $user, public ' for e.g. postgres,
the tables are created in the public schema. Hence, I propose
the attached patch which issues SET search_path = ... statements
before the first CREATE TABLE stmt in their respective schema
instead of before the first DROP command.
The problem manifests only when you dump only one schema.
The same problem exists in at least 8.0.3, 8.2.5 and last 8.3cvs.
Best regards,
Zoltán Böszörményi
--
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
--- postgresql-8.2.5.orig/src/bin/pg_dump/pg_backup_archiver.c 2007-08-06 03:38:24.0 +0200
+++ postgresql-8.2.5/src/bin/pg_dump/pg_backup_archiver.c 2007-11-16 11:00:46.0 +0100
@@ -241,9 +241,6 @@
{
/* We want the schema */
ahlog(AH, 1, dropping %s %s\n, te-desc, te-tag);
-/* Select owner and schema as necessary */
-_becomeOwner(AH, te);
-_selectOutputSchema(AH, te-namespace);
/* Drop it */
ahprintf(AH, %s, te-dropStmt);
}
@@ -275,6 +272,10 @@
{
ahlog(AH, 1, creating %s %s\n, te-desc, te-tag);
+ /* Select owner and schema as necessary */
+ _becomeOwner(AH, te);
+ _selectOutputSchema(AH, te-namespace);
+
_printTocEntry(AH, te, ropt, false, false);
defnDumped = true;
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
On Fri, Nov 16, 2007 at 12:05:02PM +0100, Andreas Joseph Krogh wrote: On Friday 16 November 2007 11:29:09 Sam Mason wrote: [snip] SP? Stored Procedure That was kind of obvious wasn't it! I failed to parse that because of the an before it; an stored procedure doesn't make much sense! English is a great language isn't it. :) Sam ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
On Friday 16 November 2007 11:29:09 Sam Mason wrote: [snip] SP? Stored Procedure -- Andreas Joseph Krogh [EMAIL PROTECTED] Senior Software Developer / Manager +-+ OfficeNet AS| The most difficult thing in the world is to | Karenslyst Allé 11 | know how to do a thing and to watch | PO. Box 529 Skøyen | somebody else doing it wrong, without | 0214 Oslo | comment.| NORWAY | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Re: [Fwd: PGBuildfarm member narwhal Branch HEAD Status changed from OK to Make failure]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Nov 2007 20:48:38 -0500 Tom Lane [EMAIL PROTECTED] wrote: Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes: On Thu, 2007-11-15 at 21:26 -0400, Marc G. Fournier wrote: Any idea on how often narwhal will do a build? It looks that it builds -HEAD every 6 hours: http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=narwhalbr=HEAD and the next build is 2 hours later. Yeah. Theoretically we should be OK because we have a couple of green results from MSVC animals, but I wouldn't mind waiting two hours to see one from a Windows/gcc build. I already asked Dave if he could force a rebuild from home, no go :-( Since we are waiting anyway, something I brought up to Dave about this exact problem was the idea of a freeze :). E.g; All animals must go green and stay green with zero additional commits for 24 hours before we wrap. Is that something that sounds reasonable? Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: 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 - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPPiGATb/zqfZUUQRAry+AKCoKCGcJ4+E4B0sDKNe/2KJ3bzf2wCeJNCA O2OLZTBmw/rpk/TH/ZC6vlQ= =kzfS -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] AllocSetStats uses fprintf instead of elog
Zdenek Kotala [EMAIL PROTECTED] writes: Function AllocSetStats uses fprintf instead of standard logging method. Is there any reason for it? Yes: it's typically called in zero-free-memory situations, and we don't want to depend on elog() succeeding to be able to find out what happened. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Freitag, 16. November 2007 schrieb Magnus Hagander: Last time it was flex (or was it bison). This time autoconf (which I beleive has happened before as well). It *will* happen again. Just download autoconf, bison, flex from GNU and do a source install. That should cover the problem. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] strange tuple from ExecutorRun
Hello
I cannot find my bug. I would to get tuple via ExecutorRun. But it
works only with one field in target. With more fields I got last
fileld on first position and others fields are null. Can somebody help
me?
Pavel Stehule
postgres=# call print(10,20,30);
NOTICE: nargs 3
NOTICE: 30 0
NOTICE: 2139062143 0
NOTICE: 2139062143 0
code:
dest = CreateDestReceiver(DestNone, NULL);
ActiveSnapshot = CopySnapshot(GetTransactionSnapshot());
qdesc = CreateQueryDesc(plan, ActiveSnapshot,
InvalidSnapshot,
dest,
paramLI, false);
ExecutorStart(qdesc, 0);
result = ExecutorRun(qdesc, ForwardScanDirection, 1L);
tuple = ExecMaterializeSlot(result);
values = (Datum *) palloc(nargs * sizeof(Datum));
nulls = (char *) palloc(nargs * sizeof(char));
/* copy typle to current context */
tuple = heap_copytuple(tuple);
heap_deform_tuple(tuple, qdesc-tupDesc, values, nulls);
for(i = 0; i nargs; i++)
elog(NOTICE, %d %d, values[i], nulls[i]);
NOTICE: plan:
DETAIL: {PLANNEDSTMT
:commandType 1
:canSetTag true
:planTree
{RESULT
:startup_cost 0.00
:total_cost 0.01
:plan_rows 1
:plan_width 0
:targetlist (
{TARGETENTRY
:expr
{CONST
:consttype 23
:consttypmod -1
:constlen 4
:constbyval true
:constisnull false
:constvalue 4 [ 10 0 0 0 ]
}
:resno 1
:resname ?Parameter?
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
{TARGETENTRY
:expr
{CONST
:consttype 23
:consttypmod -1
:constlen 4
:constbyval true
:constisnull false
:constvalue 4 [ 20 0 0 0 ]
}
:resno 1
:resname ?Parameter?
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
{TARGETENTRY
:expr
{CONST
:consttype 23
:consttypmod -1
:constlen 4
:constbyval true
:constisnull false
:constvalue 4 [ 30 0 0 0 ]
}
:resno 1
:resname ?Parameter?
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
)
:qual
:lefttree
:righttree
:initPlan
:extParam (b)
:allParam (b)
:resconstantqual
}
:rtable
:resultRelations
:utilityStmt
:intoClause
:subplans
:rewindPlanIDs (b)
:returningLists
:rowMarks
:relationOids
:nParamExec 0
}
---(end of broadcast)---
TIP 6: explain analyze is your friend
[HACKERS] pg_ctl -t N register ??
Hi, I just noticed that the pg_ctl register synopsis was updated to have a -t parameter. This does not seem to make sense to me. Is it correct? Does it do anything? My thinking is that we should just remove the -t from that synopsis. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ Tiene valor aquel que admite que es un cobarde (Fernandel) ---(end of broadcast)--- TIP 1: 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] Javascript support in the backend, i.e. PL/JS
On Friday 16 November 2007 09:10:43 Sam Mason wrote: Hi All, I've been writing some code[1] to support Javascript in the backend. [snip] Wow, this is supercool! Most people, as you probably know, don't like JS as a language 'cause they think of it as a web-browser language with lots of bad side-effects, but that's 'cause they don't know the language, really. JS actually has some nice programming concepts and being able to use it as an SP seems pretty attractive. Keep up the good work! -- Andreas Joseph Krogh [EMAIL PROTECTED] Senior Software Developer / Manager +-+ OfficeNet AS| The most difficult thing in the world is to | Karenslyst Allé 11 | know how to do a thing and to watch | PO. Box 529 Skøyen | somebody else doing it wrong, without | 0214 Oslo | comment.| NORWAY | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. One idea people might suggest is to stop keeping the generated configure script in CVS. I'm not sure that'd make things better though. We'd be buying into the concept of trying to make configure.in work with any autoconf version any developer might be likely to use. I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Could we compare the configure version used during the compile and throw an error to catch mismatches? You would have to hard-code the configure version into one of the static Makefiles. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 17:44:52 + Dave Page [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane [EMAIL PROTECTED] wrote: I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPdjx4QvfyHIvDvMRAj6AAJwO7SFyhCi0qdFANX/5pWt8dagWFACff82K NbrLYsQF9JKIerV4DxPoljU= =gvyw -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? If the first thing some of them do is re-run autoconf, then we should get test results for a variety of versions as found on various distros. We would then be able to tell which versions may or may not work which could help us when we need to upgrade, or if someone has problems with a specific version when hacking (which should be rare I appreciate). /D ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. So let's create a VM for just this? A VM is very cheap, it just costs a bit of disk space as long as it's not used. And give committers access to it, to use it for committing these changes (unless they are running the correct version at home - a simple cvs diff before committing should show you very clearly if you're not). And before it's suggested, this should not be the cvs VM. The cvs VM is a dedicated VM for just that for stability and security reasons. It should remain that. Even though it's a VM where all the devs have accounts already. I just don't see any great value in it. I keep trees for doing commit work on all branches on my workstation - I suspect most other committers do too. I'm going to want the relevant configure version where I do my work, so I can test things out. Having multiple versions around isn't a huge burden. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spinlock backoff algorithm
On Wed, Nov 14, 2007 at 06:57:18PM -0800, Josh Berkus wrote: The question is, for our most common platforms (like AMD and Intel) is the FPU notably slower/more contended than integer division? I'd the impression that it was, but my knowledge of chip architectures is liable to be out of date. Can we have a hardware geek speak up? I did some searching and the best figures I can find for integer division is 15-40 cycles whereas for floating point the best I found was 5 cycles. The FP units on modern processer as very highly optimsed, but the figures quoted are for pipelined division, which is not what we're doing here. http://www.behardware.com/art/imprimer/623/ I did find a thread about how integer division on the Itanium was implemented by copying the integers to the FP registers, doing the division and rounding there and copying back. So at least there it's not true. http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01518.html Hope this helps, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
[HACKERS] Re: [Fwd: PGBuildfarm member narwhal Branch HEAD Status changed from OK to Make failure]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, November 15, 2007 20:23:30 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Should we wait longer for the buildfarm to become more green? Any idea on how often narwhal will do a build? are we talking 24hr to wait to see if it goes green?:) - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPPHa4QvfyHIvDvMRAjPmAJ9vvi+1Z3SpDR9rzVC4Bz6Jqz8s3QCfTGpT bmr7aMXrwWpCVPFX92+4Gh8= =0rDF -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
On Fri, Nov 16, 2007 at 09:04:38AM +0100, Peter Eisentraut wrote: Am Freitag, 16. November 2007 schrieb Tom Lane: [ digs for a moment... ] According to my notes we are using autoconf 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13 is already out of the picture. It might be that 2.53 to 2.59 to 2.61 is not all that big a jump in reality, but I've got to say that it scares me when I read commit-log entries that report ten thousand lines worth of diffs in a 20K-line script ... Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't hard at all. We have been doing it for years. (Hint: ./configure; make; make install) Yeah. I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. Last time it was flex (or was it bison). This time autoconf (which I beleive has happened before as well). It *will* happen again. If we move to the latest autoconf now, it will just happen the next time distro of choice upgrades what they have. (I say distro of choice. In thi case it's freebsd, but I'm sure it happens on other platforms as well. For example, I notice my Gutsy box has a different autoconf from my Dapper one. Which is why I do my pg autoconf work on the dapper one) //Magnus ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: update files for beta3
[EMAIL PROTECTED] (Marc G. Fournier) writes: configure (r1.570 - r1.571) (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570r2=1.571) It appears that Marc has got autoconf 2.61 installed now, instead of the 2.59 that we've been using for some time. I'm a bit concerned about the implications of switching to a version that's got zero track record for us, and that AFAIK no other committers have installed. I'd rather see a switch happen at the start of a devel cycle than at beta3; and in any case it's got to be coordinated so that what is in the release doesn't vary depending on who committed last. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, November 15, 2007 20:49:04 -0800 Joshua D. Drake [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so can someone else please run autoconf and commit, and I'll re-tag ... I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPSIc4QvfyHIvDvMRAoZCAJ9MF5wdAcB0aUTyT8qo62+DF61wywCfQLJF kSsl+ZTYu9SC+OEuA2NGPfU= =EDTa -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_ctl -t N register ??
Alvaro Herrera wrote: Hi, I just noticed that the pg_ctl register synopsis was updated to have a -t parameter. This does not seem to make sense to me. Is it correct? Does it do anything? My thinking is that we should just remove the -t from that synopsis. Well, Peter added it, but register already had the -w parameter, so either register needs both -t and -w, or it needs neither of them. I don't know which is true. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
Sam Mason [EMAIL PROTECTED] writes:
For SPI, I'm thinking that I'd currently like to attempt some object
orientated style interface. ...
So running some SQL would probably look something like:
for (row in spi.prepare(SELECT 1 AS n).query()) {
print(row.n);
}
What's not apparent to me is how one can avoid re-planning the query
every single time the function is called?
More generally, I think that the average programmer would rather just
not be bothered with all these details; he'd want to write
for (row in spi.query(...sql... [, arguments])) { ...
I don't object to exposing the machinery for those who like to play with
such stuff, but you should have shortcuts to keep the simple things
simple.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander wrote: So let's create a VM for just this? This just moves the problem elsewhere: from use the right autoconf version to use the right VM. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Terminal width for help output
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Nov 2007 16:04:46 -0500 Tom Lane [EMAIL PROTECTED] wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Do we care to maintain a maximum width for programs' --help output (and psql's \?)? I think 79 characters was once a recommendation (or perhaps 72), but we have a couple of violations either way, which I'd like to fix, but what to? I think 79 is still a reasonable maximum. AFAIK 80 columns is still a pretty standard terminal window width, but if you try to print in the last column you may get unexpected extra blank lines. O.k. this might be offtopic if it is feel free to smack me... but I have noticed that psql really breaks on terminals that are wide.. \df works fine, but \df+ is completely broke. Can't we just ask the terminal? Peter is talking about --help text that is hard-coded into the binary, meaning you don't run it through some filter before output. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] strange tuple from ExecutorRun
[ not directly related to your bug, but... ] Pavel Stehule [EMAIL PROTECTED] writes: result = ExecutorRun(qdesc, ForwardScanDirection, 1L); tuple = ExecMaterializeSlot(result); values = (Datum *) palloc(nargs * sizeof(Datum)); nulls = (char *) palloc(nargs * sizeof(char)); /* copy typle to current context */ tuple = heap_copytuple(tuple); heap_deform_tuple(tuple, qdesc-tupDesc, values, nulls); Surely that's the hard way, considering that the output tupleslot is probably *already* a values/nulls array. Use slot_getattr(), or call slot_getallattrs() and then reference the slot's arrays directly. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GiST crash recovery (potential problems?)
In GiST, I found that after the crash recovery, NSN and right page link are initialized. We can search all the records in this case but performance may become a little worse because we cannot traverse leaves. It doesn't matter. NSN and rightlink are used only during concurrent access: while we are scanning pages and page's LSN is changed - then page is changed. And if page is changed and LSN of parent page is less than NSN of current page then we should check right page. NSN and rightlink are changed synchronously. Look at gistget.c lines 185-197 (gistnext()) and at gistplacetopage() in gist.c The code doesn't believe that rigthlink is correct in any time and doesn't believe that you can read all level of tree following by right link as btree does. During recovery NSN doesn't increase. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] AllocSetStats uses fprintf instead of elog
Function AllocSetStats uses fprintf instead of standard logging method. Is there any reason for it? If not I will rewrite it to use elog(NOTICE,..) instead. Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Call for translations
Some of you have already been doing a great job, but I would like to point out that with the upcoming release of PostgreSQL 8.3, it is once again time to update the message translations. We are now near a string freeze, which has traditionally been associated with the first release candidate, so it's a good time to do this work now. If you want to help, see http://pgtranslation.projects.postgresql.org/ for instructions and other information. If there are already active translation teams, please communicate with them first. The mailing list [EMAIL PROTECTED] is available for general discussion and coordination of translation activities. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
On 16/11/2007, Sam Mason [EMAIL PROTECTED] wrote:
Hi All,
I've been writing some code[1] to support Javascript in the backend.
I've got the basic bits working, the next job for me is implementing
SPI support. Currently, it runs simple bits of code like the
following:
CREATE FUNCTION jsinc(n INTEGER) RETURNS INTEGER LANGUAGE pljs AS $$
return n+1;
$$;
nice
Pavel
It knows to compile the code inside a javascript function, passing the
parameters with the specified names. If no names are specified, $n
style naming is used--Javascript nicely deviates from C syntax in
respect of allowing $ in parameter names. It knows how to handle
boolean and numeric (int[248], float[48] and numeric) types are known
about at the moment. Javascript has only one numeric type, so
everything behaves as a double.
For SPI, I'm thinking that I'd currently like to attempt some object
orientated style interface. In simplest terms, it would look a bit
like this:
portal = {
next : function () { return {} }
close : function () { }
}
plan = {
query : function (args,readonly) { return portal; }
execute : function (args) { }
close : function () { }
}
spi = {
prepare : function (sql,argtypes) { return plan; }
}
So running some SQL would probably look something like:
for (row in spi.prepare(SELECT 1 AS n).query()) {
print(row.n);
}
The spi object would be passed into the javascript function as an extra
parameter, maybe with the name __spi to avoid name clashes.
I may put some shortcuts in if things turn out to be too slow later
on, but I'd prefer not to. Most other languages seem to expose the
SPI functions directly, but that seems like a bit of a waste in a
language that should be able to do OO stuff. PL/Java seems to have
its hands tied with JDBC, so I can't look there for much inspiration.
Are there any other OO languages that do things well?
Let me know what you think!
Sam
p.s. the main reason for doing this is because I think Javascript is a
nice language!. Having said that, Nulls are handled very badly by
javascript, so (1+null = 1) and (_+null+_ = _null_)!
[1] http://xen.samason.me.uk/~sam/repos/pljs/
It's definitely work in progress! I have fun with header
clashes between Postgres and Spidermonkey---hence the split
into C files.
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier [EMAIL PROTECTED] writes: - --On Friday, November 16, 2007 00:40:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Perhaps so, but it'd cost us a fair amount of up-front work to verify that we don't break the back branches by updating their configure scripts. Not something I want to touch on a last-minute basis ;-) Wasn't suggesting 'last-minute', but maybe post 8.3 release, while things are a bit quiet? Sure, if someone wants to do the legwork early in 8.4 devel cycle, I'm all for it ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
Sam Mason [EMAIL PROTECTED] writes:
On Fri, Nov 16, 2007 at 10:56:55AM -0500, Tom Lane wrote:
More generally, I think that the average programmer would rather just
not be bothered with all these details; he'd want to write
for (row in spi.query(...sql... [, arguments])) { ...
OK. Would you expect this to use cursors under the hood? I can't see a
good way of making this work without them unless I accept that they're
going to fail if the record set gets too large.
Yeah, you want it to just work ...
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane [EMAIL PROTECTED] wrote: I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPdXm4QvfyHIvDvMRAsuEAJwJ4F5yISz8wa/AR9W/b2kwgEky/ACgh015 7KGhYRO3GoyT/M/2mJn9k24= =2/7/ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. So let's create a VM for just this? A VM is very cheap, it just costs a bit of disk space as long as it's not used. And give committers access to it, to use it for committing these changes (unless they are running the correct version at home - a simple cvs diff before committing should show you very clearly if you're not). And before it's suggested, this should not be the cvs VM. The cvs VM is a dedicated VM for just that for stability and security reasons. It should remain that. Even though it's a VM where all the devs have accounts already. One idea people might suggest is to stop keeping the generated configure script in CVS. I'm not sure that'd make things better though. We'd be buying into the concept of trying to make configure.in work with any autoconf version any developer might be likely to use. I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Having it in cvs made life a *lot* easier when developing with mingw. Getting the proper autoconfy stuff going there is not easy at all. I'm sure there can be others having the same problems. I would much prefer a solution that keeps it in cvs. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane [EMAIL PROTECTED] wrote: I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? Maybe the BF members could just run their default autoconf as part of the build if they have one. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Dave Page wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. The problem here isn't really that we require a great testing and staging procedure for introducing new autoconf versions. The issue at hand is strictly that we shouldn't introduce a new autoconf version at the night of beta 3. When we want to move to a newer autoconf, we can handle it like any other patch. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Terminal width for help output
On Nov 15, 2007 4:56 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: Peter Eisentraut wrote: Do we care to maintain a maximum width for programs' --help output (and psql's \?)? I think 79 characters was once a recommendation (or perhaps 72), but we have a couple of violations either way, which I'd like to fix, but what to? 79 is perfect IMHO. It would be great to ask translators to preserve the constraint too. Agreed, all my terminals are set to standard 80 cols and I always manually wrap at 79 just to be safe. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_ctl -t N register ??
Bruce Momjian wrote: Alvaro Herrera wrote: Hi, I just noticed that the pg_ctl register synopsis was updated to have a -t parameter. This does not seem to make sense to me. Is it correct? Does it do anything? My thinking is that we should just remove the -t from that synopsis. Well, Peter added it, but register already had the -w parameter, so either register needs both -t and -w, or it needs neither of them. I don't know which is true. Humm, in pgwin32_CommandLine I don't see any reference to -t but -w is there. So either a) the bug is that somebody forgot to add -t to pgwin32_CommandLine b) the bug is that -t was added to the synopsis, or c) I'm full of it because of an untold reason. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica (Irulan) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 18:00:26 + Dave Page [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? If the first thing some of them do is re-run autoconf, then we should get test results for a variety of versions as found on various distros. We would then be able to tell which versions may or may not work which could help us when we need to upgrade, or if someone has problems with a specific version when hacking (which should be rare I appreciate). Ah, okay, you are going for the 'remove pre-built configure from cvs' route .. that works too, and does make sense ... wouldn't definitely make sure we get broad coverage ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPdwq4QvfyHIvDvMRAiqvAKDdtV+AtsFZe9WkbG+7GYPRs+0zvQCeJGxX pY3WUGVHUgXtU1mfYIGAfBo= =wyE3 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: 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] Javascript support in the backend, i.e. PL/JS
On Fri, Nov 16, 2007 at 10:56:55AM -0500, Tom Lane wrote:
Sam Mason [EMAIL PROTECTED] writes:
For SPI, I'm thinking that I'd currently like to attempt some object
orientated style interface. ...
So running some SQL would probably look something like:
for (row in spi.prepare(SELECT 1 AS n).query()) {
print(row.n);
}
What's not apparent to me is how one can avoid re-planning the query
every single time the function is called?
Nothing. I've not got a good solution for avoiding replanning between
invocations of the PL/JS function either.
I wanted to get the most complicated case working first, and as of about
5 minutes ago, it appears to be. Code's still quite a mess, but seems
to be functioning.
More generally, I think that the average programmer would rather just
not be bothered with all these details; he'd want to write
for (row in spi.query(...sql... [, arguments])) { ...
I don't object to exposing the machinery for those who like to play with
such stuff, but you should have shortcuts to keep the simple things
simple.
OK. Would you expect this to use cursors under the hood? I can't see a
good way of making this work without them unless I accept that they're
going to fail if the record set gets too large.
Sam
---(end of broadcast)---
TIP 1: 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] [pgtranslation-translators] Call for translations
Peter Eisentraut wrote:
Some of you have already been doing a great job, but I would like to point
out
that with the upcoming release of PostgreSQL 8.3, it is once again time to
update the message translations. We are now near a string freeze, which has
traditionally been associated with the first release candidate, so it's a
good time to do this work now.
I would like to propose this patch. This avoids an inconsistent message
wording, and removes the need to translate a string by duplicate.
--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
Estoy de acuerdo contigo en que la verdad absoluta no existe...
El problema es que la mentira sà existe y tu estás mintiendo (G. Lama)
Index: src/bin/initdb/initdb.c
===
RCS file: /home/alvherre/cvs/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.150
diff -c -p -r1.150 initdb.c
*** src/bin/initdb/initdb.c 15 Nov 2007 21:14:41 - 1.150
--- src/bin/initdb/initdb.c 16 Nov 2007 15:08:02 -
*** check_input(char *path)
*** 938,963
if (stat(path, statbuf) != 0)
{
if (errno == ENOENT)
fprintf(stderr,
! _(%s: file \%s\ does not exist\n
! This means you have a corrupted installation or identified\n
! the wrong directory with the invocation option -L.\n),
! progname, path);
else
fprintf(stderr,
! _(%s: could not access file \%s\: %s\n
! This might mean you have a corrupted installation or identified\n
! the wrong directory with the invocation option -L.\n),
! progname, path, strerror(errno));
exit(1);
}
if (!S_ISREG(statbuf.st_mode))
{
fprintf(stderr,
! _(%s: file \%s\ is not a regular file\n
! This means you have a corrupted installation or identified\n
! the wrong directory with the invocation option -L.\n),
! progname, path);
exit(1);
}
}
--- 938,968
if (stat(path, statbuf) != 0)
{
if (errno == ENOENT)
+ {
+ fprintf(stderr,
+ _(%s: file \%s\ does not exist\n), progname, path);
fprintf(stderr,
! _(This might mean you have a corrupted installation or identified\n
! the wrong directory with the invocation option -L.\n));
! }
else
+ {
+ fprintf(stderr,
+ _(%s: could not access file \%s\: %s\n), progname, path,
+ strerror(errno));
fprintf(stderr,
! _(This might mean you have a corrupted installation or identified\n
! the wrong directory with the invocation option -L.\n));
! }
exit(1);
}
if (!S_ISREG(statbuf.st_mode))
{
fprintf(stderr,
! _(%s: file \%s\ is not a regular file\n), progname, path);
! fprintf(stderr,
! _(This might mean you have a corrupted installation or identified\n
! the wrong directory with the invocation option -L.\n));
exit(1);
}
}
*** main(int argc, char *argv[])
*** 2958,2968
case 2:
/* Present and not empty */
fprintf(stderr,
! _(%s: directory \%s\ exists but is not empty\n
! If you want to create a new database system, either remove or empty\n
the directory \%s\ or run %s\n
with an argument other than \%s\.\n),
! progname, pg_data, pg_data, progname, pg_data);
exit(1); /* no further message needed */
default:
--- 2963,2975
case 2:
/* Present and not empty */
fprintf(stderr,
! _(%s: directory \%s\ exists but is not empty\n),
! progname, pg_data);
! fprintf(stderr,
! _(If you want to create a new database system, either remove or empty\n
the directory \%s\ or run %s\n
with an argument other than \%s\.\n),
! pg_data, progname, pg_data);
exit(1); /* no further message needed */
default:
*** main(int argc, char *argv[])
*** 3022,3031
case 2:
/* Present and not empty */
fprintf(stderr,
! _(%s: directory \%s\ exists but is not empty\n
! If you want to store the transaction log there, either\n
remove or empty the directory \%s\.\n),
! progname, xlog_dir, xlog_dir);
exit(1); /* no further message needed */
default:
--- 3029,3040
case 2:
/* Present and not empty */
fprintf(stderr,
! _(%s: directory \%s\ exists but is not empty\n),
! progname, xlog_dir);
! fprintf(stderr,
! _(If you want to store the transaction log there, either\n
remove or empty the directory \%s\.\n),
! xlog_dir);
exit(1); /* no further message needed */
default:
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Off-Topic: Float point division academia? (was: Re: [HACKERS] Spinlock backoff algorithm)
Martijn van Oosterhout wrote:
On Wed, Nov 14, 2007 at 06:57:18PM -0800, Josh Berkus wrote:
The question is, for our most common platforms (like AMD and Intel) is the FPU
notably slower/more contended than integer division? I'd the impression that
it was, but my knowledge of chip architectures is liable to be out of date.
Can we have a hardware geek speak up?
I did some searching and the best figures I can find for integer
division is 15-40 cycles whereas for floating point the best I found was 5
cycles. The FP units on modern processer as very highly optimsed, but
the figures quoted are for pipelined division, which is not what we're
doing here.
I agree with Tom that the although the user might be experiencing odd
issues as PostgreSQL was not designed for 32 light-weight cores like the
Niagara, that this particular issue is unlikely to be the primary issue.
In response to the academic discussion above, did you also look up the
time to convert from INT - FLOAT, and then FLOAT - INT?
Also, if divided by a constant, there are automatic optimization tricks
performed, such as:
$ cat a.c
int f(int i)
{
return i / 7;
}
$ gcc -O3 -S a.c
$ cat a.s
...
.globl f
.type f, @function
f:
.LFB2:
movl%edi, %eax
movl$-1840700269, %edx
imull %edx
leal(%rdx,%rdi), %eax
sarl$31, %edi
sarl$2, %eax
subl%edi, %eax
ret
No divide. No need to convert from INT - FLOAT - INT.
Here is non-conclusive evidence both that integer division by a constant
may still be faster on a fairly modern processor (AMD X2 3800+), and
that, as Tom believes, this issue is a waste of time:
$ cat a.c
#define MAX_RANDOM_VALUE (0x7FFF)
int old_f(int i)
{
return ((double) i / (double) MAX_RANDOM_VALUE) + 0.5;
}
int new_f(int i)
{
return (i + MAX_RANDOM_VALUE - 1) / MAX_RANDOM_VALUE;
}
$ cat old.c
int old_f(int);
int new_f(int);
int main()
{
for (int i = 0; i 1; i++)
old_f(50);
return 0;
}
$ cat new.c
int old_f(int);
int new_f(int);
int main()
{
for (int i = 0; i 1; i++)
new_f(50);
return 0;
}
$ gcc -o old -O3 -std=c99 old.c a.c
$ gcc -o new -O3 -std=c99 new.c a.c
$ time ./old
./old 1.58s user 0.00s system 99% cpu 1.590 total
$ time ./old
./old 1.31s user 0.00s system 99% cpu 1.314 total
$ time ./old
./old 1.14s user 0.00s system 99% cpu 1.142 total
$ time ./old
./old 1.46s user 0.00s system 99% cpu 1.461 total
$ time ./new
./new 0.68s user 0.00s system 99% cpu 0.682 total
$ time ./new
./new 0.70s user 0.01s system 99% cpu 0.703 total
$ time ./new
./new 0.70s user 0.00s system 99% cpu 0.705 total
$ time ./new
./new 0.70s user 0.00s system 99% cpu 0.703 total
I say non-conclusive, because:
1) my CPU is probably doing branch prediction and may possibly be doing
out-of-order execution. Since it has more integer units that floating
point units, this would work in the favour of integers. The contention
case described by the original poster does not allow for multiple
integer units to be in use at the same time.
2) as Tom has already said, 100 million divides in either 0.7 seconds or
1.5 seconds, is still orders of magnitude more than the contended case
would ever be called.
For the future, please consider doing integer division when working with
integers and the rvalue is a constant. For this case, it doesn't seem
like it is worth it to risk breaking the code.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That would be a good idea, and really simply things ... FreeBSD seems to have drop'd off support for all but 2.13 and 2.61 ... If we do that, (I honestly don't know) what happens on versions that are running an older version of autoconf? I mean, if everything is put together with 2.61, are 2.59 versions going to have an issue? Joshua D. Drake - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPShG4QvfyHIvDvMRAm48AJ9D7FOT0EyASLJuBmxeLbE+464HdgCg54fJ xQOk7rf3xBmwEreHKzlk3C4= =6M0k -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: update files for beta3
Andrew Dunstan [EMAIL PROTECTED] writes: We are making a mountain out of a molehill here. We've managed to get this right for years with very little fuss. Why make infrastructure to handle a problem that is at most marginal? I have more pressing concerns that building an autoconf step into buildfarm. I think that trying to get configure.in to work with arbitrary versions of autoconf is probably not a very useful expenditure of time, anyway. What we *do* need is some way of checking whether the right autoconf version was used in any particular branch; right now we simply rely on committers to get it right, and it's an easy thing to mess up. Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Andrew Dunstan wrote: (And I share Tom's concern about version compatibility - the autoconf team don't have a great record on that IIRC.) Thats why I think it might be useful to keep an eye on what does and doesn't work. I agree it's not a major issue though, so if it's non-trivial to implement then there's no point persuing the idea. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 18:00:26 + Dave Page [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? If the first thing some of them do is re-run autoconf, then we should get test results for a variety of versions as found on various distros. We would then be able to tell which versions may or may not work which could help us when we need to upgrade, or if someone has problems with a specific version when hacking (which should be rare I appreciate). Ah, okay, you are going for the 'remove pre-built configure from cvs' route .. that works too, and does make sense ... wouldn't definitely make sure we get broad coverage ... No, I wouldn't remove it - leave it there for some BF members, but have others regenerate it just for test purposes. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... Locally I've got several autoconf versions installed so that I can update back-branch configure scripts properly. It'd probably be a good idea to improve your release scripts so that they select the right autoconf version for each release branch. You'll need multiple local installations though, instead of depending on freebsd ports for the one true autoconf. Either that or we try to move up all supported back branches to the latest autoconf version; which might be a good idea but it scares me a bit. I say have a VMWare instance running with the one true autoconf that is currently accepted. That way we don't have to make that distinction. Autoconf 2.59 is going to be predominantly in the wild (rhel 5, centos5 , dapper, debian) for at least another 3-4 years. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? Yes: diff -ur ../cvs-pgsql/configure.in ./configure.in --- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.0 +0100 +++ ./configure.in 2007-11-16 22:27:36.0 +0100 @@ -19,7 +19,7 @@ AC_INIT([PostgreSQL], [8.3beta3], [EMAIL PROTECTED]) -AC_PREREQ(2.59) +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version 2.59 is required])]) AC_COPYRIGHT([Copyright (c) 1996-2007, PostgreSQL Global Development Group]) AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c]) AC_CONFIG_AUX_DIR(config) This appears to work with 2.53, 2.59, and 2.61, which are the ones that affect us at the moment. I can backpatch this all the way to 7.3 if desired. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Dave Page wrote: Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? Maybe the BF members could just run their default autoconf as part of the build if they have one. We are making a mountain out of a molehill here. We've managed to get this right for years with very little fuss. Why make infrastructure to handle a problem that is at most marginal? I have more pressing concerns that building an autoconf step into buildfarm. (And I share Tom's concern about version compatibility - the autoconf team don't have a great record on that IIRC.) cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] [pgtranslation-translators] Call for translations
Alvaro Herrera wrote: I would like to propose this patch. This avoids an inconsistent message wording, and removes the need to translate a string by duplicate. That's fine by me. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? Yes: Excellent. This appears to work with 2.53, 2.59, and 2.61, which are the ones that affect us at the moment. I can backpatch this all the way to 7.3 if desired. Please. regards, tom lane ---(end of broadcast)--- TIP 1: 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] [GENERAL] [pgtranslation-translators] Call for translations
Peter Eisentraut wrote: Alvaro Herrera wrote: I would like to propose this patch. This avoids an inconsistent message wording, and removes the need to translate a string by duplicate. That's fine by me. Done. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 I think my standards have lowered enough that now I think 'good design' is when the page doesn't irritate the living f*ck out of me. (JWZ) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. One idea people might suggest is to stop keeping the generated configure script in CVS. I'm not sure that'd make things better though. We'd be buying into the concept of trying to make configure.in work with any autoconf version any developer might be likely to use. I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. regards, tom lane ---(end of broadcast)--- TIP 1: 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] Javascript support in the backend, i.e. PL/JS
On Fri, Nov 16, 2007 at 09:49:38AM +0100, Andreas Joseph Krogh wrote: Most people, as you probably know, don't like JS as a language 'cause they think of it as a web-browser language with lots of bad side-effects, but that's 'cause they don't know the language, really. Javascript is a very nice little language. There are a few weirdos (the treatment of NULLs I noted before being one of them) but amazingly few of them considering that's it's a scripting language. I think it's had some amazingly good effects hasn't it? There all sort of cool things happening in web browsers (quite a few of them shouldn't happen there, but that's beside the point) that build on Javascript. I'd love to see something like Caja[1] actually getting somewhere---I have a lot of respect for the people behind it and it would be very cool if it managed to break into the mainstream at some point. Some of you may have heard my rants (mainly on #postgresql) about object-capability security. It's from there that I thought it would be good to have spi come in through a parameter, if you have subscripts that you don't want to touch your database then just don't pass them a reference to the spi object and they won't be able to. Likewise, IMMUTABLE functions probably shouldn't get the spi parameter in the first place. JS actually has some nice programming concepts and being able to use it as an SP seems pretty attractive. Keep up the good work! SP? I hope my code will get useful some point soon. Sam [1] http://code.google.com/p/google-caja/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] [solved] strange tuple from ExecutorRun
Hello It was my bug :(. I forgot increase resno. Classic situation. When you are search bug, search elsewhere. Regards Pavel Stehule ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Javascript support in the backend, i.e. PL/JS
On Friday 16 November 2007 12:23:26 Sam Mason wrote: On Fri, Nov 16, 2007 at 12:05:02PM +0100, Andreas Joseph Krogh wrote: On Friday 16 November 2007 11:29:09 Sam Mason wrote: [snip] SP? Stored Procedure That was kind of obvious wasn't it! I failed to parse that because of the an before it; an stored procedure doesn't make much sense! English is a great language isn't it. :) Yea, I wrote an 'cause I pronounce it ess pee... -- Andreas Joseph Krogh [EMAIL PROTECTED] Senior Software Developer / Manager +-+ OfficeNet AS| The most difficult thing in the world is to | Karenslyst Allé 11 | know how to do a thing and to watch | PO. Box 529 Skøyen | somebody else doing it wrong, without | 0214 Oslo | comment.| NORWAY | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ ---(end of broadcast)--- TIP 6: explain analyze is your friend
