Re: [HACKERS] LGPL
On Saturday 18 June 2005 01:43, Gregory Maxwell wrote:
On 6/18/05, Tom Lane [EMAIL PROTECTED] wrote:
... But is it really the case that PostgreSQL developers are being
paid to code because PG is BSDed and proprietary forks are possible?
... There is no harm in being BSDed, but I question that the users of
PostgreSQL are gaining enough advantage that there needs to be so much
paranoia about making sure that the code is as easy as possible to
make propritary forks of...
SRA, Greenplumb, and EnterpriseDB are just three of the companies that both
subsidize development and release non-bsd/proprietary versions of PostgreSQL.
You can bet they wouldn't be so quick to work with us if we weren't BSD
licensed. The community benefits greatly from our BSD license, and IMHO it
is the central factor that will eventually allow postgresql to achive total
world domination ;-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend)
On Saturday 18 June 2005 01:36, Tom Lane wrote:
Dave Page dpage@vale-housing.co.uk writes:
Personally I prefer the first or last, as default implies to me that
it's a kindof general use database - which, as Tom points out it could
be, however I think it's better to encourage users to only use it as
directed by tool providers, and not for general purpose.
If that is what you want then the database should surely not become the
default connection target for clients.
The proposal I thought was being made was that we separate the
default-connection-target property from the default-CREATE-DATABASE-source
property. This business about where tool authors can dump random junk
of their own devising does not seem to me to fit at all with either of
those properties. I think what you are really asking for is yet another
standard database named something like TOOLS_ONLY_KEEP_OUT.
But I do not see the argument for having that created by default,
because any tool that is capable of creating random junk is surely
capable of creating a database to put it in. Furthermore, if it's
created by default and completely unused in the default installation,
lots of DBAs will immediately drop it --- so I entirely fail to see
the argument that tools could expect it to be there without any
expenditure of their own effort.
I still say the most that's needed here is some agreement among tool
authors about a common choice of database name to create if their tool
is installed.
I was gradually drifting toward this idea. Do we really need the blessing of
the postgresql core to make this happen? ISTM we don't. Right now we
(phppgadmin) already tell users that, if they want to make use of our
reports functionality, they must create a phppgadmin database that also
creates a table to hold the report information; a script is provided to help
ease this setup requirement.
But what if we all just agreed that we would use a common database called
pg_addons, and that each tool would install thier information into an
appropriatly named schema within that database; phppgadmin for us, pgadminiii
for pgadmin for examples. This means that, if you install pgadmin, it
creates this database and puts its information into its own schema. If you
then wanted phppgadmin reporting, we'd look for this database and, since it
exists, we'd just install our needed information into a phppgadmin schema
within that database. Any other addons/tool makers out there that wanted to
jump on the bandwagon could do so, just by following this basic agreement.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] LGPL
Tom Lane wrote: What is important is that it is possible, and useful, to build Postgres in a completely non-GPL environment. If that were not so then I think we'd have some license issues. But the fact that building PG in a GPL-ized environment creates a GPL-ized binary is not a problem from my point of view. You've already bought into the GPL if you're using that environment. So, is there an effort to not require GNU make then ? Peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend)
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Sat 6/18/2005 6:36 AM To: Dave Page Cc: Andreas Pflug; Christopher Kings-Lynne; Magnus Hagander; Josh Berkus; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend) The proposal I thought was being made was that we separate the default-connection-target property from the default-CREATE-DATABASE-source property. This business about where tool authors can dump random junk of their own devising does not seem to me to fit at all with either of those properties. I think what you are really asking for is yet another standard database named something like TOOLS_ONLY_KEEP_OUT. Keeping people out of template1 is my major concern, however it seemed like a good way to kill 2 birds with one stone and solve both problems at once. I'll knock up a patch to create a database called 'default' at initdb time given that that appears to be the only name with more than one person backing it. We (the tool makers), can argue over whether we will use it, or pg_addons (as Robert has suggested) later. In some ways perhaps it would be better to keep them seperate - the first db a real first-time-newbie will see is 'default', so perhaps having lots of tool data where he might fiddle is not such a good idea. Any objections (he says, looking for a smooth patch-CVS before 8.1 :-) )? Regards, Dave ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend)
I was gradually drifting toward this idea. Do we really need the blessing of the postgresql core to make this happen? ISTM we don't. I think not, but I would perhaps make things easier ;-) But what if we all just agreed that we would use a common database called pg_addons, and that each tool would install thier information into an appropriatly named schema within that database; phppgadmin for us, pgadminiii for pgadmin for examples. This means that, if you install pgadmin, it creates this database and puts its information into its own schema. If you then wanted phppgadmin reporting, we'd look for this database and, since it exists, we'd just install our needed information into a phppgadmin schema within that database. Any other addons/tool makers out there that wanted to jump on the bandwagon could do so, just by following this basic agreement. Seems reasonable. The only argument agains it vs having it in the default (whatevr it's named) database is that you'll have two more databases. But with them coming in at 5-6Mb (I think it was), I don't see that as a big problem. It has to be documented somewhere though, so new tool vendors know how to create it. You'll get in a lot of trouble if it starts showing up with different encodings depending on which tool created it, for example. But that should be easy enough. //Magnus ---(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] Utility database (Was: RE: Autovacuum in the backend)
Magnus Hagander wrote: I was gradually drifting toward this idea. Do we really need the blessing of the postgresql core to make this happen? ISTM we don't. I think not, but I would perhaps make things easier ;-) But what if we all just agreed that we would use a common database called pg_addons, and that each tool would install thier information into an appropriatly named schema within that database; phppgadmin for us, pgadminiii for pgadmin for examples. This means that, if you install pgadmin, it creates this database and puts its information into its own schema. If you then wanted phppgadmin reporting, we'd look for this database and, since it exists, we'd just install our needed information into a phppgadmin schema within that database. Any other addons/tool makers out there that wanted to jump on the bandwagon could do so, just by following this basic agreement. Seems reasonable. The only argument agains it vs having it in the default (whatevr it's named) database is that you'll have two more databases. But with them coming in at 5-6Mb (I think it was), I don't see that as a big problem. It has to be documented somewhere though, so new tool vendors know how to create it. You'll get in a lot of trouble if it starts showing up with different encodings depending on which tool created it, for example. But that should be easy enough. I just posted a patch for an initdb time default db creation, with public creation rights removed. I'm still unhappy about that name (though I understand Tom, psql localhost default looks good), but I consider the default db a system db, so it wouldn't shown up in pgAdmin unless explicitely enabled and users would be kept out. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Returning Composite Types from C functions
Hi all,
CREATE TYPE my_type AS (
a int,
b int,
c int,
d int,
e int
);
CREATE FUNCTION text_to_my_type(text)
RETURNS my_type
AS 'my_lib.so'
LANGUAGE 'C' IMMUTABLE STRICT;
CREATE CAST (text AS my_type) WITH FUNCTION text_to_my_type (text);
SELECT ('1:2:3:4:5'::text::my_type).*;
This results in the text_to_my_type(text) function being called no less
than 5 times. Once for each element.
Is this the desired behaviour, or a bug?
---(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] Returning Composite Types from C functions
On Sat, Jun 18, 2005 at 09:18:34PM +1000, John Hansen wrote:
SELECT ('1:2:3:4:5'::text::my_type).*;
This results in the text_to_my_type(text) function being called no less
than 5 times. Once for each element.
Is this the desired behaviour, or a bug?
It's a known behavior with functions that return composite types.
Apparently it's not easy to fix:
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00971.php
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Returning Composite Types from C functions
Michael Fuhr [mailto:[EMAIL PROTECTED] Wrote:
Sent: Saturday, June 18, 2005 9:56 PM
To: John Hansen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Returning Composite Types from C functions
On Sat, Jun 18, 2005 at 09:18:34PM +1000, John Hansen wrote:
SELECT ('1:2:3:4:5'::text::my_type).*;
This results in the text_to_my_type(text) function being called no
less than 5 times. Once for each element.
Is this the desired behaviour, or a bug?
It's a known behavior with functions that return composite types.
Apparently it's not easy to fix:
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00971.php
There is a workaround tho, so should be fixable:
SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS b) AS a;
Or am I missing something?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
... John
---(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] Utility database
On Fri, 17 Jun 2005, Andrew Dunstan wrote: Thus, sys_shared, def_share, user_commons are all sorts of names that suggest that this is some sort of default/shared area. I like the first. The second and third seem less obvious to me. 'default_shared' should definitely get the point across, though it's a little long. It strikes me that these names just might have some significance to developers but will have none at all for users. I don't heve a better alternative ... maybe because the purpose has been expressed somewhat fuzzily. It seems that far and away the most common use of this database will be as the default database to connect to with any of the client apps. Thus Tom's suggestion of default makes the most sense to me. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ ---(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] LGPL
Peter Galbavy [EMAIL PROTECTED] writes: So, is there an effort to not require GNU make then ? No, that's not relevant. GNU make is a tool, not part of the end result. A more interesting question is Autoconf, which we also depend on as a build tool, and which does copy parts of itself into the distributed product. However, Autoconf explicitly releases its output scripts as entirely free software, not GPL code. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Returning Composite Types from C functions
On Sat, Jun 18, 2005 at 10:03:38PM +1000, John Hansen wrote:
There is a workaround tho, so should be fixable:
SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS b) AS a;
Or am I missing something?
I don't know enough about PostgreSQL internals so I'll have to defer
to the developers. But here's a case where the above workaround
doesn't work -- in my tests, the cast function is called once per
column per row, or ten times:
CREATE TABLE foo (t text);
INSERT INTO foo VALUES ('1:2:3:4:5');
INSERT INTO foo VALUES ('6:7:8:9:10');
SELECT (a.b).* FROM (SELECT t::my_type AS b FROM foo) AS a;
What do you get? Can you think of a workaround for this case?
Maybe one of the developers can comment on why your example calls
the function only once and mine calls it multiple times per row,
even though they look similar.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Returning Composite Types from C functions
John Hansen [EMAIL PROTECTED] writes:
There is a workaround tho, so should be fixable:
SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS b) AS a;
Or am I missing something?
Try it ;-)
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: [HACKERS] Returning Composite Types from C functions
Yes, it worked for me,...
But my point is the workaround shouldn't be nescessary
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 18, 2005 11:36 PM
To: John Hansen
Cc: Michael Fuhr; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Returning Composite Types from C functions
John Hansen [EMAIL PROTECTED] writes:
There is a workaround tho, so should be fixable:
SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS
b) AS a;
Or am I missing something?
Try 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] Returning Composite Types from C functions
John Hansen [EMAIL PROTECTED] writes:
SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS
b) AS a;
Or am I missing something?
Try it ;-)
Yes, it worked for me,...
It depends on your test case, but in many situations the planner will
flatten that into the same result as the other. The basic problem is
that (foo).* is expanded to (foo).f1, (foo).f2, ... which is OK if
foo is just a variable referring to a subquery output --- but if the
subquery gets flattened into the parent then your function appears
textually multiple times in the resulting query.
There's been some discussion of disabling flattening when the subquery
output targetlist contains any volatile functions, but that seems like
rather a performance-losing answer. It doesn't completely address the
complaint anyway since even a non-volatile function might be expensive
to compute.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] default database creation with initdb
[ redirected back to hackers, since it seems this is far from a finished discussion ] Robert Treat [EMAIL PROTECTED] writes: What is the purpose of this database? A generalized, shared resource for tool makers and add-on packages to store information in PostgreSQL, or a working database that is usable (and to be used) out of the box for new users? I really don't think we want the latter... I can see users connecting via psql and then playing around with different add/create type statements. It is all too common a question from newbies... does postgresql have a default database to get started with? They'll see this database and begin creating schema and using this as thier main database, and I think we ought to avoid that. If people don't like pg_system, pg_addons seem like a much safer name to go with imho. pg_addons or pg_tools or something like that seems like a fine name *for the purpose of a tools-only database* ... but that is only one of the issues being tossed around here. To me the much more interesting aspect of this is reducing the extent to which template1 is serving multiple not-very-compatible purposes. I like the idea of a default database because it would eliminate two perennial issues: * newbies mistakenly cluttering template1 with junk * CREATE DATABASE failing because there are other connections to the template database. To be newbie-friendly, such a default database *should* be writable, I think. The whole point is to let people play without having to learn how to create a database first. If they clutter it up, so what? They can always drop it and recreate it --- there won't be anything at all special about it. (Thus, Andreas' desire to have it be considered a system object seems misplaced to me.) This vision immediately brings up another issue: for most client tools the default database-to-connect-to is *not* template1, it is the database named after the connecting user. If we invent a default database, should we change things to remove the username dependence and always connect to default by default? I think you could argue this either way --- it may be too much of a non-backwards-compatible change, but if we were designing the behavior in a green field today, I suspect that's what we'd make it do. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Escape handling in strings
On Friday 17 June 2005 08:55, Bruce Momjian wrote:
Michael Glaesemann wrote:
On Jun 17, 2005, at 4:34 PM, Greg Stark wrote:
And for an app issuing
hundreds or thousands of queries per minute (or even second) a
warning could
effectively be a showstopper. It could require disabling all
warnings in their
config to avoid filling their disk with Postgres logs in minutes.
Good point.
I would suggest this warning be disable-able with a GUC variable.
Otherwise
you're effectively giving no advance warning time to those users.
Perhaps NOTICE would be better, at least for the first step? People
might be more comfortable with that, as using backslash escaping
isn't really going to cause problems with this particular version,
but rather for future versions.
I am thinking changing the level of the message isn't going to help
people much because it still displays and fills up the server logs.
If postgres keeps advancing at the pace it's advancing now I might
suggest
waiting two release cycles instead of just one.
How's this for an idea?
Step 1 (8.1) NOTICE level (or some other level, lower than WARNING),
E'' and \' are available
Step 2 (8.2?) WARNING level, E'' and \' are available
Step 3 (8.3? 8.4?) E'' available, plain '' interpreted literally.
Right now I am thinking we would have the warning available in 8.1, but
not turn it on by default. Perhaps we can tell users to enable the
warning at some time during 8.1 so they are ready for it in 8.2.
I think it is worth restating in stronger language, the potential overhead of
raising notices or warning in such a large number of queries will be an
upgrading show stopper for some people. (To the extent that for some, the
release where this is a mandatory warning will be as much a show stopper as
the release where the behavior is changed)
IMHO we need at least 1 release with a GUC to control the warning (defaulting
off initial, if people want the next release to default on, thats ok, but is
probably a waste), so that people can turn it on/off in order to debug thier
applications and make them compliant for upgrading to the next version. It
doesnt much matter to me where you put this... 8.0.x, 8.1... it's just a
question of where do you want to create a roadblock to upgrading, because the
release where you force the warning always on your going to have raised the
barrier to entry too high for some people.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Escape handling in strings
Robert Treat wrote: I think it is worth restating in stronger language, the potential overhead of raising notices or warning in such a large number of queries will be an upgrading show stopper for some people. (To the extent that for some, the release where this is a mandatory warning will be as much a show stopper as the release where the behavior is changed) IMHO we need at least 1 release with a GUC to control the warning (defaulting off initial, if people want the next release to default on, thats ok, but is probably a waste), so that people can turn it on/off in order to debug thier applications and make them compliant for upgrading to the next version. It doesnt much matter to me where you put this... 8.0.x, 8.1... it's just a question of where do you want to create a roadblock to upgrading, because the release where you force the warning always on your going to have raised the barrier to entry too high for some people. The GUC will always be around to turn the warning on or off, until we go with standard SQL strings, at which point there will be no warnings generated. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Returning Composite Types from C functions
Michael Fuhr [EMAIL PROTECTED] writes: Maybe one of the developers can comment on why your example calls the function only once and mine calls it multiple times per row, even though they look similar. Look at the EXPLAIN results --- one case gets flattened into a single plan node and the other doesn't. I know exactly where that particular skeleton is buried, too: /* * Hack: don't try to pull up a subquery with an empty jointree. * query_planner() will correctly generate a Result plan for a * jointree that's totally empty, but I don't think the right things * happen if an empty FromExpr appears lower down in a jointree. Not * worth working hard on this, just to collapse SubqueryScan/Result * into Result... */ if (subquery-jointree-fromlist == NIL) return false; regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] LGPL
On Sat, Jun 18, 2005 at 08:43:01 +0100, Peter Galbavy [EMAIL PROTECTED] wrote: Tom Lane wrote: What is important is that it is possible, and useful, to build Postgres in a completely non-GPL environment. If that were not so then I think we'd have some license issues. But the fact that building PG in a GPL-ized environment creates a GPL-ized binary is not a problem from my point of view. You've already bought into the GPL if you're using that environment. So, is there an effort to not require GNU make then ? Neither using GNU make or gcc make to buld a binary make the resulting binary bound by the GPL. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] process crash when a plpython function returns unicode
I've moved this thread from pgsql-bugs to pgsql-hackers; here are the original messages: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php http://archives.postgresql.org/pgsql-bugs/2005-06/msg00107.php As I mentioned in my followup to the bug report, a simple fix would appear to be to check for a NULL return value from PyObject_Str() before calling PyString_AsString() at the following location: /* Lines 776-77 in plpython.c */ plrv_so = PyObject_Str(plrv); plrv_sc = PyString_AsString(plrv_so); I was going to submit a patch, but I don't know enough about the Python API or how Python and PostgreSQL handle Unicode to know whether adding that simple check is the appropriate solution (I was planning to raise an error if PyObject_Str() returned NULL). Can anybody think of a better fix? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] default database creation with initdb
Am Samstag, den 18.06.2005, 10:12 -0400 schrieb Tom Lane: [ redirected back to hackers, since it seems this is far from a finished discussion ] ... pg_addons or pg_tools or something like that seems like a fine name *for the purpose of a tools-only database* ... but that is only one of the issues being tossed around here. To me the much more interesting aspect of this is reducing the extent to which template1 is serving multiple not-very-compatible purposes. I like the idea of a default database because it would eliminate two perennial issues: * newbies mistakenly cluttering template1 with junk * CREATE DATABASE failing because there are other connections to the template database. To be newbie-friendly, such a default database *should* be writable, I think. The whole point is to let people play without having to learn how to create a database first. If they clutter it up, so what? They can always drop it and recreate it --- there won't be anything at all special about it. (Thus, Andreas' desire to have it be considered a system object seems misplaced to me.) This vision immediately brings up another issue: for most client tools the default database-to-connect-to is *not* template1, it is the database named after the connecting user. If we invent a default database, should we change things to remove the username dependence and always connect to default by default? I think you could argue this either way --- it may be too much of a non-backwards-compatible change, but if we were designing the behavior in a green field today, I suspect that's what we'd make it do. Looks like 2 entirely different targets. So the only solution I see would 2 databases created by default: 1 tooldb or systemdb or whatever a good name there is for the tools to store their information 1 default DB (which could be optional? or initdb asks interactively? or psql/tools output a hint to create one?) If thats too much I think it could really be considered to stop connections to template0 (as to avoid clutter here) but allow it as default template for new databases. Which seems more consistent imho. (And so it would make template1 optional) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] process crash when a plpython function returns
Am Samstag, den 18.06.2005, 08:41 -0600 schrieb Michael Fuhr: I've moved this thread from pgsql-bugs to pgsql-hackers; here are the original messages: http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php http://archives.postgresql.org/pgsql-bugs/2005-06/msg00107.php As I mentioned in my followup to the bug report, a simple fix would appear to be to check for a NULL return value from PyObject_Str() before calling PyString_AsString() at the following location: /* Lines 776-77 in plpython.c */ plrv_so = PyObject_Str(plrv); plrv_sc = PyString_AsString(plrv_so); I was going to submit a patch, but I don't know enough about the Python API or how Python and PostgreSQL handle Unicode to know whether adding that simple check is the appropriate solution (I was planning to raise an error if PyObject_Str() returned NULL). Can anybody think of a better fix? raise error would be a correct solution since this is what python does in this case: http://docs.python.org/api/exceptions.html also in this context it would be helpful if sys.defaultencoding would be set to the database encoding so strings get encoded to utf-8 when postgres works in unicode mode rather then the default encoding of ascii. This could avoid most of the PyObject_Str() exeptions in the first place. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] pg_locks view versus prepared transactions
Now that Heikki's two-phase-commit patch is in, we have a bit of a problem in the pg_locks view: prepared transactions can hold locks, but you can't tell which prepared transaction is holding which lock. They all show with pid 0. (This should probably come out as a NULL instead of 0, but I didn't change it yet.) I think the minimum thing we ought to do about this is add an XID column to pg_locks to show the transaction ID holding each lock. Then you could join that to pg_prepared_xacts to see what's what. I was also wondering about adding a current-XID column to pg_stat_activity, and encouraging people to join pg_locks and pg_stat_activity on XID instead of PID. Ultimately we should maybe even remove PID from pg_locks, but probably for backwards compatibility it'd have to be deprecated for a release or two first. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two-phase commit
While cleaning out old mail about two-phase commit, I noticed this thought from Oliver: Oliver Jowett [EMAIL PROTECTED] writes: Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back? That sounds very dangerous to me. You could end up breaking global atomicity if some other resource in the global transaction committed. Right. You wouldn't enable it lightly.. If pg_prepared_xacts had a time-of-preparation column, it would be possible to put the timeout policy in an external client. Perhaps that's a better solution? This seems like a good idea to me in any case --- barring objections, I will add this to the data structures and view. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Login/logout
Hello all I want to register in an audit table the date and time of the login/logout of a database user. I have been looking for some function in the code but I didn't find something like that. Can you give me some ideas to implement it?. I'm ready to program if it is necessary. Thanks in advance, regards Juan P. Espino ---(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] Login/logout
On Sat, Jun 18, 2005 at 11:11:31AM -0500, Juan Pablo Espino wrote: I want to register in an audit table the date and time of the login/logout of a database user. I have been looking for some function in the code but I didn't find something like that. Are you interested in logging to a table specifically, or are you just trying to get the login/logout info? If the latter, then you can use log_connections and log_disconnections (the second of which is available in 8.0 and later). http://www.postgresql.org/docs/8.0/static/runtime-config.html#RUNTIME-CONFIG-LOGGING-WHAT -- 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] Login/logout
Thanks for the quick response. Yes I want to retrieve the login/logout info, but I want to insert this info in a table that I use as an audit table. Regards Juan P. Espino On 6/18/05, Michael Fuhr [EMAIL PROTECTED] wrote: On Sat, Jun 18, 2005 at 11:11:31AM -0500, Juan Pablo Espino wrote: I want to register in an audit table the date and time of the login/logout of a database user. I have been looking for some function in the code but I didn't find something like that. Are you interested in logging to a table specifically, or are you just trying to get the login/logout info? If the latter, then you can use log_connections and log_disconnections (the second of which is available in 8.0 and later). http://www.postgresql.org/docs/8.0/static/runtime-config.html#RUNTIME-CONFIG-LOGGING-WHAT -- 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] LGPL
So, is there an effort to not require GNU make then ? Neither using GNU make or gcc make to buld a binary make the resulting binary bound by the GPL. That is correct because all (well most) of the libraries used by GCC are LGPL not GPL. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two-phase commit
Tom Lane wrote: While cleaning out old mail about two-phase commit, I noticed this thought from Oliver: Oliver Jowett [EMAIL PROTECTED] writes: Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back? That sounds very dangerous to me. You could end up breaking global atomicity if some other resource in the global transaction committed. Right. You wouldn't enable it lightly.. If pg_prepared_xacts had a time-of-preparation column, it would be possible to put the timeout policy in an external client. Perhaps that's a better solution? This seems like a good idea to me in any case --- barring objections, I will add this to the data structures and view. I am a little confused by the use of the term prepared in terms of 2-phase commit vs. prepared queries. Is there a way to make the wording clearer? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Login/logout
On Sat, 2005-06-18 at 11:46 -0500, Juan Pablo Espino wrote: Thanks for the quick response. Yes I want to retrieve the login/logout info, but I want to insert this info in a table that I use as an audit table. Regards I suggest putting together a short script to scan the logs periodically and add the new entries to your table. On 6/18/05, Michael Fuhr [EMAIL PROTECTED] wrote: On Sat, Jun 18, 2005 at 11:11:31AM -0500, Juan Pablo Espino wrote: I want to register in an audit table the date and time of the login/logout of a database user. I have been looking for some function in the code but I didn't find something like that. Are you interested in logging to a table specifically, or are you just trying to get the login/logout info? If the latter, then you can use log_connections and log_disconnections (the second of which is available in 8.0 and later). http://www.postgresql.org/docs/8.0/static/runtime-config.html#RUNTIME-CONFIG-LOGGING-WHAT -- 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 -- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)
Oh-ho, I see it:
(gdb) bt
#0 0x4489fba4 in memcpy () from /usr/lib/libc.so.34.2
#1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90,
action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653
#2 0x003434f0 in pg_tzset (name=0xa5ff90 PST8PDT) at pgtz.c:1039
#3 0x001fbcf0 in assign_timezone (value=0xa5ff90 PST8PDT,
doit=1 '\001', source=PGC_S_CLIENT) at variable.c:351
...
(gdb) f 1
#1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90,
action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653
653 memcpy(ELEMENTKEY(currBucket), keyPtr,
hctl-keysize);
(gdb) p *hctl
$1 = {dsize = 256, ssize = 256, sshift = 8, max_bucket = 31, high_mask = 63,
low_mask = 31, ffactor = 1, nentries = 1, nsegs = 1, keysize = 255,
entrysize = 11064, max_dsize = -1, freeList = 0xaca758}
(gdb) p keyPtr
$2 = (const void *) 0xa5ff90
(gdb) x/255c 0xa5ff90
0xa5ff90: 80 'P' 83 'S' 84 'T' 56 '8' 80 'P' 68 'D' 84 'T' 0 '\0'
0xa5ff98: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffa0: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffa8: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffb0: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffb8: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffc0: 80 'P' 111 'o' 115 's' 116 't' 103 'g' 114 'r' 101 'e' 115 's'
0xa5ffc8: 44 ',' 32 ' ' 77 'M' 68 'D' 89 'Y' 0 '\0' 0 '\0' 0 '\0'
0xa5ffd0: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffd8: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffe0: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5ffe8: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa5fff0: 36 '$' 108 'l' 105 'i' 98 'b' 100 'd' 105 'i' 114 'r' 0 '\0'
0xa5fff8: 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0' 0 '\0'
0xa6: Cannot access memory at address 0xa6
(gdb)
dynahash.c thinks it should always copy 255 bytes of key, since that's
what it was told the key size was ... but in this case the supplied
search key has been allocated very close to the end of the process's
memory, and there are not 255 bytes before the end of memory.
I'm surprised we have not seen cases like this reported before, because
the risk has been there since at least PG 7.4 (or whenever we started
allowing un-padded C strings as dynahash keys). Will fix.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)
Tom Lane wrote: dynahash.c thinks it should always copy 255 bytes of key, since that's what it was told the key size was ... but in this case the supplied search key has been allocated very close to the end of the process's memory, and there are not 255 bytes before the end of memory. aaah - this description rings a bell ... OpenBSD has some very useful features for configuration of malloc() - and on this particular box it has: G ``Guard''. Enable guard pages and chunk randomization. Each page size or larger allocation is followed by a guard page that will cause a segmentation fault upon any access. Smaller than page size chunks are returned in a random order. and indeed - enabling G on another (x86) OpenBSD box of mine causes make check to die there too Stefan ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Checkpointing problem with new buffer mgr.
Tom, folks, I'm continuing to see a problem with checkpointing and clock-sweep. Previously I thought that it was just the long checkpoint intervals on the standard DBT2 test, but things get worse when you checkpoint more frequently: 60 minute checkpoint: http://khack.osdl.org/stp/302458/results/0/ (look at the first chart) Here you can see the huge dive in performance when the checkpoint hits. Without it, our test scores would average 2000 notpm, better than Oracle on low-end hardware like this. Every 5 minutes: http://khack.osdl.org/stp/302656/results/0/ (again, look at the notpm chart) First off, note that the average NOTPM is 1320, which is a 20% decrease from 8.0.2.Second, you can see that the checkpoint spikes go just as low as they do in the 60minute test. But, it appears that under the new buffer manager, Postgres now needs 10 minutes or more of heavy activity to recover from a checkpoint. So this is obviously a major performance problem. It could be fixed by turning off checkpointing completely, but I don't think that's really feasable. Any clue on why clock-sweep should be so slammed by checkpoints? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Lane wrote: dynahash.c thinks it should always copy 255 bytes of key, since that's what it was told the key size was ... but in this case the supplied search key has been allocated very close to the end of the process's memory, and there are not 255 bytes before the end of memory. aaah - this description rings a bell ... OpenBSD has some very useful features for configuration of malloc() - and on this particular box it has: G ``Guard''. Enable guard pages and chunk randomization. Each page size or larger allocation is followed by a guard page that will cause a segmentation fault upon any access. Smaller than page size chunks are returned in a random order. and indeed - enabling G on another (x86) OpenBSD box of mine causes make check to die there too Cool. Once I get this bug fixed, the people running openbsd build farm machines probably should turn that on as standard practice ... we've found bugs of this ilk several times before, and I would not be surprised if there are more. The palloc mechanism probably does quite a lot to mask this type of error, since it aggregates small chunk requests into large malloc chunks. If you read past the end of a palloc'd chunk it's quite unlikely that you'll see a problem. I wonder if it is worth having a debug-build option that defeats that somehow ... 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] Login/logout
Hi, thanks for the response. On 6/18/05, Rod Taylor [EMAIL PROTECTED] wrote: On Sat, 2005-06-18 at 11:46 -0500, Juan Pablo Espino wrote: Thanks for the quick response. Yes I want to retrieve the login/logout info, but I want to insert this info in a table that I use as an audit table. Regards I suggest putting together a short script to scan the logs periodically and add the new entries to your table. It sounds to me good in order to resolve my problem. Nevertheless I think that it would be very useful to have a function that does something like select login() and gives back to the date and time of login, or that we can retrieve that info from the system catalogs. Regards, Juan P. Espino ---(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] Utility database (Was: RE: Autovacuum in the backend)
Dave Page dpage@vale-housing.co.uk writes: Keeping people out of template1 is my major concern, however it seemed like a good way to kill 2 birds with one stone and solve both problems at once. FWIW here's a me too on keeping people out of template1 by default. I've more than once accidentally created objects in template1. A couple times I've actually restored an entire database in template1. And it's a bit of a pain to clean out if you have any objects you actually want there. I would agree with keeping things simple and naming it default. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pg_locks column names
In a moment of sheer brain fade I wrote: Log Message: --- Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about. But of course the transaction column of pg_locks is *not* new; I was momentarily confusing it with the ones that did get added recently. So this needs reconsideration. We need a column to identify the transaction holding/awaiting the lock, as well as one for the identity of a lock taken on a transaction ID. In a green field, I think the names I used in the patch would be good (transaction and transactionid respectively). The best backward- compatible names I can think of are xid and transaction, which aren't very attractive. Any better ideas? How important do you think it is to preserve the column name of this pg_locks column? 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] Checkpointing problem with new buffer mgr.
Josh Berkus josh@agliodbs.com writes: So this is obviously a major performance problem. It could be fixed by turning off checkpointing completely, but I don't think that's really feasable. Any clue on why clock-sweep should be so slammed by checkpoints? Hm, notice that the processor utilization doesn't actually drop all that much, so it seems it's not fundamentally an I/O storm kind of issue. I'm thinking that the issue may be that just after a checkpoint, each modification of a page incurs a dump of the whole page into WAL, with attendant CRC-calculation and other costs. The reason the long intercheckpoint interval yields such nifty performance is that it lets you ramp up into a regime where almost none of the pages being touched need to be dumped to WAL as a whole. Unfortunately that regime hasn't got a lot to do with reality ... You could test this theory by disabling the page-dump-out logic to see what happens to the performance curve. In CVS tip, look at XLogCheckBuffer() in src/backend/access/transam/xlog.c, and dike out the whole large if() in it --- just have it set *lsn and return false. (I assume this *is* CVS tip, or near to it? The recent CRC32 and omit-the-hole changes should affect the costs of this quite a bit.) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] buildfarm notifications
[from 2pc post mortem thread on -patches]
Stefan Kaltenbrunner wrote:
Looks suspicious, doesn't it. How long since you last tested on that
machine?
*argl* - it's not 2PC ...
the machine had some issues a week ago or so - but it looks like the
problem occured first here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2005-06-15%2023:50:04
and in that changeset we have some timezone-patches ...
If people don't monitor the buildfarm then it isn't serving its purpose
of catching these things quickly. To aid that process I am currently
working on a notification enhancement for buildfarm which has long been
requested. Here's the description I sent to the buildfarm list (the
first few lines refer to how buildfarm members would have themselves
notified - non-buildfarm members can ignore):
Basically, it would work thus:
in your config file, put a setting like this:
mail_events = { all= ['[EMAIL PROTECTED]', '[EMAIL PROTECTED]'}],
failures = '[EMAIL PROTECTED]' },
The allowed event keys in this hash would be:
all: every build status received
failures: every non-OK build status received
all_changes: every time status changes
green_changes: every time status changes to/from OK
The corresponding values in the hash can be an arrayref of email
addresses, or a single scalar email address.
The notification sent by the server would look something like this:
Subject: PGBuildfarm member membername Branch branchname Status
[changed to] status
The PGBbuildfarm member membername had the following event on branch
branch:
Status: status (or Status Change from oldstatus to newstatus)
The snapshot timestamp for the build that triggered this notification
is: -MM-DD HH::mm::ss
The specs of this machine are:
OS: osname osversion
Arch: architecture
Comp: compiler compiler-version
For more information, see
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=namebr=branch
--
In addition, I am thinking of setting up mailing lists that digest all
these event sets for all members over a 24 hour period, and that
anyone can subscribe to.
The enhancement is almost done, and the whole thing will be complete
this weekend, I hope.
The mailing lists are being set up as digest-only, at least for the all
and failures lists - the state change lists should have much lower
volume, and I will probably make them digest optional.
comments welcome (buildfarm exists to help people on this list - if you
want something speak up).
cheers
andrew
---(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] buildfarm notifications
Andrew Dunstan [EMAIL PROTECTED] writes: comments welcome (buildfarm exists to help people on this list - if you want something speak up). There are a number of buildfarm machines that don't seem to have *ever* posted a successful run. In some cases this represents a genuine portability issue but in others it looks more like local misconfiguration. Can we do something to encourage people to fix these? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: OpenBSD has some very useful features for configuration of malloc() - and on this particular box it has: G ``Guard''. Enable guard pages and chunk randomization. Each page size or larger allocation is followed by a guard page that will cause a segmentation fault upon any access. Smaller than page size chunks are returned in a random order. and indeed - enabling G on another (x86) OpenBSD box of mine causes make check to die there too Cool. Once I get this bug fixed, the people running openbsd build farm machines probably should turn that on as standard practice ... we've found bugs of this ilk several times before, and I would not be surprised if there are more. Stefan currently has the only openbsd members. However. I will probably add something to the buildfarm config file to turn on some of those options on openbsd. Can you please look at http://www.openbsd.org/cgi-bin/man.cgi?query=malloc.confapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html and tell us which ones you would like turned on? Stefan suggests A F and G might be useful. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)
Andrew Dunstan [EMAIL PROTECTED] writes: Can you please look at http://www.openbsd.org/cgi-bin/man.cgi?query=malloc.confapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html and tell us which ones you would like turned on? Stefan suggests A F and G might be useful. Not A please --- that's a pretty significant change in the behavior of malloc and would break code that expects to be able to tolerate out-of-memory conditions (which we do have, see palloc). F and G are good, also J, maybe P though I doubt that one's very significant. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] default database creation with initdb
Tom Lane wrote: [ redirected back to hackers, since it seems this is far from a finished discussion ] Robert Treat [EMAIL PROTECTED] writes: What is the purpose of this database? A generalized, shared resource for tool makers and add-on packages to store information in PostgreSQL, or a working database that is usable (and to be used) out of the box for new users? I really don't think we want the latter... I can see users connecting via psql and then playing around with different add/create type statements. It is all too common a question from newbies... does postgresql have a default database to get started with? They'll see this database and begin creating schema and using this as thier main database, and I think we ought to avoid that. If people don't like pg_system, pg_addons seem like a much safer name to go with imho. pg_addons or pg_tools or something like that seems like a fine name *for the purpose of a tools-only database* ... but that is only one of the issues being tossed around here. To me the much more interesting aspect of this is reducing the extent to which template1 is serving multiple not-very-compatible purposes. I like the idea of a default database because it would eliminate two perennial issues: * newbies mistakenly cluttering template1 with junk * CREATE DATABASE failing because there are other connections to the template database. To be newbie-friendly, such a default database *should* be writable, I think. The whole point is to let people play without having to learn how to create a database first. If they clutter it up, so what? They can always drop it and recreate it --- there won't be anything at all special about it. (Thus, Andreas' desire to have it be considered a system object seems misplaced to me.) This contradicts my intention to have users *not* to write to it, but reserve it for system like stuff. You might take everything that's not in postgres binary as non-system, but the average user's perception is different. Apparently we really need two initdb created databases for all purposes. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Login/logout - Utility Database
Juan Pablo Espino wrote: I want to register in an audit table the date and time of the login/logout of a database user. I have been looking for some function in the code but I didn't find something like that. This is the kind of functionality I'd expect to go to the pg_system (or however it is named) database if added in pgsql 9.x or so. Would you like to have auditing stuff mixed up with user data (e.g. in terms of backup)? Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm notifications
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: comments welcome (buildfarm exists to help people on this list - if you want something speak up). There are a number of buildfarm machines that don't seem to have *ever* posted a successful run. In some cases this represents a genuine portability issue but in others it looks more like local misconfiguration. Can we do something to encourage people to fix these? Yes. Thankyou for asking. Several of these have been inactive for quite a while, and I will mark those as retired after giving their owners due notice. Others I will chase up on a case by case basis. We've never been completely clean on anything before REL8_0_STABLE, so I'll be chasing the latest branches first. The obvious candidates are: sysname |branch | latest +---+- badger | HEAD | 2005-03-20 03:36:07 dove| HEAD | 2005-06-17 01:10:00 fantail | HEAD | 2004-12-06 23:04:43 muskrat | HEAD | 2005-01-10 22:16:41 osprey | HEAD | 2005-06-18 16:00:17 osprey | REL8_0_STABLE | 2005-06-17 22:00:17 penguin | REL8_0_STABLE | 2005-06-15 22:00:09 cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
