Re: [HACKERS] 8.5 release timetable, again
On sön, 2009-08-23 at 09:37 -0400, Robert Haas wrote: To some degree, what this boils down to is that you can have time-based releases or feature-based releases, but not both. Sure. But some people are trying to introduce another subvariant: The conference-circuit-based releases. ;-) It sounds attractive, but it shouldn't trump all other concerns. Consider this instead: Nothing to do during beta? Write your conference slides! ;-) I suggest going with four commit fests. Three is too short. We already started the first one early, which didn't give those involved in the release any time to prepare some patches for it. So with three fests you'd only give the major developers 8 weeks to code something for a yearly release. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Tom Lane píše v so 22. 08. 2009 v 09:56 -0400:
Zdenek Kotala zdenek.kot...@sun.com writes:
There are most important records from yesterdays issues.
Messages:
-
Aug 20 11:14:54 genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap
space to grow stack for pid 507 (postgres)
Hmm, that seems to confirm the idea that something had run the machine
out of memory/swap space, which would explain the repeated ENOMEM fork
failures. But we're still no closer to understanding how come the
delay in the avlauncher didn't do what it was supposed to.
I found hungry process which eats up all memory and fortunately it is
not postgres :-).
I run also following dtrace script:
dtrace -n 'syscall::kill:entry / execname==postgres/ { printf(%i %
s, %i-%i : %i, timestamp, execname, pid, arg0, arg1); }'
and it show following (little bit modified) output:
snip
CPU Timestamp[ns] diff[ms]caller callee sig
0 275074552090899,96 28604 - 28608 16
3 2750745100280460100,23 28608 - 28604 16
1 2750746000144690899,86 28604 - 28608 16
3 2750746100380940100,24 28608 - 28604 16
2 2750747000135380899,75 28604 - 28608 16
3 2750747100171650100,04 28608 - 28604 16
0 2750748000101050899,93 28604 - 28608 16
3 2750748100331900100,23 28608 - 28604 16
1 2750749000148550899,82 28604 - 28608 16
3 2750749100386640100,24 28608 - 28604 16
2 275075095040899,71 28604 - 28608 16
3 2750750100127780100,03 28608 - 28604 16
We can see there that AVlauncher really wait 100ms, but it is not enough
when system is under stress.
I tested Alvaro's patch and it works, because it does not lead to stack
consumption, but it shows another bug in StartAutovacuumWorker() code.
When fork fails bn structure is freed but
ReleasePostmasterChildSlot() should be called as well. See error:
2009-08-24 11:50:20.360 CEST 3468 FATAL: no free slots in PMChildFlags array
and comment in source code:
/* Out of slots ... should never happen, else postmaster.c messed up */
I think that Alvaro's patch is good and it fix a crash problem. I also
think that AVlauncher could wait little bit more then 100ms. When system
cannot fork, I don't see any reason why hurry to repeat a fork
operation. Maybe 1s is good compromise.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Zdenek Kotala píše v po 24. 08. 2009 v 13:47 +0200: I tested Alvaro's patch and it works, because it does not lead to stack consumption, but it shows another bug in StartAutovacuumWorker() code. When fork fails bn structure is freed but ReleasePostmasterChildSlot() should be called as well. See error: 2009-08-24 11:50:20.360 CEST 3468 FATAL: no free slots in PMChildFlags array and comment in source code: /* Out of slots ... should never happen, else postmaster.c messed up */ Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix solves the problem and PostgreSQL survives well during a memory shortages. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] hba load error and silent mode
Last night I had to deal with a puzzled user of version 8.4 who found postgres refused to start but didn't log any error. It turned out that there was an error in the pg_hba.conf file, and the client was running in silent mode (the SUSE default). This seems like a bug, and it's certainly not very postgres-like behaviour. Can we move the call to hba_load() in postmaster.c down a bit so it occurs after the SysLogger is set up? ISTM we really need an absolute minimum of code between the call to pmdaemonize() and SysLogger_Start(). (Maybe there's a good case for deprecating silent mode. I'm not sure why Suse uses it. Other distros don't seem to feel the need.) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
On Mon, Aug 24, 2009 at 14:39, Andrew Dunstanand...@dunslane.net wrote: Last night I had to deal with a puzzled user of version 8.4 who found postgres refused to start but didn't log any error. It turned out that there was an error in the pg_hba.conf file, and the client was running in silent mode (the SUSE default). This seems like a bug, and it's certainly not very postgres-like behaviour. Can we move the call to hba_load() in postmaster.c down a bit so it occurs after the SysLogger is set up? ISTM we really need an absolute minimum of code between the call to pmdaemonize() and SysLogger_Start(). I can see other reasons that this would be good, so +1 from me unless there is any specific reason we can't start it earlier. (Maybe there's a good case for deprecating silent mode. I'm not sure why Suse uses it. Other distros don't seem to feel the need.) Could be, but even with silent_mode=off that would be a problem, no? as in, the log wouldn't go where you'd expect it to go. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
This is to go with the hypot() patch I posted the other day.
As other code, such as found in adt/float.c and adt/numeric.c, simply
assumes that isnan() exists, despite it being a C99 function, I have
assumed the same.
The below code should be placed into a file called src/port/hypot.c.
Unfortunately I do not know how to drive configure and all the other
associated build magics. Could some kind soul please implemented that
portion. (Or shove me in the right direction)
#include math.h
#include c.h
#include utils/builtins.h
/*
* Find the hypotenuse. Firstly x and y are swapped, if required, to make
* x the larger number. The traditional formulae of x^2+y^2 is rearranged
* to bring x outside the sqrt. This allows computation of the hypotenuse
* for much larger magnitudes than otherwise normally possible.
*
* sqrt( x^2 + y^2 ) = sqrt( x^2( 1 + y^2/x^2) )
* = x * sqrt( 1 + y^2/x^2 )
* = x * sqrt( 1 + y/x * y/x )
*/
double hypot( double x, double y )
{
double yx;
if( isinf(x) || isinf(y) )
return get_float8_infinity();
if( isnan(x) || isnan(y) )
return get_float8_nan();
x = fabs(x);
y = fabs(y);
if (x y) {
double temp = x;
x = y;
y = temp;
}
if (x == 0.0)
return 0.0;
else {
yx = y/x;
return x*sqrt(1.0+yx*yx);
}
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote: --enable-cassert, enabled, and also added exit_* in pg_dump to list of functions that never return. A few more functions to mark noreturn: DateTimeParseError(), and die_horribly() in pg_dump -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 7:39 AM, Peter Eisentrautpete...@gmx.net wrote: On sön, 2009-08-23 at 09:37 -0400, Robert Haas wrote: To some degree, what this boils down to is that you can have time-based releases or feature-based releases, but not both. Sure. But some people are trying to introduce another subvariant: The conference-circuit-based releases. ;-) It sounds attractive, but it shouldn't trump all other concerns. Consider this instead: Nothing to do during beta? Write your conference slides! ;-) Oh, gee, what am I speaking on? :-) The main thing that I (can't speak for anyone else) like about getting a release out in time for PGCon is that it happens at about the same time every year, and I kind of like the idea of shooting for a yearly cycle. I'd be just as happy to release every year on Christmas day, but it's harder to get people to bundle a release around then. I suggest going with four commit fests. Three is too short. We already started the first one early, which didn't give those involved in the release any time to prepare some patches for it. So with three fests you'd only give the major developers 8 weeks to code something for a yearly release. Well, that's a good point, but 12 weeks out of a 14-month release cycle is only marginally better than 8 weeks out of a 12-month release cycle. If we really want to give people more time to write patches, we need to figure out how to speed up the time from the end of the last CommitFest until release. One thing that I had thought of proposing is that we branch the tree when we go to 8.5-beta and hold the first 8.6 CommitFest at that time - or, failing that, that we hold a DontCommitFest at that time, where we review all of the patches just as we would for a regular CommitFest, but without the committing part. At least for 8.4, it didn't seem like much was happening during beta, at least not much that was discussed on -hackers or could be distributed across the community. I actually don't think that's the ideal solution, though. It's just papering around the problem that the release takes too long and the burden falls on too few people. But we haven't yet come up with any good idea to address that problem. At any rate, I'm OK with 4 CommitFests if that is the consensus, but so far we only have 3 people weighing in on this thread, which is not a consensus for anything. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
This is to go with the hypot() patch I posted the other day.
As other code, such as found in adt/float.c and adt/numeric.c, simply
assumes that isnan() exists, despite it being a C99 function, I have
assumed the same.
The below code should be placed into a file called src/port/hypot.c.
Unfortunately I do not know how to drive configure and all the other
associated build magics. Could some kind soul please implemented that
portion. (Or shove me in the right direction)
Comments below :)
#include math.h
#include c.h
#include utils/builtins.h
/*
* Find the hypotenuse. Firstly x and y are swapped, if required, to make
* x the larger number. The traditional formulae of x^2+y^2 is rearranged
* to bring x outside the sqrt. This allows computation of the hypotenuse
* for much larger magnitudes than otherwise normally possible.
*
* sqrt( x^2 + y^2 ) = sqrt( x^2( 1 + y^2/x^2) )
* = x * sqrt( 1 + y^2/x^2 )
* = x * sqrt( 1 + y/x * y/x )
*/
double hypot( double x, double y )
{
double yx;
if( isinf(x) || isinf(y) )
return get_float8_infinity();
if( isnan(x) || isnan(y) )
return get_float8_nan();
x = fabs(x);
y = fabs(y);
if (x y) {
double temp = x;
x = y;
y = temp;
}
How about putting:
if (x = 0.0 y == 0.0)
return x;
here?
These next two lines are a teensy bit baroque. Is there some
significant speed increase that would justify them?
if (x == 0.0)
return 0.0;
else {
yx = y/x;
return x*sqrt(1.0+yx*yx);
}
}
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Magnus Hagander wrote: (Maybe there's a good case for deprecating silent mode. I'm not sure why Suse uses it. Other distros don't seem to feel the need.) Could be, but even with silent_mode=off that would be a problem, no? as in, the log wouldn't go where you'd expect it to go. It would go to stderr, and then I would have seen it. Silent mode apparently sends stderr to the bit bucket until the syslogger is set up. I found where the error was by running postmaster under strace, but that's really rather icky. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
On Mon, Aug 24, 2009 at 02:57:02PM +0200, Magnus Hagander wrote: On Mon, Aug 24, 2009 at 14:39, Andrew Dunstanand...@dunslane.net wrote: Last night I had to deal with a puzzled user of version 8.4 who found postgres refused to start but didn't log any error. It turned out that there was an error in the pg_hba.conf file, and the client was running in silent mode (the SUSE default). This seems like a bug, and it's certainly not very postgres-like behaviour. Can we move the call to hba_load() in postmaster.c down a bit so it occurs after the SysLogger is set up? ISTM we really need an absolute minimum of code between the call to pmdaemonize() and SysLogger_Start(). I can see other reasons that this would be good, so +1 from me unless there is any specific reason we can't start it earlier. +1 from me, too, under the same condition. Since logging in really interesting ways depends on a separate process, any logging before then will be abnormal, and any logs we create will probably show up in a relatively unexpected place. The Principle of Least Surprise suggests we minimize that possibility. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] hba load error and silent mode
Andrew Dunstan and...@dunslane.net writes: (Maybe there's a good case for deprecating silent mode. +1. The only reason to use it is that an init-script writer is too lazy to deal with things properly --- the thing in question here being exactly to think of a place for early failure messages to go. You can *not* just move the syslogger start call up; it's dependent on having done some of the other initialization steps. (chdir and signal setup being obvious candidates.) In general, there will always be messages that come out before the syslogger can start, and thus a robust setup has got to provide some fallback place for them. It might be that a reasonable solution on our end would be for pmdaemonize to point stdout/stderr someplace other than /dev/null, perhaps $PGDATA/postmaster.log? Of course, it's not clear what we're supposed to do if that open() fails ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: It might be that a reasonable solution on our end would be for pmdaemonize to point stdout/stderr someplace other than /dev/null, perhaps $PGDATA/postmaster.log? Of course, it's not clear what we're supposed to do if that open() fails ... Well, yes, but that is at least a comparatively low risk, certainly much much lower than the risk having a faulty hba file, for example. This sounds like a reasonable approach. Actually, if people are happy with that basic behavior, I think we could make it robust: open /dev/null and $PGDATA/postmaster.log *before* we fork away from the terminal session. On failure, report that and exit(1). On success, go ahead and fork. Failure of the subsequent dup2() calls should be just about impossible --- in fact, so far as I can tell from the SUS documents, if we put in a loop for EINTR then there is no documented way for them to fail. If no objections, I'll be happy to make this happen. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Tom Lane wrote: It might be that a reasonable solution on our end would be for pmdaemonize to point stdout/stderr someplace other than /dev/null, perhaps $PGDATA/postmaster.log? Of course, it's not clear what we're supposed to do if that open() fails ... Well, yes, but that is at least a comparatively low risk, certainly much much lower than the risk having a faulty hba file, for example. This sounds like a reasonable approach. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Bruce Momjian wrote: Ultimately, why not allow: DELETE h, tn FROM history AS h INNER JOIN term_node AS tn ON (h.nid = tn.nid) INNER JOIN term_data AS td ON (td.tid = tn.tid) WHERE h.uid = 2067 AND td.vid = 2 IMHO this would improve compliance towards other database systems. To me this seems to be in the reasonable scope of compatibility. Which other database systems? Only MySQL? If it is MySQL-only, we are unlikely to add it. The SQL standard does not support this syntax. They would have you put the joins in a subselect (which is often not enough because then you can't use outer joins). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Zdenek Kotala zdenek.kot...@sun.com writes: ... We can see there that AVlauncher really wait 100ms, but it is not enough when system is under stress. OK, thanks for checking that. I think that Alvaro's patch is good and it fix a crash problem. I also think that AVlauncher could wait little bit more then 100ms. When system cannot fork, I don't see any reason why hurry to repeat a fork operation. Maybe 1s is good compromise. Seems reasonable to me. Alvaro, do you want to take care of applying these three fixes? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Zdenek Kotala wrote:
Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix
solves the problem and PostgreSQL survives well during a memory
shortages.
So this patch would do it.
I think this stuff about postmaster child slots is later than
launcher/worker split. I don't recall seeing it before.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/backend/postmaster/postmaster.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.587
diff -c -p -r1.587 postmaster.c
*** src/backend/postmaster/postmaster.c 7 Aug 2009 05:58:55 - 1.587
--- src/backend/postmaster/postmaster.c 24 Aug 2009 15:05:50 -
*** bool redirection_done = false; /* stder
*** 290,295
--- 290,297
/* received START_AUTOVAC_LAUNCHER signal */
static volatile sig_atomic_t start_autovac_launcher = false;
+ /* the launcher needs to be signalled to communicate some condition */
+ static volatile bool avlauncher_needs_signal = false;
/*
* State for assigning random salts and cancel keys.
*** ServerLoop(void)
*** 1391,1396
--- 1393,1406
if (PgStatPID == 0 pmState == PM_RUN)
PgStatPID = pgstat_start();
+ /* If we need to signal the autovacuum launcher, do so now */
+ if (avlauncher_needs_signal)
+ {
+ avlauncher_needs_signal = false;
+ if (AutoVacPID != 0)
+ kill(AutoVacPID, SIGUSR1);
+ }
+
/*
* Touch the socket and lock file every 58 minutes, to ensure that
* they are not removed by overzealous /tmp-cleaning tasks. We assume
*** StartAutovacuumWorker(void)
*** 4343,4348
--- 4353,4359
* fork failed, fall through to report -- actual error message was
* logged by StartAutoVacWorker
*/
+ ReleasePostmasterChildSlot(bn-child_slot);
free(bn);
}
else
*** StartAutovacuumWorker(void)
*** 4354,4365
/*
* Report the failure to the launcher, if it's running. (If it's not, we
* might not even be connected to shared memory, so don't try to call
! * AutoVacWorkerFailed.)
*/
if (AutoVacPID != 0)
{
AutoVacWorkerFailed();
! kill(AutoVacPID, SIGUSR1);
}
}
--- 4365,4380
/*
* Report the failure to the launcher, if it's running. (If it's not, we
* might not even be connected to shared memory, so don't try to call
! * AutoVacWorkerFailed.) Note that we also need to signal it so that it
! * responds to the condition, but we don't do that here, instead waiting
! * for ServerLoop to do it. This way we avoid a ping-pong signalling in
! * quick succession between the autovac launcher and postmaster in case
! * things get ugly.
*/
if (AutoVacPID != 0)
{
AutoVacWorkerFailed();
! avlauncher_needs_signal = true;
}
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Alvaro Herrera wrote: Bruce Momjian wrote: Ultimately, why not allow: DELETE h, tn FROM history AS h INNER JOIN term_node AS tn ON (h.nid = tn.nid) INNER JOIN term_data AS td ON (td.tid = tn.tid) WHERE h.uid = 2067 AND td.vid = 2 IMHO this would improve compliance towards other database systems. To me this seems to be in the reasonable scope of compatibility. Which other database systems? Only MySQL? If it is MySQL-only, we are unlikely to add it. The SQL standard does not support this syntax. They would have you put the joins in a subselect (which is often not enough because then you can't use outer joins). So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Bug in date arithmetic
Folks, While debugging an error with Aziz (postgres_newbie) Sharief in the #postgresql IRC channel, I found a major POLA violation: $ psql Welcome to psql 8.3.7, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit shac...@shackle:5432=# SELECT now() + '90'; ?column? --- 2009-09-03 19:03:43.195514-07 (1 row) shac...@shackle:5432=# SELECT now() - '90'; ERROR: date/time field value out of range: 90 HINT: Perhaps you need a different datestyle setting. I'd be tempted to call it a flat-out bug in the first case. Adding a string literal to a timestamptz should just result in an error, IMHO. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Ultimately, why not allow: DELETE h, tn FROM history AS h INNER JOIN term_node AS tn ON (h.nid = tn.nid) INNER JOIN term_data AS td ON (td.tid = tn.tid) WHERE h.uid = 2067 AND td.vid = 2 IMHO this would improve compliance towards other database systems. To me this seems to be in the reasonable scope of compatibility. Which other database systems? Only MySQL? If it is MySQL-only, we are unlikely to add it. The SQL standard does not support this syntax. They would have you put the joins in a subselect (which is often not enough because then you can't use outer joins). So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? Not sure about that. USING is already an extension to the standard, so if we extend it a bit more, it can't be a problem, can it? But this doesn't solve Jean Michel's problem, because MySQL does not support DELETE USING (or does it?). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] compilation with libeditpreferred is broken
Zdenek Kotala zdenek.kot...@sun.com writes: I attached conservative version of patch which only reorder #define to avoid cross including half from readline and half from editline. Applied, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: Ultimately, why not allow: DELETE h, tn FROM history AS h INNER JOIN term_node AS tn ON (h.nid = tn.nid) INNER JOIN term_data AS td ON (td.tid = tn.tid) WHERE h.uid = 2067 AND td.vid = 2 IMHO this would improve compliance towards other database systems. To me this seems to be in the reasonable scope of compatibility. Which other database systems? Only MySQL? If it is MySQL-only, we are unlikely to add it. The SQL standard does not support this syntax. They would have you put the joins in a subselect (which is often not enough because then you can't use outer joins). So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? Not sure about that. USING is already an extension to the standard, so if we extend it a bit more, it can't be a problem, can it? But this doesn't solve Jean Michel's problem, because MySQL does not support DELETE USING (or does it?). Right, but if we support ANSI joins in the USING clause, at least we would have a _functional_ equivalent, which we don't know because of missing outer join support. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
pete...@gmx.net (Peter Eisentraut) writes: I suggest going with four commit fests. Three is too short. We already started the first one early, which didn't give those involved in the release any time to prepare some patches for it. So with three fests you'd only give the major developers 8 weeks to code something for a yearly release. Partial counter-argument... A large portion of the patches in CommitFest #1 represented items that had been deferred from 8.4. So... a) Many of these patches came in with ~6 months of preparation time b) People were always free to start work earlier than CommitFest #1 c) If something requires a *lot* of work, then it may be that it gets deferred so that it comes in as part of CommitFest #1 for 8.6, with the very same characteristics as in a)... I do agree that trying to force coordination with a specific conference in Ottawa seems like a very peculiar sort of forced scheduling. -- select 'cbbrowne' || '@' || 'ca.afilias.info'; Christopher Browne Bother, said Pooh, Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Alvaro Herrera alvhe...@commandprompt.com writes: Zdenek Kotala wrote: Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix solves the problem and PostgreSQL survives well during a memory shortages. So this patch would do it. Looks good to me, but I think you should also increase the avlauncher delay from 100ms - 1s as Zdenek suggested. I think this stuff about postmaster child slots is later than launcher/worker split. I don't recall seeing it before. Yeah, I added that recently to try to detect postmaster children that exit without cleaning up properly. I seem to have missed this error case :-(. Actually it looks like fork failure for regular backends gets it wrong too :-( :-( --- would you please also add one in the pid0 path in BackendStartup? I think this logic is in 8.4 too, in which case it'll need to be back-patched. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
On Mon, Aug 24, 2009 at 16:31, Tom Lanet...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: (Maybe there's a good case for deprecating silent mode. +1. The only reason to use it is that an init-script writer is too lazy to deal with things properly --- the thing in question here being exactly to think of a place for early failure messages to go. You can *not* just move the syslogger start call up; it's dependent on having done some of the other initialization steps. (chdir and signal setup being obvious candidates.) In general, there will always be messages that come out before the syslogger can start, and thus a robust setup has got to provide some fallback place for them. Agreed. I don't see why we couldn't move the hba call specifically, though. That's a fairly common error, so it would be good if the output went to the place that is actually configured in postgresql.conf. It's at least a lot more likely than most other things that are prior to syslogger startup. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
In response to Bruce Momjian br...@momjian.us: Alvaro Herrera wrote: Bruce Momjian wrote: Ultimately, why not allow: DELETE h, tn FROM history AS h INNER JOIN term_node AS tn ON (h.nid = tn.nid) INNER JOIN term_data AS td ON (td.tid = tn.tid) WHERE h.uid = 2067 AND td.vid = 2 IMHO this would improve compliance towards other database systems. To me this seems to be in the reasonable scope of compatibility. Which other database systems? Only MySQL? If it is MySQL-only, we are unlikely to add it. The SQL standard does not support this syntax. They would have you put the joins in a subselect (which is often not enough because then you can't use outer joins). So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? I suspect that the reason MySQL has this syntax is because for a long time they didn't have proper foreign keys and referential integrity. With proper foreign keys and ON DELETE CASCADE, why would supporting such syntax even be necessary? -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Magnus Hagander mag...@hagander.net writes: I don't see why we couldn't move the hba call specifically, though. That's a fairly common error, so it would be good if the output went to the place that is actually configured in postgresql.conf. It's at least a lot more likely than most other things that are prior to syslogger startup. Oh, you mean move load_hba *down*, past the syslogger startup? Yeah, that would probably be all right. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
David Fetter da...@fetter.org writes: While debugging an error with Aziz (postgres_newbie) Sharief in the #postgresql IRC channel, I found a major POLA violation: I see no bug here. There is only one '+' operator with timestamptz as left input, and it is timestamptz plus interval, so the system takes the unknown literal as an interval. Possibly it should throw error instead of assuming that the unmarked value is in seconds, but I'll bet money that people are depending on that longstanding behavior. As for the other case, there are two possible interpretations: regression=# select oid::regoperator from pg_operator where oprname = '-' and oprleft = 'timestamptz'::regtype; oid -- -(timestamp with time zone,timestamp with time zone) -(timestamp with time zone,interval) (2 rows) and the first one is preferred due to an ancient and generally correct heuristic. I'm not sure why it's complaining about field overflow rather than syntax error when the literal is taken as a timestamp, but that's a pretty minor issue. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Alvaro Herrera alvhe...@commandprompt.com writes: Bruce Momjian wrote: So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? Not sure about that. USING is already an extension to the standard, so if we extend it a bit more, it can't be a problem, can it? I don't see any very good way to extend the USING syntax to allow the target table to be outer-joined to something else. Some other systems allow it by letting you re-specify the target in the other clause, equivalently to DELETE FROM target t USING t LEFT JOIN other_table ot ON ... but we have always considered that the target is *not* to be identified with any member of the FROM/USING clause, so it would be a serious compatibility break to change that now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 09:12:07AM -0700, David Fetter wrote: shac...@shackle:5432=# SELECT now() + '90'; ?column? --- 2009-09-03 19:03:43.195514-07 (1 row) shac...@shackle:5432=# SELECT now() - '90'; ERROR: date/time field value out of range: 90 HINT: Perhaps you need a different datestyle setting. I'd be tempted to call it a flat-out bug in the first case. Adding a string literal to a timestamptz should just result in an error, IMHO. But you're not adding a string literal, you're adding an interval of 90 seconds, or 250 hours! This is the weirdness resulting from the lack of difference in syntax between string literals and other literals. i.e. SELECT timestamptz '2000-01-01'; = 2000-01-01 00:00:00+00 SELECT timestamptz '2000-01-01' + '90'; = 2000-01-11 10:00:00+00 SELECT timestamptz '2000-01-01' + interval '90'; = 2000-01-11 10:00:00+00 SELECT timestamptz '2000-01-01' + 90; = no operator matches (rhs is of type INT) SELECT timestamptz '2000-01-01' + text '90'; = no operator matches (rhs is of type TEXT) It seems to be deciding the unknown type is of type date with subtraction for some reason: SELECT timestamptz '2000-01-01' + '90'; = date/time field value out of range SELECT timestamptz '2000-01-01' - date '90'; = date/time field value out of range Whereas you were expecting it to be using an interval as before: SELECT timestamptz '2000-01-01' - interval '90'; = 1999-12-21 14:00:00+00 A timestamptz + date operator doesn't exist though, so it wouldn't wouldn't be able to pick it and is why you were seeing this odd behavior. Not sure what good fixes would be; a couple of simple (and bad) ones would be: 1) assume literals are of type text, unless otherwise specified. 2) require the type of the literal to be specified if there is any ambiguity The second option is nicer, but defining any ambiguity doesn't seem possible in general; worse, it would seem to change over time as operators/types were added/removed and would cause things that used to work to start breaking. Then again they would now, so I'm not sure why this would be worse. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
Christopher Browne cbbro...@ca.afilias.info writes: I do agree that trying to force coordination with a specific conference in Ottawa seems like a very peculiar sort of forced scheduling. Well, PGCon is just a convenient concrete target. The real point here is that we're trying to get the release cycle to end with a release in the spring. We've grown tired of releasing in the fall and invariably finding the date slipping into holiday season, so we'd like to try releasing near the other equinox. (Neither solstice is good, since you are up against either holidays or vacations taking away the time of the people who need to be doing the work.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
2009/8/24 Tom Lane t...@sss.pgh.pa.us: Alvaro Herrera alvhe...@commandprompt.com writes: Bruce Momjian wrote: So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? Not sure about that. USING is already an extension to the standard, so if we extend it a bit more, it can't be a problem, can it? I don't see any very good way to extend the USING syntax to allow the target table to be outer-joined to something else. Some other systems allow it by letting you re-specify the target in the other clause, equivalently to DELETE FROM target t USING t LEFT JOIN other_table ot ON ... but we have always considered that the target is *not* to be identified with any member of the FROM/USING clause, so it would be a serious compatibility break to change that now. I'm all in favor of compatibility, but if there is any way to make this work without massive collateral damage, I am also all in favor of that. I am forever writing queries that contain a needless self-join to work around the impossibility of directly outer-joining against the target. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
I wrote: ... I'm not sure why it's complaining about field overflow rather than syntax error when the literal is taken as a timestamp, but that's a pretty minor issue. Oh, of course, it's because we allow this shorthand: regression=# select '900102'::timestamptz; timestamptz 1990-01-02 00:00:00-05 (1 row) so '90'::timestamptz is seen as year (19)90, month 00, day 00, and field out of range is entirely sensible for that. Just out of curiosity, what were you *expecting* this to do? You obviously weren't expecting the literal to be taken as interval, but its contents are not very sane for any other likely interpretation. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 5:55 PM, Tom Lanet...@sss.pgh.pa.us wrote: Christopher Browne cbbro...@ca.afilias.info writes: I do agree that trying to force coordination with a specific conference in Ottawa seems like a very peculiar sort of forced scheduling. Well, PGCon is just a convenient concrete target. The real point here is that we're trying to get the release cycle to end with a release in the spring. Yeah, conference-based releases is just a proxy for time-based releases. It's nice to have something to be happy about at the conference too. And it's a convenient time to start talking about the next release when you're all face-to-face. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Zdenek Kotala wrote: Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix solves the problem and PostgreSQL survives well during a memory shortages. So this patch would do it. Looks good to me, but I think you should also increase the avlauncher delay from 100ms - 1s as Zdenek suggested. Committed with this change. I think this stuff about postmaster child slots is later than launcher/worker split. I don't recall seeing it before. Yeah, I added that recently to try to detect postmaster children that exit without cleaning up properly. I seem to have missed this error case :-(. Actually it looks like fork failure for regular backends gets it wrong too :-( :-( --- would you please also add one in the pid0 path in BackendStartup? I think this logic is in 8.4 too, in which case it'll need to be back-patched. And this one too. Thanks! -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Robert Haas robertmh...@gmail.com writes: 2009/8/24 Tom Lane t...@sss.pgh.pa.us: ... Some other systems allow it by letting you re-specify the target in the other clause, equivalently to DELETE FROM target t USING t LEFT JOIN other_table ot ON ... but we have always considered that the target is *not* to be identified with any member of the FROM/USING clause, so it would be a serious compatibility break to change that now. I'm all in favor of compatibility, but if there is any way to make this work without massive collateral damage, I am also all in favor of that. I am forever writing queries that contain a needless self-join to work around the impossibility of directly outer-joining against the target. It'd be pretty easy to do if we were willing to introduce a new reserved word; for example DELETE FROM target t USING SELF LEFT JOIN other_table ot ON ... (or maybe TARGET instead of SELF, or some other word). Wouldn't do anything for exact compatibility with MySQL or anybody else using the respecify-the-target-table-name approach. But it would be unambiguous and backwards-compatible. The real problem with this is that all the good candidates for the reserved word are things people are probably already using as aliases, so we'd have a large risk of breaking existing queries. We could avoid that with a sufficiently ugly choice like DELETE FROM target t USING DELETE_TARGET LEFT JOIN other_table ot ON ... but yech ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
David Fetter da...@fetter.org wrote:
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
These next two lines are a teensy bit baroque. Is there some
significant speed increase that would justify them?
if (x == 0.0)
return 0.0;
else {
yx = y/x;
return x*sqrt(1.0+yx*yx);
}
}
I think the reason is overflow. From the function comment:
* The traditional formulae of x^2+y^2 is rearranged
* to bring x outside the sqrt. This allows computation of the
hypotenuse
* for much larger magnitudes than otherwise normally possible.
Although I don't see why the first part isn't:
if (y == 0.0)
return x;
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
All, Yeah, conference-based releases is just a proxy for time-based releases. It's nice to have something to be happy about at the conference too. And it's a convenient time to start talking about the next release when you're all face-to-face. On the one hand: I'd say that we go for the 3-CF release. I think we need to prove that we can do a time-based release once before a lot of people on this list will believe in it. If we do 4 CFs, we're in danger of still being in beta in late May ... and once conference and vacation season start, things get a lot slower. Mind you, it's possible that we can shorten the final CF and beta this time, but I wouldn't want to count on it. If we *can* shorten them, then 8.6 can have 4CFs. But we won't know until after we've done it. On the other hand: I think if we do another release without Standby/replication, we'll start to lose a lot of users. People are waiting on that, and a lot of folks were expecting it in 8.4. Therefore: I think, 3CFs, but we go all-out to get Standby/Replication into 8.5 in the next month. So, every committer/major hacker on this list should pitch in to get those features done. So, is there someone here who could be helping with HS/SR and isn't? Why not? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: I don't see why we couldn't move the hba call specifically, though. That's a fairly common error, so it would be good if the output went to the place that is actually configured in postgresql.conf. It's at least a lot more likely than most other things that are prior to syslogger startup. Oh, you mean move load_hba *down*, past the syslogger startup? Yeah, that would probably be all right. Well, that's what I originally said, yes ;-) But I don't think that precludes your more general suggestion regarding startup errors. In particular, I think moving the hba load down would be reasonable to backpatch to 8.4, whereas I doubt the general fix would. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
On Mon, Aug 24, 2009 at 01:41:28PM -0400, Tom Lane wrote: The real problem with this is that all the good candidates for the reserved word are things people are probably already using as aliases, so we'd have a large risk of breaking existing queries. We could avoid that with a sufficiently ugly choice like DELETE FROM target t USING DELETE_TARGET LEFT JOIN other_table ot ON ... but yech ... PRIMARY or TABLE? Both are pretty grim, but I think they're reserved at the moment. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Mon, Aug 24, 2009 at 12:47:42PM -0500, Kevin Grittner wrote:
David Fetter da...@fetter.org wrote:
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
These next two lines are a teensy bit baroque. Is there some
significant speed increase that would justify them?
if (x == 0.0)
return 0.0;
else {
yx = y/x;
return x*sqrt(1.0+yx*yx);
}
}
I think the reason is overflow. From the function comment:
* The traditional formulae of x^2+y^2 is rearranged
* to bring x outside the sqrt. This allows computation of the
hypotenuse
* for much larger magnitudes than otherwise normally possible.
Although I don't see why the first part isn't:
if (y == 0.0)
return x;
D'oh!
Good point :)
So the code should read as follows?
#include math.h
#include c.h
#include utils/builtins.h
/*
* Find the hypotenuse. Firstly x and y are swapped, if required, to make
* x the larger number. The traditional formulae of x^2+y^2 is rearranged
* to bring x outside the sqrt. This allows computation of the hypotenuse
* for much larger magnitudes than otherwise normally possible.
*
* sqrt( x^2 + y^2 ) = sqrt( x^2( 1 + y^2/x^2) )
* = x * sqrt( 1 + y^2/x^2 )
* = x * sqrt( 1 + y/x * y/x )
*/
double hypot( double x, double y )
{
double yx;
if( isinf(x) || isinf(y) )
return get_float8_infinity();
if( isnan(x) || isnan(y) )
return get_float8_nan();
x = fabs(x);
y = fabs(y);
if (x y) {
double temp = x;
x = y;
y = temp;
}
if (y == 0.0)
return x;
yx = y/x;
return x*sqrt(1.0+yx*yx);
}
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 01:18:46PM -0400, Tom Lane wrote: I wrote: ... I'm not sure why it's complaining about field overflow rather than syntax error when the literal is taken as a timestamp, but that's a pretty minor issue. Oh, of course, it's because we allow this shorthand: regression=# select '900102'::timestamptz; timestamptz 1990-01-02 00:00:00-05 (1 row) so '90'::timestamptz is seen as year (19)90, month 00, day 00, and field out of range is entirely sensible for that. Just out of curiosity, what were you *expecting* this to do? You obviously weren't expecting the literal to be taken as interval, but its contents are not very sane for any other likely interpretation. The gentleman in IRC was the one who was using the construct. I spell out my date arithmetic. :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Mon, Aug 24, 2009 at 07:07:13AM -0700, David Fetter wrote:
These next two lines are a teensy bit baroque. Is there some
significant speed increase that would justify them?
Just noticed with your revised code that the following check:
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
if (x == 0.0)
return 0.0;
else {
yx = y/x;
is preventing a divide by zero on the line above. So it's not a
performance hack, it's just allowing it to remain correct as a result of
changing the maths around.
return x*sqrt(1.0+yx*yx);
}
}
--
Sam http://samason.me.uk/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 1:48 PM, Josh Berkusj...@agliodbs.com wrote: Therefore: I think, 3CFs, but we go all-out to get Standby/Replication into 8.5 in the next month. So, every committer/major hacker on this list should pitch in to get those features done. So, is there someone here who could be helping with HS/SR and isn't? Why not? Unfortunately, neither Simon nor Fujii Masao is publishing a git repository of their work or regular updates to their patch set. Therefore, no one else can contribute code, and in fact no one else can even provide a review, because there is nothing to look at. I don't think that there would be any problem getting these patches reviewed/committed outside of the regular CommitFest cycle, but there's simply no place to start. I have volunteered to work on Hot Standby and have merged it up to CVS HEAD several times, and cleaned out a bit of other cruft, but the scope of the task appears to exceed the time I have available. It seems to me that other people could clone my git repo (or that branch) and submit patches against it (or ask me to pull from a branch that they publish), but will Simon incorporate those patches (assuming that they don't suck) into his next version, or ignore them? It's not really clear. As I've said before, I am presently of the opinion that Streaming Replication has little chance of making it into 8.5. This opinion is vulnerable to contrary evidence, like a new version of the patch showing up that shows massive progress. But the patch was bounced from CF 2009-07 for a whole series of architectural problems which have to be addressed before we can even get to implementation details, bugs, documentation, etc. Hot Standby is in better shape but amount of code cleanup needed is substantial and there is also quite a bit of 'git diff master | grep XXX' that needs to be gone through. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Mon, Aug 24, 2009 at 06:59:38PM +0100, Sam Mason wrote:
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
if (x == 0.0)
return 0.0;
else {
yx = y/x;
is preventing a divide by zero on the line above. So it's not a
performance hack, it's just allowing it to remain correct as a result of
changing the maths around.
I've also just realized why it's safe to return zero here; y contains
the smaller number and so if x is zero, y must be zero as well.
--
Sam http://samason.me.uk/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
David Fetter da...@fetter.org writes: On Mon, Aug 24, 2009 at 01:18:46PM -0400, Tom Lane wrote: Just out of curiosity, what were you *expecting* this to do? The gentleman in IRC was the one who was using the construct. Well, what did he think it would do? If it's a date it's invalid, and if it's not a date I'm not sure what he expected... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
David Fetter da...@fetter.org writes: He expected '-' to subtract seconds, just as '+' added them. Ah. Well, what it boils down to is that in a scenario like known_type_expr operator unknown_literal we preferentially consider unknown_literal to be of the same type as the other operand. But there's no timestamp plus timestamp operator (doesn't seem like a sensible operation to me, does it to you?), so there's only one possible typing of the unknown literal, and it's not that. Plus and minus just aren't all that symmetrical in this situation. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: Oh, you mean move load_hba *down*, past the syslogger startup? Yeah, that would probably be all right. Well, that's what I originally said, yes ;-) But I don't think that precludes your more general suggestion regarding startup errors. In particular, I think moving the hba load down would be reasonable to backpatch to 8.4, whereas I doubt the general fix would. Well, the change I had in mind is only a few lines of code, and is fixing a behavior that you yourself are arguing is unusably broken. It seems like a reasonable back-patch candidate to me if we think this is a serious bug. But I personally wasn't seeing any of this as due for back-patching. The -S behavior has been like it is since forever, and nobody's complained before. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 02:05:38PM -0400, Tom Lane wrote: David Fetter da...@fetter.org writes: On Mon, Aug 24, 2009 at 01:18:46PM -0400, Tom Lane wrote: Just out of curiosity, what were you *expecting* this to do? The gentleman in IRC was the one who was using the construct. Well, what did he think it would do? If it's a date it's invalid, and if it's not a date I'm not sure what he expected... I apologize for being obtuse. He expected '-' to subtract seconds, just as '+' added them. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
Josh Berkus j...@agliodbs.com writes: So, is there someone here who could be helping with HS/SR and isn't? Why not? You mean, other than Simon's hands-off attitude? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: Yeah, I added that recently to try to detect postmaster children that exit without cleaning up properly. I seem to have missed this error case :-(. Actually it looks like fork failure for regular backends gets it wrong too :-( :-( --- would you please also add one in the pid0 path in BackendStartup? I think this logic is in 8.4 too, in which case it'll need to be back-patched. And this one too. Almost right --- we only want to release for non-dead_end children. I fixed that part. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGUSR1 pingpong between master na autovacum launcher causes crash
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: Yeah, I added that recently to try to detect postmaster children that exit without cleaning up properly. I seem to have missed this error case :-(. Actually it looks like fork failure for regular backends gets it wrong too :-( :-( --- would you please also add one in the pid0 path in BackendStartup? I think this logic is in 8.4 too, in which case it'll need to be back-patched. And this one too. Almost right --- we only want to release for non-dead_end children. I fixed that part. Oops, sorry about that -- I even noticed it :-( -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: Oh, you mean move load_hba *down*, past the syslogger startup? Yeah, that would probably be all right. Well, that's what I originally said, yes ;-) But I don't think that precludes your more general suggestion regarding startup errors. In particular, I think moving the hba load down would be reasonable to backpatch to 8.4, whereas I doubt the general fix would. Well, the change I had in mind is only a few lines of code, and is fixing a behavior that you yourself are arguing is unusably broken. It seems like a reasonable back-patch candidate to me if we think this is a serious bug. But I personally wasn't seeing any of this as due for back-patching. The -S behavior has been like it is since forever, and nobody's complained before. We didn't check HBA validity at startup time before, did we? I would not be surprised to get more complaints now. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Mon, Aug 24, 2009 at 6:52 PM, David Fetterda...@fetter.org wrote:
double hypot( double x, double y )
{
double yx;
if( isinf(x) || isinf(y) )
return get_float8_infinity();
if( isnan(x) || isnan(y) )
return get_float8_nan();
For what it's worth though, check out the code in float.c to see how
postgres handles floating point overflows. I'm not sure whether it's
forced by the standard, we discussed and settled on this behaviour, or
the person who wrote it just thought it was a good idea but we may as
well be consistent.
The behaviour we have now is that if you pass Inf or -Inf then we
happily return Inf or -Inf (or whatever the result is) as appropriate.
But if the operation overflows despite being passed reasonable values
then it throws an error.
Afaict hypot() can still overflow even with this new coding if you
have, say, hypot(MAX_FLOAT, MAX_FLOAT) which will return MAX_FLOAT *
sqrt(2). In that case we should throw an error unless either input was
Inf.
Also, the question arises what should be returned for hypot(Inf,NaN)
which your code returns Inf for. Empirically, it seems the normal
floating point behaviour is to return NaN so I think the NaN test
should be first.
Lastly I find the swap kind of confusing and also think it might
perform less well than just having one branch and simple logic in each
branch. This is just a style question that you could see either way
though, the performance difference is probably immeasurable if even if
my guess is right.
so I would suggest:
if (isnan(x) || isnan(y)
return float8_get_nan();
else if (isinf(x) || isinf(y))
return float8_get_inf();
else if (x == 0.0 y == 0.0)
return 0.0;
x = fabs(x);
y = fabs(y);
if (x y)
retval = x * sqrt((y/x)*(y/x) + 1);
else
retval = y * sqrt((x/y)*(x/y) + 1);
if (isinf(retval))
ereport(overflow...)
return retval;
}
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Determining client_encoding from client locale
On Wed, Aug 19, 2009 at 11:08 AM, Jaime Casanovajcasa...@systemguards.com.ec wrote: On Tue, Aug 18, 2009 at 6:49 AM, Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote: Hmm, are you sure you the right version of libpq is being loaded at runtime? What does ldd ./test-libpq say? attached the results of ldd and the result of the test script for client_encoding=auto and client_encoding=latin1, seems like it's trying to use auto as an encoding and when it fails takes SQL_ASCII the same results for windows (i used dependency walker to be sure i was using the right libpq.dll) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 postg...@casanova1:~/pg_releases/pgtests$ ldd ./test-libpq linux-vdso.so.1 = (0x7fffad1ff000) libpq.so.5 = /usr/local/pgsql/head.client_encoding/lib/libpq.so.5 (0x7fdea4c48000) libc.so.6 = /lib/libc.so.6 (0x7fdea48f5000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x7fdea46bd000) /lib64/ld-linux-x86-64.so.2 (0x7fdea4e6a000) postg...@casanova1:~/pg_releases/pgtests$ ./test-libpq dbname=postgres user=postgres client_encoding=auto PostgreSQL version(): PostgreSQL 8.5devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2, 64-bit client_encoding: SQL_ASCII postg...@casanova1:~/pg_releases/pgtests$ ./test-libpq dbname=postgres user=postgres client_encoding=latin1 PostgreSQL version(): PostgreSQL 8.5devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2, 64-bit client_encoding: latin1 administra...@casanova11 ~$ ./test-libpq.exe dbname=postgres user=postgres host=192.168.0.196 port=54323 PostgreSQL version: PostgreSQL 8.5devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2, 64-bit client_encoding: UTF8 administra...@casanova11 ~$ ./test-libpq.exe dbname=postgres user=postgres host=192.168.0.196 port=54323 client_encoding=latin1 PostgreSQL version: PostgreSQL 8.5devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2, 64-bit client_encoding: latin1 administra...@casanova11 ~$ ./test-libpq.exe dbname=postgres user=postgres host=192.168.0.196 port=54323 client_encoding=auto PostgreSQL version: PostgreSQL 8.5devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2, 64-bit client_encoding: SQL_ASCII -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Issues for named/mixed function notation patch
Hello,
I reworked patch to respect mentioned issues. - this patch still
implement mixed notation - I am thing so this notation is really
important. All others I respect. The behave is without change, fixed
some bugs, enhanced regress tests.
Sorry for delay.
Regards
Pavel Stehule
p.s. Bernard, please, can you look on this version?
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
I've now read most of this patch, and I think there are some things that
need rework, and perhaps debate about what we want.
1. As I already mentioned, I think the mixed-notation business is a bad
idea. It's unintuitive, it's not especially useful, and it substantially
increases our risk of being semantically incompatible with whatever the
SQL committee might someday do in this area. I think we should disallow
it until we see what they do. I gather that this might be an unpopular
position though.
2. It doesn't appear that any attention has been given to what happens
if CREATE OR REPLACE FUNCTION is used to change the parameter names of
an existing function. Since the post-analysis representation of parameter
lists is still entirely positional, the actual effect on a function call
in a stored view or rule is nil --- it will still call the same function
it did before, passing the parameters that were originally identified to
be passed. That might be considered good, but it's quite unlike what
will happen to function calls that are stored textually (eg, in plpgsql
functions). Is that what we want? Or should we consider that parameter
names are now part of the API of a function, and forbid CREATE OR REPLACE
FUNCTION from changing them? Or perhaps we should recheck parameter name
matching someplace after analysis, perhaps at default-expansion time?
3. In the same vein, CREATE FUNCTION doesn't disallow duplicate parameter
names, nor functions that have names for some but not all parameters.
The patch appears to cope with the latter case but not the former.
Should we disallow these things in CREATE FUNCTION, or make the patch
never match such functions, or what?
4. No attention has been given to making ruleutils.c list out named or
mixed function calls correctly.
5. I don't like anything about the leaky list representation of
analyzed function arguments. Having null subexpressions in unexpected
places isn't a good idea --- it's likely to cause crashes in code that
isn't being really cautious. Moreover, if we did ultimately support
mixed notation, there's no way to list it out correctly on the basis
of this representation, because you can't tell which arguments were
named and which weren't. I think it would be better to keep the
ArgExprs in the transformed parameter list and have the planner
remove them (and reorder the arguments if needed) when it does
default-argument expansion. Depending on what you think about point
#2, the transformed ArgExprs might need to carry the argument number
instead of the argument name, but in any case they'd just be there
for named arguments. This approach probably will also reduce the
amount of change in the parser, since you won't have to separate
the names from the argument list and pass those all over the place
separately.
Some minor style issues:
* ArgExpr is confusingly named and incorrectly documented, since it's
only used for named arguments. Perhaps NamedArgExpr would be better.
Also, it'd probably be a good idea to include a location field in it
(pointing at the parameter name not the argument expression).
* Most of the PG source code just writes short or long,
not short int. Actually I wonder whether int2 wouldn't
be preferred anyway, since that's how the relevant pg_proc
columns are declared.
* The error messages aren't even approximately conformant to style guide.
* Please avoid useless whitespace changes, especially ones as
ill-considered as this:
***
*** 10028,10034
;
! name: ColId
{ $$ = $1; };
database_name:
ColId
{ $$ = $1; };
--- 10056,10062
;
! name: ColId
{ $$ = $1; };
database_name:
ColId
{ $$ = $1; };
I'm going to mark the patch Waiting on Author, since it's not close
to being committable until these issues are resolved.
regards, tom lane
mnnotation.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
On Mon, Aug 24, 2009 at 20:51, Andrew Dunstanand...@dunslane.net wrote: Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: Oh, you mean move load_hba *down*, past the syslogger startup? Yeah, that would probably be all right. Well, that's what I originally said, yes ;-) But I don't think that precludes your more general suggestion regarding startup errors. In particular, I think moving the hba load down would be reasonable to backpatch to 8.4, whereas I doubt the general fix would. Well, the change I had in mind is only a few lines of code, and is fixing a behavior that you yourself are arguing is unusably broken. It seems like a reasonable back-patch candidate to me if we think this is a serious bug. But I personally wasn't seeing any of this as due for back-patching. The -S behavior has been like it is since forever, and nobody's complained before. We didn't check HBA validity at startup time before, did we? I would not be surprised to get more complaints now. We checked some of it, but we check it a whole lot more now. +1 for backpatching at least the move of the load_hba call. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 02:31:35PM -0400, Tom Lane wrote: David Fetter da...@fetter.org writes: He expected '-' to subtract seconds, just as '+' added them. Ah. Well, what it boils down to is that in a scenario like known_type_expr operator unknown_literal we preferentially consider unknown_literal to be of the same type as the other operand. But there's no timestamp plus timestamp operator (doesn't seem like a sensible operation to me, does it to you?), Doesn't seem sensible to me, either. so there's only one possible typing of the unknown literal, and it's not that. Plus and minus just aren't all that symmetrical in this situation. I'm thinking that the unknown literal here should just cause an error in the case of '+'. Same with '-', for what it's worth. Cheers, David (There's something happening here. What is ain't exactly clear.) -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hba load error and silent mode
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 24, 2009 at 20:51, Andrew Dunstanand...@dunslane.net wrote:
We didn't check HBA validity at startup time before, did we? I would not be
surprised to get more complaints now.
Good point.
We checked some of it, but we check it a whole lot more now.
+1 for backpatching at least the move of the load_hba call.
OK, in that case I think it's reasonable to backpatch into 8.4.
Attached is my work-in-progress changes to pmdaemonize --- I think
the code is good now, but I need to go say something in the docs.
I haven't moved the load_hba call yet.
regards, tom lane
Index: postmaster.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.589
diff -c -r1.589 postmaster.c
*** postmaster.c24 Aug 2009 18:09:37 - 1.589
--- postmaster.c24 Aug 2009 19:22:28 -
***
*** 191,197
/* still more option variables */
bool EnableSSL = false;
! bool SilentMode = false; /* silent mode (-S) */
int PreAuthDelay = 0;
int AuthenticationTimeout = 60;
--- 191,197
/* still more option variables */
bool EnableSSL = false;
! bool SilentMode = false; /* silent_mode */
int PreAuthDelay = 0;
int AuthenticationTimeout = 60;
***
*** 744,750
}
/*
!* Fork away from controlling terminal, if -S specified.
*
* Must do this before we grab any interlock files, else the interlocks
* will show the wrong PID.
--- 744,750
}
/*
!* Fork away from controlling terminal, if silent_mode specified.
*
* Must do this before we grab any interlock files, else the interlocks
* will show the wrong PID.
***
*** 1204,1218
/*
! * Fork away from the controlling terminal (-S option)
*/
static void
pmdaemonize(void)
{
#ifndef WIN32
! int i;
pid_t pid;
pid = fork_process();
if (pid == (pid_t) -1)
{
--- 1204,1249
/*
! * Fork away from the controlling terminal (silent_mode option)
! *
! * Since this requires disconnecting from stdin/stdout/stderr (in case they're
! * linked to the terminal), we re-point stdin to /dev/null and stdout/stderr
! * to postmaster.log in the data directory, where we're already chdir'd.
*/
static void
pmdaemonize(void)
{
#ifndef WIN32
! const char *pmlogname = postmaster.log;
! int dvnull;
! int pmlog;
pid_t pid;
+ int res;
+ /*
+* Make sure we can open the files we're going to redirect to. If this
+* fails, we want to complain before disconnecting. Mention the full
path
+* of the logfile in the error message, even though we address it by
+* relative path.
+*/
+ dvnull = open(DEVNULL, O_RDONLY, 0);
+ if (dvnull 0)
+ {
+ write_stderr(%s: could not open file \%s\: %s\n,
+progname, DEVNULL, strerror(errno));
+ ExitPostmaster(1);
+ }
+ pmlog = open(pmlogname, O_CREAT | O_WRONLY | O_APPEND, 0600);
+ if (pmlog 0)
+ {
+ write_stderr(%s: could not open log file \%s/%s\: %s\n,
+progname, DataDir, pmlogname,
strerror(errno));
+ ExitPostmaster(1);
+ }
+
+ /*
+* Okay to fork.
+*/
pid = fork_process();
if (pid == (pid_t) -1)
{
***
*** 1231,1238
MyStartTime = time(NULL);
/*
!* GH: If there's no setsid(), we hopefully don't need silent mode.
Until
!* there's a better solution.
*/
#ifdef HAVE_SETSID
if (setsid() 0)
--- 1262,1269
MyStartTime = time(NULL);
/*
!* Some systems use setsid() to dissociate from the TTY's process group,
!* while on others it depends on stdin/stdout/stderr. Do both if
possible.
*/
#ifdef HAVE_SETSID
if (setsid() 0)
***
*** 1242,1255
ExitPostmaster(1);
}
#endif
! i = open(DEVNULL, O_RDWR, 0);
! dup2(i, 0);
! dup2(i, 1);
! dup2(i, 2);
! close(i);
#else /* WIN32 */
/* not supported */
! elog(FATAL, SilentMode not supported under WIN32);
#endif /* WIN32 */
}
--- 1273,1298
ExitPostmaster(1);
}
#endif
!
! /*
!* Reassociate stdin/stdout/stderr. fork_process() cleared any pending
!* output, so this should be safe.
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 8:27 PM, David Fetterda...@fetter.org wrote: I'm thinking that the unknown literal here should just cause an error in the case of '+'. Same with '-', for what it's worth. That would make a lot of people very unhappy. They expect things like select date + '1 year' to just work. The problem is that they would also like select date - '1year' and select date - '2000-01-01' to work. I wonder if we could get around this by inventing a new type date_or_interval which looks at the input and decides which it is using fairly strict rules. date_sub would take that type and do the appropriate operation based on what the constant had in it. Of course we still want to be able to do date1 - date2 or date1+intervalcolumn so we would need implicit casts from date and interval to this new type. The question is whether we could arrange things so this implicit cast doesn't cause ambiguity elsewhere. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Feedback about Drupal SQL debugging
On fre, 2009-08-21 at 20:07 -0400, Tom Lane wrote: As of SQL99 it's supposed to be legal if you're grouping by a primary key (or some other cases where the other columns can be proved functionally dependent on the grouping columns, but that's the most useful one). We haven't got round to implementing that, but I'm not sure that it would make the Drupal code work anyway. Are they actually writing to spec here, or just doing whatever mysql will let them? BTW, I was under the impression there already *was* a TODO entry about improving our standards compliance in this area. I can't find it in the list right now, though. I added Add support for functional dependencies just now, with a comment how this relates to GROUP BY. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
Greg Stark gsst...@mit.edu writes: I wonder if we could get around this by inventing a new type date_or_interval which looks at the input and decides which it is using fairly strict rules. date_sub would take that type and do the appropriate operation based on what the constant had in it. Ick. This would be a pretty enormous blot on the type system to solve one special case, in a manner that would only be helpful to newbies who don't know that they ought to cast to eliminate the ambiguity. In fact it sounds quite a bit like the implicit-cast-to-text situations we just finished getting rid of ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 09:13:09PM +0100, Greg Stark wrote: On Mon, Aug 24, 2009 at 8:27 PM, David Fetterda...@fetter.org wrote: I'm thinking that the unknown literal here should just cause an error in the case of '+'. Same with '-', for what it's worth. That would make a lot of people very unhappy. They expect things like select date + '1 year' to just work. We broke a lot more things than this when we got rid of implicit casts to TEXT. :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
Josh Berkus wrote: All, Yeah, conference-based releases is just a proxy for time-based releases. It's nice to have something to be happy about at the conference too. And it's a convenient time to start talking about the next release when you're all face-to-face. On the one hand: I'd say that we go for the 3-CF release. I think we need to prove that we can do a time-based release once before a lot of people on this list will believe in it. If we do 4 CFs, we're in danger of still being in beta in late May ... and once conference and vacation season start, things get a lot slower. Mind you, it's possible that we can shorten the final CF and beta this time, but I wouldn't want to count on it. If we *can* shorten them, then 8.6 can have 4CFs. But we won't know until after we've done it. On the other hand: I think if we do another release without Standby/replication, we'll start to lose a lot of users. People are waiting on that, and a lot of folks were expecting it in 8.4. That is a slightly alarmist. Who are we going to lose these users to? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
Robert Haas wrote: As I've said before, I am presently of the opinion that Streaming Replication has little chance of making it into 8.5. This opinion is vulnerable to contrary evidence, like a new version of the patch showing up that shows massive progress. But the patch was bounced from CF 2009-07 for a whole series of architectural problems which have to be addressed before we can even get to implementation details, bugs, documentation, etc. Hot Standby is in better shape but amount of code cleanup needed is substantial and there is also quite a bit of 'git diff master | grep XXX' that needs to be gone through. I agree. I think it is unlikely we will have anything ready to commit for Streaming Replication or Hot Standby for the next commit-fest in mid-September, and if we go for a 3-CF (commit fest) release, that gives us only one final CF to get those features accepted, again unlikely. We are either going to need to go to a 4-CF release, change the way we are developing these patches, or both to get either in 8.5. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
Greg Stark gsst...@mit.edu wrote: David Fetterda...@fetter.org wrote: I'm thinking that the unknown literal here should just cause an error in the case of '+'. Same with '-', for what it's worth. That would make a lot of people very unhappy. They expect things like select date + '1 year' to just work. I realize I'm in a minority on this, but I would also prefer an error. I expect things like SELECT date + (INTERVAL '1' YEAR) to just work. This whole business of taking a perfectly explicit character string literal and treating it as an unknown literal until something in the surrounding context causes it to automagically resolve to any type kinda makes my skin crawl. I'd love to have a GUC to resolve character string literals to text when they're not in a context which makes them part of some other standard literal declaration. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 4:56 PM, Bruce Momjianbr...@momjian.us wrote: Robert Haas wrote: As I've said before, I am presently of the opinion that Streaming Replication has little chance of making it into 8.5. This opinion is vulnerable to contrary evidence, like a new version of the patch showing up that shows massive progress. But the patch was bounced from CF 2009-07 for a whole series of architectural problems which have to be addressed before we can even get to implementation details, bugs, documentation, etc. Hot Standby is in better shape but amount of code cleanup needed is substantial and there is also quite a bit of 'git diff master | grep XXX' that needs to be gone through. I agree. I think it is unlikely we will have anything ready to commit for Streaming Replication or Hot Standby for the next commit-fest in mid-September, and if we go for a 3-CF (commit fest) release, that gives us only one final CF to get those features accepted, again unlikely. We are either going to need to go to a 4-CF release, change the way we are developing these patches, or both to get either in 8.5. I don't think a 4-CF release is going to help. It's just going to be 2 more months before everything else that has been done gets released. Call me a pessimist if you will, but zero times an arbitrary number of CommitFests is still zero. The only solution here is to get more people working on these patches. I have volunteered to work on HS and would also be willing to work on SR. Work can be reviewing or actual code. But I cannot work on a patch I cannot see, and neither can anyone else. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
Robert Haas wrote: On Mon, Aug 24, 2009 at 4:56 PM, Bruce Momjianbr...@momjian.us wrote: Robert Haas wrote: As I've said before, I am presently of the opinion that Streaming Replication has little chance of making it into 8.5. ?This opinion is vulnerable to contrary evidence, like a new version of the patch showing up that shows massive progress. ?But the patch was bounced from CF 2009-07 for a whole series of architectural problems which have to be addressed before we can even get to implementation details, bugs, documentation, etc. ?Hot Standby is in better shape but amount of code cleanup needed is substantial and there is also quite a bit of 'git diff master | grep XXX' that needs to be gone through. I agree. ?I think it is unlikely we will have anything ready to commit for Streaming Replication or Hot Standby for the next commit-fest in mid-September, and if we go for a 3-CF (commit fest) release, that gives us only one final CF to get those features accepted, again unlikely. ?We are either going to need to go to a 4-CF release, change the way we are developing these patches, or both to get either in 8.5. I don't think a 4-CF release is going to help. It's just going to be 2 more months before everything else that has been done gets released. Call me a pessimist if you will, but zero times an arbitrary number of CommitFests is still zero. The only solution here is to get more people working on these patches. I have volunteered to work on HS and would also be willing to work on SR. Work can be reviewing or actual code. But I cannot work on a patch I cannot see, and neither can anyone else. Agreed, so we fall back to change the way we are developing these patches. I am hesistant to jump into managing these patches until they get their shot by their original authors in the September CF, but managing them starting in mid-October will probably be too late for them to get into 8.5. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Bruce Momjian wrote: So the problem is that our DELETE ... USING does not allow ANSI join syntax? Can that be added? Not sure about that. USING is already an extension to the standard, so if we extend it a bit more, it can't be a problem, can it? I don't see any very good way to extend the USING syntax to allow the target table to be outer-joined to something else. Some other systems allow it by letting you re-specify the target in the other clause, equivalently to DELETE FROM target t USING t LEFT JOIN other_table ot ON ... but we have always considered that the target is *not* to be identified with any member of the FROM/USING clause, so it would be a serious compatibility break to change that now. Let's look at this a little closer. We can use an alias in the DELETE FROM clause: test= DELETE FROM test t; test= DELETE FROM test t USING test; What we cannot currently do is reference test twice: test= DELETE FROM test USING test; ERROR: table name test specified more than once test= DELETE FROM test t USING test t; ERROR: table name t specified more than once As far as I understand it, allowing ANSI joins in USING would simple mean removing that error message and linking the two table aliases. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Monday 24 August 2009 3:51:31 pm Bruce Momjian wrote: folks were expecting it in 8.4. That is a slightly alarmist. Who are we going to lose these users to? the insane asylum? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 04:51:31PM -0400, Bruce Momjian wrote: Josh Berkus wrote: All, Yeah, conference-based releases is just a proxy for time-based releases. It's nice to have something to be happy about at the conference too. And it's a convenient time to start talking about the next release when you're all face-to-face. On the one hand: I'd say that we go for the 3-CF release. I think we need to prove that we can do a time-based release once before a lot of people on this list will believe in it. If we do 4 CFs, we're in danger of still being in beta in late May ... and once conference and vacation season start, things get a lot slower. Mind you, it's possible that we can shorten the final CF and beta this time, but I wouldn't want to count on it. If we *can* shorten them, then 8.6 can have 4CFs. But we won't know until after we've done it. On the other hand: I think if we do another release without Standby/replication, we'll start to lose a lot of users. People are waiting on that, and a lot of folks were expecting it in 8.4. That is a slightly alarmist. Who are we going to lose these users to? Sadly, to one of the MySQL forks. This is one of those cases (cf. the current thread on -advocacy) where pointy-hair-friendliness can really help or hurt us. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] revised hstore patch
Ron == Ron Mayer rm...@cheapcomplexdevices.com writes: At this point it's been 12 days since this was written and no updated patch has been posted, so I think it's well past time to move this to Returned with Feedback. Accordingly I'm going to make that change. Hopefully, an updated patch will be ready in time for the September CommitFest. Ron Curious if this patch is likely for 8.5 and/or if there's a Ron newer patch available. I've come across an application that it Ron seems well suited for, and would be happy to test whichever Ron version of the patch would be most useful for me to test Ron against. I'm planning to submit another version soon. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] alpha1 bundled -- please verify
On ons, 2009-08-19 at 19:11 +0200, Stefan Kaltenbrunner wrote: Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Alpha1 has been bundled and is available at http://developer.postgresql.org/~petere/alpha/ Please check that it is sane. It looks like all the derived grammar files have been built with bison 2.4.1, which is not what's on svr1 (unless that's been updated recently). I'm not sure that this is something to worry about, but it does mean that people will be testing something that's a bit different from what an official tarball would look like. correct - svr1 has bison 1.875 and flex 2.5.35 (for the -HEAD builds) and flex 2.5.4 for the back branches. I didn't realize that you had prepared special installations of those. Will use those next time. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
Greg Stark wrote: Also, the question arises what should be returned for hypot(Inf,NaN) which your code returns Inf for. Empirically, it seems the normal floating point behaviour is to return NaN so I think the NaN test should be first. See http://www.opengroup.org/onlinepubs/95399/functions/hypot.html If /x/ or /y/ is ±Inf, +Inf shall be returned (even if one of /x/ or /y/ is NaN). If /x/ or /y/ is NaN, and the other is not ±Inf, a NaN shall be returned. Just trying to implement correct C99 behaviour here. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
Kevin Grittner kevin.gritt...@wicourts.gov writes: I realize I'm in a minority on this, but I would also prefer an error. I expect things like SELECT date + (INTERVAL '1' YEAR) to just work. Uh, I think you're confused. That certainly works, and I didn't hear anyone proposing to change it. The issue is about undecorated literals. If we start throwing errors for those, the fallout will make the 8.3 implicit-cast changes look like a day at the beach. I believe that it would also violate the SQL spec in numerous places --- whether you like it or not, the concept of context-dependent type resolution is built into the standard. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
I think if we do another release without Standby/replication, we'll start to lose a lot of users. People are waiting on that, and a lot of folks were expecting it in 8.4. That is a slightly alarmist. Who are we going to lose these users to? Drizzle. MySQL forks. CouchDB. Any database which has replication which you don't need a professional DBA to understand. Whether or not it works. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
Bruce Momjian br...@momjian.us writes: What we cannot currently do is reference test twice: test= DELETE FROM test USING test; ERROR: table name test specified more than once test= DELETE FROM test t USING test t; ERROR: table name t specified more than once Hmm, I had forgotten that we throw errors in these cases now. Maybe that *would* give us an escape-hatch for the other interpretation. As far as I understand it, allowing ANSI joins in USING would simple mean removing that error message and linking the two table aliases. Well, you'd still need to complain about DELETE FROM test USING test JOIN test ON ... Also, it's not nearly as easy as just removing the error check. There's stuff in the planner (and perhaps executor) that's dependent on the assumption that the target table isn't on the inside of an outer join, for example. Still, getting agreement on a syntax would in itself be a huge step forward. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
Josh Berkus j...@agliodbs.com writes: That is a slightly alarmist. Who are we going to lose these users to? Drizzle. MySQL forks. CouchDB. Any database which has replication which you don't need a professional DBA to understand. Whether or not it works. You haven't explained why we'd lose such folk next year when we haven't lost them already. MySQL has had replication (or at least has checked off the bullet point ;-)) for years. I'd be seriously surprised if any of the forks will offer significantly better replication than is there now, so the competitive situation is not changing in that regard. It is true that we're missing a chance to pull some folks away while the situation on that side of the fence is so messy. But I don't see our situation getting worse because of that, just not getting better. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
Paul Matthews p...@netspace.net.au writes: Just trying to implement correct C99 behaviour here. Around here we tend to read the Single Unix Spec before C99, and SUS saith something different: http://www.opengroup.org/onlinepubs/007908799/xsh/hypot.html It would be serious folly for us to suppose that every platform's version of hypot() behaves exactly the same for these corner cases, anyway. If you're proposing to write code that would depend on that, we need to call it something else and not pretend that it's just a fill-in for platforms that lack hypot() entirely. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
On Mon, Aug 24, 2009 at 07:48:06PM -0400, Tom Lane wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: I realize I'm in a minority on this, but I would also prefer an error. I expect things like SELECT date + (INTERVAL '1' YEAR) to just work. Uh, I think you're confused. That certainly works, and I didn't hear anyone proposing to change it. The issue is about undecorated literals. If we start throwing errors for those, the fallout will make the 8.3 implicit-cast changes look like a day at the beach. I believe that it would also violate the SQL spec in numerous places --- whether you like it or not, the concept of context-dependent type resolution is built into the standard. As far as you can tell, does the standard speak to adding an untyped literal to a time format? The draft standard I have here lists, Valid operators involving datetimes and intervals as, Operand 1 Operator Operand 2 Result Type Datetime – Datetime Interval Datetime + or – Interval Datetime Interval + Datetime Datetime Interval + or – Interval Interval Interval * or / Numeric Interval Numeric * Interval Interval It's not crystal clear to me whether any type coercion behavior is mandated here, or which kind, if there is some. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Slaying the HYPOTamus
On Tue, Aug 25, 2009 at 1:14 AM, Tom Lanet...@sss.pgh.pa.us wrote: Paul Matthews p...@netspace.net.au writes: Just trying to implement correct C99 behaviour here. Around here we tend to read the Single Unix Spec before C99, and SUS saith something different: It doesn't seem to anticipate NaN at all. Neither of these seems on-point since we're neither implementing SuS nor a C compiler. In fact we're not even implementing hypot(). We're implementing things like box_distance and point_distance which as it happens will already be doing earlier arithmetic on the doubles, so whatever HYPOT() does had better be consistent with that or the results will be just an inexplicable mishmash. Incidentally, what on earth does it mean to multiply or divide a circle by a point? -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Bug in visibility hint bit
There seems to be a bug in the visibility map in 8.4.0, introduced to
cvs on 2008-12-03. It results in tuples being called visible that
shouldn't be.
In heap_update function from heapam.c:
/*
* Note: we mustn't clear PD_ALL_VISIBLE flags before writing the WAL
* record, because log_heap_update looks at those flags to set the
* corresponding flags in the WAL record.
*/
So the full_page_write of the block sent to WAL has the wrong
PD_ALL_VISIBLE. It needs to be fixed during WAL replay after a crash.
But it is not.
In heap_xlog_update:
if (record-xl_info XLR_BKP_BLOCK_1)
{
if (samepage)
return; /* backup
block covered both changes */
goto newt;
}
The goto newt causes it to skip the code that would have called
PageClearAllVisible.
I don't feel particularly competent to propose a patch for this. It
seems to me that
log_heap_update should be sent the correct block in the first place,
and some other
method should be used to communicate between heap_update and log_heap_update
if communication is necessary. But really, I don't think such
communication should be necessary, and the xlrec.all_visible_cleared
and xlrec.new_all_visible_cleared fields are unneeded. Just assume
they are true. It seems like the worst thing that can happen is that
we call PageClearAllVisible when it is already cleared, which is
hardly harmful (the blocks that have redo applied to them are already
dirty, so a spurious clear doesn't cause unneeded IO)
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Reworks for Access Control facilities (r2251)
The following url is a patch to rework access control facilities in PostgreSQL. http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz The current implementation does not have well separation in what to be controled and how to be controled. For example, when we create a new table, it requires users ACL_CREATE on the namespace and ACL_CREATE on the tablespace if necessary. These checks are methods to control whether he can create a new table, or not. This patch provides an abstraction layer of access controls to separate what to be controlsed and how to be controled. The abstraction layer is a set of functions to implement what to be controled. For example, ac_relation_create() checks user's privilege to create a new table. It internally calls pg_namespace_aclcheck() and pg_tablespace_aclcheck() to make its access control decision based on the security model in database ACLs. This abstraction layer functions have the following naming convension. ac_object type_action(args, ...) e.g) void ac_proc_execute(Oid proOid, Oid roleOid) It checks privilege to execute a certain procedure with the given database role. The caller gives all the necessary informations to make its decision. It replaces all the pg_xxx_aclcheck() and pg_xxx_ownercheck() invocations from the backend implementations, except for security/access_control.c. In this patch, these are used as helper functions to implement access control logic (in other word, how to be controled), invoked from the access control functions. These ac_xxx_xxx() routines will be entrypoints to invoke additional security checks (SE-PostgreSQL), rather than sepgsql() hooks around the backend implementation. Thanks, $ diffstat sepgsql-01-base-8.5devel-r2251.patch.gz backend/Makefile |2 backend/catalog/aclchk.c | 218 ! backend/catalog/namespace.c | 53 backend/catalog/pg_aggregate.c| 12 backend/catalog/pg_conversion.c | 33 backend/catalog/pg_operator.c | 42 backend/catalog/pg_proc.c | 15 backend/catalog/pg_shdepend.c |8 backend/catalog/pg_type.c | 25 backend/commands/aggregatecmds.c | 42 backend/commands/alter.c | 66 backend/commands/analyze.c|5 backend/commands/cluster.c|9 backend/commands/comment.c| 120 backend/commands/conversioncmds.c | 71 backend/commands/copy.c | 40 backend/commands/dbcommands.c | 160 ! backend/commands/foreigncmds.c| 144 backend/commands/functioncmds.c | 123 backend/commands/indexcmds.c | 120 backend/commands/lockcmds.c | 17 backend/commands/opclasscmds.c| 223 ! backend/commands/operatorcmds.c | 70 backend/commands/proclang.c | 56 backend/commands/schemacmds.c | 60 backend/commands/sequence.c | 38 backend/commands/tablecmds.c | 427 -! backend/commands/tablespace.c | 46 backend/commands/trigger.c| 41 backend/commands/tsearchcmds.c| 176 ! backend/commands/typecmds.c | 136 ! backend/commands/vacuum.c |3 backend/commands/view.c |7 backend/executor/execMain.c | 203 ! backend/executor/execQual.c | 16 backend/executor/nodeAgg.c| 24 backend/executor/nodeMergejoin.c |8 backend/executor/nodeWindowAgg.c | 24 backend/optimizer/util/clauses.c |6 backend/parser/parse_utilcmd.c| 13 backend/rewrite/rewriteDefine.c | 10 backend/rewrite/rewriteRemove.c |6 backend/security/Makefile | 10 backend/security/access_control.c | 4290 ++ backend/tcop/fastpath.c | 15 backend/tcop/utility.c| 74 backend/utils/adt/dbsize.c| 25 backend/utils/adt/ri_triggers.c | 24 backend/utils/adt/tid.c | 18 backend/utils/init/postinit.c | 14 include/catalog/pg_proc_fn.h |1 include/commands/defrem.h |1 include/utils/security.h | 337 ++ 53 files changed, 5027 insertions(+), 924 deletions(-), 1776 modifications(!) -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DELETE syntax on JOINS
All, DELETE FROM target t USING t LEFT JOIN other_table ot ON ... but we have always considered that the target is *not* to be identified with any member of the FROM/USING clause, so it would be a serious compatibility break to change that now. What I don't get is why this is such a usability issue. Subqueries in DELETE FROM work perfectly well, and provide more flexibility than most users know what to do with. Personally, I'd be happy just to stop with the SQL extension we have. I think extending USING any further is going to cause more problems than it solves. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in visibility hint bit
On Mon, Aug 24, 2009 at 6:23 PM, Jeff Janesjeff.ja...@gmail.com wrote: There seems to be a bug in the visibility map in 8.4.0, introduced to cvs on 2008-12-03. It results in tuples being called visible that shouldn't be. Well, never mind. It took me a few days to track down the bug and in the mean time I didn't want to rsync the CVS repository and lose my own local against it. So once I'm done I rsync and see that Tom already patched it yesterday. Cheers, Jeff
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 08:02:31PM -0400, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: That is a slightly alarmist. Who are we going to lose these users to? Drizzle. MySQL forks. CouchDB. Any database which has replication which you don't need a professional DBA to understand. Whether or not it works. You haven't explained why we'd lose such folk next year when we haven't lost them already. MySQL has had replication (or at least has checked off the bullet point ;-)) for years. I'd be seriously surprised if any of the forks will offer significantly better replication than is there now, so the competitive situation is not changing in that regard. It is true that we're missing a chance to pull some folks away while the situation on that side of the fence is so messy. But I don't see our situation getting worse because of that, just not getting better. Not getting better, isn't a situation to be dismissed lightly. In FLOSS, as I've seen it, a project whose adoption isn't growing is dying. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in date arithmetic
Tom, we preferentially consider unknown_literal to be of the same type as the other operand. I can't really think of what other assumption we would make. Any time a user doesn't specify a type, they're taking pot luck. Me, I always use some_timestamp + INTERVAL 'value' -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Reworks for Access Control facilities (r2251)
KaiGai Kohei wrote: The following url is a patch to rework access control facilities in PostgreSQL. http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz IIRC, the limitation of attachment was 40kb, so I resent it using a pointing URL instead of attachment, sorry for same messages. BTW, was it expanded? -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in visibility hint bit
Jeff Janes escribió: On Mon, Aug 24, 2009 at 6:23 PM, Jeff Janesjeff.ja...@gmail.com wrote: There seems to be a bug in the visibility map in 8.4.0, introduced to cvs on 2008-12-03. It results in tuples being called visible that shouldn't be. Well, never mind. It took me a few days to track down the bug and in the mean time I didn't want to rsync the CVS repository and lose my own local against it. So once I'm done I rsync and see that Tom already patched it yesterday. Congratulations on finding it independently. We welcome your eyes on our code ;-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Reworks for Access Control facilities (r2251)
KaiGai Kohei wrote: KaiGai Kohei wrote: The following url is a patch to rework access control facilities in PostgreSQL. http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz IIRC, the limitation of attachment was 40kb, so I resent it using a pointing URL instead of attachment, sorry for same messages. Actually the message with the big attachment was delivered and is on the archives: http://archives.postgresql.org/message-id/4a93480c@ak.jp.nec.com -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 release timetable, again
On Mon, Aug 24, 2009 at 10:15 PM, David Fetterda...@fetter.org wrote: On Mon, Aug 24, 2009 at 08:02:31PM -0400, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: That is a slightly alarmist. Who are we going to lose these users to? Drizzle. MySQL forks. CouchDB. Any database which has replication which you don't need a professional DBA to understand. Whether or not it works. You haven't explained why we'd lose such folk next year when we haven't lost them already. MySQL has had replication (or at least has checked off the bullet point ;-)) for years. I'd be seriously surprised if any of the forks will offer significantly better replication than is there now, so the competitive situation is not changing in that regard. It is true that we're missing a chance to pull some folks away while the situation on that side of the fence is so messy. But I don't see our situation getting worse because of that, just not getting better. Not getting better, isn't a situation to be dismissed lightly. In FLOSS, as I've seen it, a project whose adoption isn't growing is dying. You may be right, but I'm not sure that it has much to do with the ostensible topic of this thread. The reason why these features have not already been committed is because they are not done. The question of why they are not done and/or why more people aren't working on them has been asked and answered. Figuring out some concrete steps that we can take to address those issues is probably a better use of time than trying to define whether these features are really important or really, really important. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
