Re: [HACKERS] [PATCH] Largeobject access controls
Itagaki Takahiro wrote:
KaiGai Kohei kai...@ak.jp.nec.com wrote:
The pg_largeobject system catalog is reworked to manage its metadata.
CATALOG(pg_largeobject,2613)
{
Oid loowner;/* OID of the owner */
Oid lochunk;/* OID of the data chunks */
aclitem loacl[1]; /* access permissions */
} FormData_pg_largeobject;
Actual data chunks are stored in the toast relation of pg_largeobject,
and its chunk_id is stored in the pg_largeobject.lochunk.
A bit acrobatic, but insteresting idea.
I have some random comments:
* Do you measure performance of the new LO implementation?
AFAIK, Users expect performance benefits to LO; TOASTed
bytea slows down when the size of data is 100KB or greater
even if they don't use random seeks.
Not yet. Can you recommend commonly-used workload?
* We might take care of DROP ROLE and REASSIGN/DROP OWNED.
Or, we might have large object without owner.
It might require full-scanning of pg_largeobject table,
but we can accept it because the size of pg_largeobject
will be smaller; we have actual data out of the table.
I think it should be implemented using the dependency mechanism.
It requires full-scanning on the pg_shdepend tables, but it has
been accepted.
* Don't we also need ALTER LARGE OBJECT oid OWNER TO user
for consistency?
Agreed. It will be also necessary to implement REASSIGN OWNED.
Thanks,
--
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] 8.5 release timetable, again
On Thu, 27 Aug 2009, Ron Mayer wrote: The Linux kernel seems to do fine with a when it is ready cycle, where some releases(2.6.24) take twice the time of others(2.6.28)[1,2]. [2] http://fblinux.freebase.com/view/base/fblinux/views/linux_kernel_release That link has bad data. If you check the tagging dates by looking at the source material here: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28 You can see that 2.6.28 didn't come out until 2008-12-14, not the 2008-10-24 claimed on the freebase.com site. I imagine it has similar stability and lack-of-data-loss requirements as postgres does. The Linux kernel developers are very clear that they don't care one bit about testing for stability or lack of data loss in any system-oriented way. That's somebody else's job now, typically the Linux distributor who decides which of the kernels floating around are the most stable, hopefully running more and larger tests than the kernel developers do. For example, if you consider Ubuntu 9.04 Jaunty, development started with 2.6.27, upgraded to 2.6.28, then rejected moving to 2.6.29 even though they might have slipped it in.[1] When faced with the similar decision for 2.6.26 vs. 2.6.27 in the previous release, they went for the later one, based on the features they needed to be stable.[2] It's really amazing that a useful result ever comes out of this model at all, and I know I'm not alone that I presume all Linux kernel releases are too full of bugs to be useful until I've proven otherwise with my own QA. If the core PostgreSQL development worked like the Linux kernel, at the end of each CommitFest whatever was done at that point would get published as the new release. Instead of pausing to focus on a stable release everyone would just speed ahead, backporting any major issues not discovered until after the official release. [1] http://www.h-online.com/news/No-2-6-29-kernel-for-Jaunty-Jackalope--/112636 [2] https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026142.html -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- 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] Memory context usage
On Fri, 28 Aug 2009, Tom Lane wrote: MemoryContextStats() might help. It just dumps the info to stderr though. Which means it ends up in the database log files in the common configuration where where the database's stderr is redirected to there. I even script running this regularly against stuff I'm suspicious of, using something like this passed the PID of the process I want to watch: #!/bin/bash gdb -p $1 EOF p MemoryContextStats(TopMemoryContext) detach quit EOF -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] phypot - Pygmy Hippotause ?
Another attempt at replacing the current HYPOT macro with a much better
behaved function. I've added comments addressing those sections of code
that tripped people up before. As well as explaining some of the design
decisions. Feedback appreciated.
Index: src/backend/utils/adt/geo_ops.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.103
diff -c -r1.103 geo_ops.c
*** src/backend/utils/adt/geo_ops.c 28 Jul 2009 09:47:59 - 1.103
--- src/backend/utils/adt/geo_ops.c 28 Aug 2009 08:11:00 -
***
*** 32,37
--- 32,38
* Internal routines
*/
+ static double phypot(double x, double y);
static intpoint_inside(Point *p, int npts, Point *plist);
static intlseg_crossing(double x, double y, double px, double py);
static BOX *box_construct(double x1, double x2, double y1, double y2);
***
*** 825,831
box_cn(a, box1);
box_cn(b, box2);
! PG_RETURN_FLOAT8(HYPOT(a.x - b.x, a.y - b.y));
}
--- 826,832
box_cn(a, box1);
box_cn(b, box2);
! PG_RETURN_FLOAT8(phypot(a.x-b.x, a.y-b.y));
}
***
*** 1971,1977
Point *pt1 = PG_GETARG_POINT_P(0);
Point *pt2 = PG_GETARG_POINT_P(1);
! PG_RETURN_FLOAT8(HYPOT(pt1-x - pt2-x, pt1-y - pt2-y));
}
double
--- 1972,1978
Point *pt1 = PG_GETARG_POINT_P(0);
Point *pt2 = PG_GETARG_POINT_P(1);
! PG_RETURN_FLOAT8(phypot(pt1-x - pt2-x, pt1-y - pt2-y));
}
double
***
*** 1979,1987
{
#ifdef GEODEBUG
printf(point_dt- segment (%f,%f),(%f,%f) length is %f\n,
! pt1-x, pt1-y, pt2-x, pt2-y, HYPOT(pt1-x - pt2-x, pt1-y -
pt2-y));
#endif
! return HYPOT(pt1-x - pt2-x, pt1-y - pt2-y);
}
Datum
--- 1980,1988
{
#ifdef GEODEBUG
printf(point_dt- segment (%f,%f),(%f,%f) length is %f\n,
! pt1-x, pt1-y, pt2-x, pt2-y, phypot(pt1-x - pt2-x, pt1-y -
pt2-y));
#endif
! return phypot(pt1-x - pt2-x, pt1-y - pt2-y);
}
Datum
***
*** 2444,2450
dist_pl_internal(Point *pt, LINE *line)
{
return (line-A * pt-x + line-B * pt-y + line-C) /
! HYPOT(line-A, line-B);
}
Datum
--- 2445,2451
dist_pl_internal(Point *pt, LINE *line)
{
return (line-A * pt-x + line-B * pt-y + line-C) /
! phypot(line-A, line-B);
}
Datum
***
*** 4916,4922
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius *= HYPOT(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
--- 4917,4923
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius *= phypot(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
***
*** 4936,4942
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius /= HYPOT(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
--- 4937,4943
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius /= phypot(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
***
*** 5401,5403
--- 5402,5468
return FALSE;
}
+
+
+ /*-
+ * Determine the hypotenuse.
+ *
+ * If required, x and y are swapped to make x the larger number. The
+ * traditional formulae of x^2+y^2 is rearranged to factor x outside the
+ * sqrt. This allows computation of the hypotenuse for significantly
+ * larger values, and with a higher precision than otherwise normally
+ * possible.
+ *
+ * Only arguments of 1.27e308 are at risk of causing overflow. Whereas
+ * the naive approach limits arguments to 9.5e153.
+ *
+ * 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 )
+ *
+ * It is expected that this routine will eventually be replaced with the
+ * C99 hypot() function.
+ *
+ * This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the
+ * case of hypot(inf,nan) results in INF, and not NAN. To obtain Single
+ * UNIX Specification behaviour, swap the order of the isnan() and isinf()
+ * test sections.
+ *
+ * The HYPOT macro this function is replacing did not check for, or
+ * signal on overflow. In addition no
Re: [HACKERS] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 09:38:15PM +0200, Dimitri Fontaine wrote: Exactly, and I think that what we're missing here is a simple tool for our users to check a new PostgreSQL release against their existing application. We already know how to either log all queries and analyze the log files (CSV makes it easier, pgfouine parses them too) or to have a fe/be protocol proxy to record application SQL traffic (tsung recorder does that). What we miss is a tool to run the captured queries through both versions of PG and report any resultset mismatch, of course with a way to account for ordering issues (but we've seen people rely on the ordering when they don't give an order by clause, then bug the lists about it if a new release changes it). This would be very useful. I often am asked how much better will the new release run our apps as part of convincing a client to upgrade to a more current postgresql release. Being able to replay a days workload in a somewhat realistic manner would be a great help. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- 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
Greg Smith wrote: The Linux kernel developers are very clear that they don't care one bit about testing for stability or lack of data loss in any system-oriented way. That's somebody else's job now, typically the Linux distributor who decides which of the kernels floating around are the most stable, hopefully running more and larger tests than the kernel developers do. Right. And we are not in any position to do that, even if we wanted to. The Linux kernel is a great example of how we don't want to do it, IMNSHO. We need to enhance our testing to preserve our reputation for stability and reliability, not throw the responsibility over the fence. 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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 08:02:03PM -0700, Ron Mayer wrote: Andrew Dunstan wrote: I don't know of anyone who is likely to want to try out alphas in their normal development environments. The client I approached was specifically prepared to test beta releases that way. Perhaps end-users won't, but I think companies who develop software that works on top of postgres will. Perhaps to make sure their existing software continues to work; or perhaps to get a head start working with new features. I test against CVS-head occasionally. I've been trying to help a client take up new versions of postgresql more quickly as the performance or feature content is often very valuable to them. Accordingly, I have encouraged them to run periodic samples of the nightly snapshots on at least one development instance, and to run the betas in the test environment. The goal is to be confident on the day of the postgresql release that we have tested enough and fixed any incompatibilities so that, if they so choose, they could migrate production to the new release immediately. This way they get several months extra benefit from improvements to postgresql. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- 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 Fri, Aug 28, 2009 at 7:35 AM, Greg Smithgsm...@gregsmith.com wrote: It's really amazing that a useful result ever comes out of this model at all, and I know I'm not alone that I presume all Linux kernel releases are too full of bugs to be useful until I've proven otherwise with my own QA. If the core PostgreSQL development worked like the Linux kernel, at the end of each CommitFest whatever was done at that point would get published as the new release. Instead of pausing to focus on a stable release everyone would just speed ahead, backporting any major issues not discovered until after the official release. The lesson that they took from earlier releases was that pausing development just led to heartache and delays and didn't actually help the release at all. Keep in mind that the Linux kernel itself is just an integration effort now anyways. All the actual development happens in other trees earlier anyways. Patches are only sent up to Linux when they've been fully developed (and hopefully somewhat tested) elsewhere. The arguments against the Linux approach are that a) it involves a lot of backpatching which is a pain. This is less convincing than it appears because the more often you fork branches the less different they all are. b) Our developers are also our testers and we don't have independent distribution vendors available to do testing. Actually we do, aside from people like EDB who have large test suites we're discussing how to get more testing from users precisely because our developers aren't really our testers. The big difference between Linux and ourselves is that it's a lot more work to migrate a database. So nobody would be particularly helped by having frequent releases. It would make a lot of sense even for us when the day comes that most people just run whatever Redhat or Debian ship. In which case we could come out with releases but users would happily ignore those releases until Redhat or Debian picked out, tested it, and released it in their distributions. -- 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] Memory context usage
On Fri, Aug 28, 2009 at 5:18 AM, Greg Smithgsm...@gregsmith.com wrote: On Fri, 28 Aug 2009, Tom Lane wrote: MemoryContextStats() might help. It just dumps the info to stderr though. Which means it ends up in the database log files in the common configuration where where the database's stderr is redirected to there. I even script running this regularly against stuff I'm suspicious of, using something like this passed the PID of the process I want to watch: #!/bin/bash gdb -p $1 EOF p MemoryContextStats(TopMemoryContext) detach quit EOF -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD Is there another way to get it in the source code? I need to control the size of a memory context on the fly and take some actions when the used memory exceeds a defined size. Thanks Adriano -- 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
Greg Stark wrote: They basically don't do any integration testing and leave that up to the distributions now. Instead they have an rc release *every week* like clockwork and every 2-3 months the last one becomes a new version regardless of whether there's any notable new feature. They have a two week merge period during which all patches of any importance are merged. The RCs are released after that, and they are supposed to include only bugfixes to the merged patches. Some things are still merged after the merge window is closed, but they are very few. They release as many RCs as are necessary to close the majority of bugs/regressions. So yeah, they have some of the time-based nature, but they also use the when it's ready philosophy a lot. -- 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] Memory context usage
Adriano Lange alange0...@gmail.com writes: I need to control the size of a memory context on the fly and take some actions when the used memory exceeds a defined size. The existing places that do that sort of thing do their own counting of how much they've allocated. 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
[HACKERS] StringInfo Macros
Hi, trying to clean up the Postgres-R code further, I would like to make use of StringInfo and accompanying functions in libpq/pqformat.c instead of some home-brown duplicate of it. However, I'm missing helper macros like these (mainly for readability of the code): #define BUFFER_START_PTR(buffer) ((buffer)-data)) #define BUFFER_END_PTR(buffer) ((buffer)-data + (buffer)-len) #define BUFFER_CURSOR_PTR(buffer) ((buffer)-data + (buffer)-cursor) #define BUFFER_BYTES_FREE(buffer) ((buffer)-maxlen - (buffer)-len) #define BUFFER_BYTES_READABLE(buffer) ((buffer)-len - (buffer)-cursor) Is there any compelling reason these don't exist (and shouldn't get added)? IF not, I'd be happy to create a patch to add and make use of such macros. Regards Markus Wanner -- 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: Review handling of MOVE and FETCH (ToDo)
Pavel Stehule pavel.steh...@gmail.com wrote: this small patch complete MOVE support in plpgsql and equalize plpgsql syntax with sql syntax. Quick correction on the doc changes: s/similar as for/similar to/ -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] StringInfo Macros
Markus Wanner mar...@bluegap.ch writes: trying to clean up the Postgres-R code further, I would like to make use of StringInfo and accompanying functions in libpq/pqformat.c instead of some home-brown duplicate of it. However, I'm missing helper macros like these (mainly for readability of the code): #define BUFFER_START_PTR(buffer) ((buffer)-data)) #define BUFFER_END_PTR(buffer) ((buffer)-data + (buffer)-len) #define BUFFER_CURSOR_PTR(buffer) ((buffer)-data + (buffer)-cursor) #define BUFFER_BYTES_FREE(buffer) ((buffer)-maxlen - (buffer)-len) #define BUFFER_BYTES_READABLE(buffer) ((buffer)-len - (buffer)-cursor) Is there any compelling reason these don't exist (and shouldn't get added)? IF not, I'd be happy to create a patch to add and make use of such macros. Don't call them BUFFER_FOO --- that term already has a pretty specific meaning in most of the backend. STRINGINFO_FOO is a bit long but seems to fit the best with the existing naming in stringinfo.h. A number of the specific things you are proposing above seem to be violations of the abstraction stringinfo is meant to present. It's a string, and the fact that there's any extra space beyond the end of the string is an internal matter. In particular I wonder exactly what you think END_PTR or BYTES_FREE would be used for. Also, the cursor field is meant to be manipulated directly by calling code, so I'm not sure how much value there's going to be in abstracting that. CURSOR_PTR as shown above seems a bit dangerous --- it might encourage someone to hold onto such a pointer across a StringInfo operation that could move buffer-data. Although maybe I'm overthinking that, since someone could try that with or without a macro :-( 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] return a set of records
2009/8/28 Andrew Dunstan and...@dunslane.net: You function doesn't look too immutable. Is it really? Hi, I fixed that, but the server continues to crash, where can I see a full example of something using the SRF functions to parse a query? All examples I see set the columns, but I parse a query that I don't have any information about attrs. thanks -- 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] Largeobject access controls
KaiGai Kohei kai...@ak.jp.nec.com writes: The attached patch provides access control features on largeobject. This patch adds the ownership and two permissions (SELECT and UPDATE) on largeobjects. The two permissions controls reader and writer accesses to the largeobejcts. What about DELETE permissions? Should we track that separately from UPDATE? The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT. It enables to controls whether the user can create a largeobject, or not. I don't think this is necessary or appropriate. The pg_largeobject system catalog is reworked to manage its metadata. Actual data chunks are stored in the toast relation of pg_largeobject, This seems like a very confusing design, and one that (a) breaks existing code to no purpose, (b) will greatly complicate in-place upgrade. Instead of abusing a toast relation to do something nonstandard, keep pg_largeobject as it is now and add a new, separate catalog that carries ownership and permissions info for each LO OID. 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] phypot - Pygmy Hippotause ?
Paul Matthews p...@netspace.net.au wrote: Feedback appreciated. + /* As x is the larger value, this must be the correct answer. Also + * avoids division by zero. */ + if( x == 0.0 ) + return 0.0; + + /* Trivial case. */ + if( y == 0.0 ) + return x; The first test seems unnecessary if you have the second. x = 0, so x can't be zero unless y is, too. Returning x on y == 0.0 will return 0.0 whenever x == 0.0. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] UPDATE .. RETURNING OLD.*
Hi everyone, Today I needed a feature like $subject. The use case was: UPDATE foo SET bar = bar + 1 WHERE id=$1, but I wanted to only do it when bar was 0. In order to give the user an informative error message, I also needed to distinguish the two cases: a row with id = $1 doesn't exist, and bar was 0, so I couldn't put bar != 0 into the WHERE clause. This time I got around it by using RETURNING bar and checking that it was 1 on the client side, but I can come up with other cases where you can't do that. Comments? Regards, Marko Tiikkaja -- 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] Largeobject access controls
Tom Lane wrote: KaiGai Kohei kai...@ak.jp.nec.com writes: The attached patch provides access control features on largeobject. This patch adds the ownership and two permissions (SELECT and UPDATE) on largeobjects. The two permissions controls reader and writer accesses to the largeobejcts. What about DELETE permissions? Should we track that separately from UPDATE? PostgreSQL checks ownership of the database object when user tries to drop it. This patch also add pg_largeobject_ownercheck() on lo_unlink(). The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT. It enables to controls whether the user can create a largeobject, or not. I don't think this is necessary or appropriate. What should control privilege to create a new largeobject? Or, it implicitly allows everyone to create a new one? The pg_largeobject system catalog is reworked to manage its metadata. Actual data chunks are stored in the toast relation of pg_largeobject, This seems like a very confusing design, and one that (a) breaks existing code to no purpose, (b) will greatly complicate in-place upgrade. Instead of abusing a toast relation to do something nonstandard, keep pg_largeobject as it is now and add a new, separate catalog that carries ownership and permissions info for each LO OID. It was the original design just before the first commit fest. :-) I don't have any reason to oppose to it. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- 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] Largeobject access controls
KaiGai Kohei kai...@kaigai.gr.jp writes: Tom Lane wrote: What about DELETE permissions? Should we track that separately from UPDATE? PostgreSQL checks ownership of the database object when user tries to drop it. This patch also add pg_largeobject_ownercheck() on lo_unlink(). Oh, okay, that will do fine. The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT. It enables to controls whether the user can create a largeobject, or not. I don't think this is necessary or appropriate. What should control privilege to create a new largeobject? Or, it implicitly allows everyone to create a new one? We have not had any requests to keep people from creating LOs, so I think we can just implicitly allow everyone. If we were going to try to manage it, I don't think a role attribute is a very good solution. It's not grantable or inheritable, it can't be managed per-database, etc. So I'd leave this out until there's some popular demand. 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
Ron Mayer rm...@cheapcomplexdevices.com wrote: Josh Berkus wrote: There's some very good reasons for the health of the project to have specific release dates and stick to them. Help me understand why? I don't know how many places are like this, but to get any significant staff or hardware resources officially allocated to anything here, you need a minimum of three months lead time. (Less, of course, if things are crashing and burning around our users' ears; more if the managers don't see an immediate and direct benefit to the users.) Any hope of organized participation by the Wisconsin Courts in a beta program would require a date they can put on their calendars and schedule around with confidence. As it is, what I do is based on having permission to run tests on my own time when there are hardware resources I can find to use which won't disrupt anything. From my perspective, a hard date for the beta release is more important than a hard date for the production release. Management here is very easy to sell on the concept that PostgreSQL stays in beta testing until there is confidence that the release is stable and trustworthy. -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] [PATCH] Largeobject access controls
The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT. It enables to controls whether the user can create a largeobject, or not. I don't think this is necessary or appropriate. What should control privilege to create a new largeobject? Or, it implicitly allows everyone to create a new one? We have not had any requests to keep people from creating LOs, so I think we can just implicitly allow everyone. If we were going to try to manage it, I don't think a role attribute is a very good solution. It's not grantable or inheritable, it can't be managed per-database, etc. So I'd leave this out until there's some popular demand. OK, I'll keep the current behavior (it allows everyone to create it). BTW, currently, the default ACL of largeobject allows anything for owner and nothing for world. Do you have any comment for the default behavior? Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- 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] Getting rid of the flat authentication file
I'm back on the warpath about $SUBJECT. (Aside from any other reason to do it, it occurs to me that we really need to get rid of the flat files for Hot Standby. Otherwise we'd need some way to keep them up to date during WAL replay.) I wrote earlier: The easy way to do it would be to postpone authentication until after we have selected and entered a database. At that point we could use existing code such as is_member_of_role(). There is a security disadvantage to that: you would find out whether the database name you'd given was valid before any authentication check occurred. Since database names are often also user names, that would give a brute-force attacker a leg up on discovering valid user names. Plan B is to use the same techniques for reading pg_authid and pg_auth_members as InitPostgres is now using for reading pg_database. I've thought of an easier way to handle this: if the given database name is invalid, connect to database postgres instead, and perform authentication using normal access to the pg_auth catalogs. If authentication succeeds, *then* throw the error about nonexistent database. If postgres is not there, we'd still expose existence of the original database name early, but how many installations don't have that? (I thought about trying template1 and/or template0 as fallbacks, but that's probably not a good thing. Backends that are waiting on a client for authentication would pose a DOS problem for sessions trying to do CREATE DATABASE, if they're connected to those.) Because this would all happen before the checks on permission to connect to the DB, it would still work as desired if, say, postgres exists but is marked not datallowconn. So anyone who was paranoid enough to not want DB postgres to be accessible could mark it that way instead of deleting it. This would avoid duplicating the is_member_of_role() logic so I'm tempted to do it like this, but wanted to see if anyone had objections or better ideas. 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] [PATCH] Largeobject access controls
KaiGai Kohei kai...@kaigai.gr.jp writes: BTW, currently, the default ACL of largeobject allows anything for owner and nothing for world. Do you have any comment for the default behavior? Mph. I think the backlash will be too great. You have to leave the default behavior the same as it is now, ie, world access. 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] [PATCH] Largeobject access controls
KaiGai Kohei wrote: BTW, currently, the default ACL of largeobject allows anything for owner and nothing for world. Do you have any comment for the default behavior? Backwards compatibility would say that the world should be able to at least read the object. -- 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] Getting rid of the flat authentication file
On Fri, 2009-08-28 at 11:52 -0400, Tom Lane wrote: I've thought of an easier way to handle this: if the given database name is invalid, connect to database postgres instead, and perform authentication using normal access to the pg_auth catalogs. If authentication succeeds, *then* throw the error about nonexistent database. If postgres is not there, we'd still expose existence of the original database name early, but how many installations don't have that? I run into it all the time. People drop the postgres database as not needed. (I thought about trying template1 and/or template0 as fallbacks, but that's probably not a good thing. Backends that are waiting on a client for authentication would pose a DOS problem for sessions trying to do CREATE DATABASE, if they're connected to those.) What if there was a silent database, say pg_authdb. That isn't even visible under normal circumstances (need to be in single user mode)? Alternatively just make it so the postgres database can't be dropped. ERROR: The database postgres is a system database. It can not be dropped. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- 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] Getting rid of the flat authentication file
Joshua D. Drake j...@commandprompt.com writes: On Fri, 2009-08-28 at 11:52 -0400, Tom Lane wrote: I've thought of an easier way to handle this: if the given database name is invalid, connect to database postgres instead, and perform authentication using normal access to the pg_auth catalogs. If authentication succeeds, *then* throw the error about nonexistent database. If postgres is not there, we'd still expose existence of the original database name early, but how many installations don't have that? I run into it all the time. People drop the postgres database as not needed. Well, it isn't, unless you are worried about a third-order security issue like whether someone can identify database names by a brute force attack. The only problem if it's not there is we'll throw the no such db error before user validation instead of after. I'm feeling that that isn't worth a large expenditure of effort, as long as there's a reasonable way to configure the system so it is secure if you care about that. 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] Getting rid of the flat authentication file
On Fri, Aug 28, 2009 at 12:12 PM, Tom Lanet...@sss.pgh.pa.us wrote: Joshua D. Drake j...@commandprompt.com writes: On Fri, 2009-08-28 at 11:52 -0400, Tom Lane wrote: I've thought of an easier way to handle this: if the given database name is invalid, connect to database postgres instead, and perform authentication using normal access to the pg_auth catalogs. If authentication succeeds, *then* throw the error about nonexistent database. If postgres is not there, we'd still expose existence of the original database name early, but how many installations don't have that? I run into it all the time. People drop the postgres database as not needed. Well, it isn't, unless you are worried about a third-order security issue like whether someone can identify database names by a brute force attack. The only problem if it's not there is we'll throw the no such db error before user validation instead of after. I'm feeling that that isn't worth a large expenditure of effort, as long as there's a reasonable way to configure the system so it is secure if you care about that. Although this seems reasonably OK from a security point of view, it does seem to violate the POLA. ...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] Time-based Releases WAS: 8.5 release timetable, again
All, There's some very good reasons for the health of the project to have specific release dates and stick to them. Help me understand why? We've cited this before, but here's the definitive paper on the subject: http://www.cyrius.com/publications/michlmayr-phd.pdf summary here: http://robertogaloppini.net/2007/04/02/open-source-production-time-based-release-management/ Further evidence since then with Debian, Parrot, and several other projects which have moved from feature-based releases to time-based releases is that each release had just as many features despite the more rigid time, and that contributors and users were far better able to organize their lives around a defined schedule. Thus, each person was able to contribute more because they knew exactly when they had to do it. I don't know about you, but I personally work better when I have an actual deadline. I'd think the advantages for our commercial adopters (who pay the salaries for many of the people on this list) would be obvious; if they know with a small margin of error when the next version of PostgreSQL is coming out, they can plan testing and deployment of their new products. See Kevin's post; many companies need to schedule serious testing hardware months in advance, and every ISV needs to plan new product deployments up to a year in advance. We bitch a lot in the community about the super-old versions of PG which commercial software is using, but our variable release cycle is partly to blame. For our contributors, it's a lot harder to get funding to do paid contract work on features if you can't tell your sponsor when the next release is coming out. The alternative? 100% of the evidence I've seen is that feature-based release cycles get progressively longer as the project gets bigger. Eventually you find yourself only doing a release every 3.5 years, like MySQL or Debian used to. And your developers start leaving because they never see the fruits of their contributions, and your users start leaving because there's never anything new. Certainly our project experiences with waiting for feature X have all been negative. The windows port never got into 7.4 despite holding it up 4 months. HOT held up 8.3 for three to five months, depending on how you count it, in what I think everyone feels was our most painful beta period ever. Most recently, we let HS/SR hold up 8.4 for 2 months ... and they still weren't ready. I would like to see us go to an annual release timeline in which we release in the same month every year. Any time we say variable release date what it really means is later release date. We've never yet released something *early*. -- 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] 8.5 release timetable, again
Folks, Here is my proposal for CFs for this year: We do four CFs, July 15, September 15, November 15, and January 15. However, we rigidly apply the 30-day deadline for the January 15 CF. That is, anything which is not completely ready for commit on February 14 gets punted to the next version. None of the oh it's almost ready, no just 2 more weeks of review. Make sure everything gets reviewed promptly (we *can* do it) and commit or punt. == Speeding things up == As far as our annual cycle is concerned, I don't think that the development/CF period is the problem; it's as efficient as we really want it to be. It's what comes after: post-CF cleanup, integration, beta. This period is especially a problem because it is one of little visible activity, no development, and generally waiting-room mentality for most of our contributors. Here are my proposals for making all of that go faster, with the caveat that it probably won't get better until the 2nd time we do it: Post-CF: Make a list (now, not in January) of the tasks which need to be done between CFend and Beta. We'll find that some of them could be done by someone other than Tom and Bruce, and that others could be done before CFend. Beta: Create a mailing list (why don't we have a list for testers? is testing less important than the JDBC driver?) and a simple web app or templated wiki page for testers. Allow people to check in with which version they tested (Alpha1,2,3, Beta 1,2,3) and what tests they ran, and issues encountered (if any). We should do this now so we can get started with Alpha testing. When this testing gets into swing, we can also look at recruiting volunteers to run various popular OSS apps' test suites against the developing version of PostgreSQL. Once beta starts, have a list of pending issues in some editable/commentable location (wiki is ok for this, or we can pervert the commitfest app) *as soon as those issues arise* so that as many hackers as possible can work on those issues. We did do a pending issues list for 8.4, but not until we were already over a month into beta, and then the list wasn't very accurate. -- 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] UPDATE .. RETURNING OLD.*
On Fri, Aug 28, 2009 at 06:12:30PM +0300, Marko Tiikkaja wrote: Hi everyone, Today I needed a feature like $subject. The use case was: UPDATE foo SET bar = bar + 1 WHERE id=$1, but I wanted to only do it when bar was 0. In order to give the user an informative error message, I also needed to distinguish the two cases: a row with id = $1 doesn't exist, and bar was 0, so I couldn't put bar != 0 into the WHERE clause. This time I got around it by using RETURNING bar and checking that it was 1 on the client side, but I can come up with other cases where you can't do that. Comments? We talked about this briefly in IRC last night, and since that's not recorded, I'd like to mention a few things here: * OLD is already a reserved word. We could use it without fear of a badly named database object. * Having access to both the old and new row could make debugging complex UPDATE queries much easier. * There's some interesting use cases if the UPDATE...RETURNING can also be used as a subquery. Auditing would be one. 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
[HACKERS] LWLock Queue Jumping
WALInsertLock is heavily contended and likely always will be even if we apply some of the planned fixes. Some callers of WALInsertLock are more important than others * Writing new Clog or Multixact pages (serialized by ClogControlLock) * For Hot Standby, writing SnapshotData (serialized by ProcArrayLock) In these cases it seems like we can skip straight to the front of the WALInsertLock queue without problem. Most other items cannot be safely reordered, possibly no other items. We already re-order the lock queues when we hold shared locks, so we know in principle it is OK to do so. This is an extension of that thought. Implementing this would do much to remove my objection to performance issues associated with simplifying the Hot Standby patch, as recently suggested by Heikki. Possible? If so, we can discuss implementation. No worries if not, but just a side thought that may be fruitful. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Add YAML option to explain
Attached patch adds YAML output option to explain:
explain (format YAML) select * from information_schema.columns;
--
Greg Sabino Mullane g...@turnstep.com
PGP Key: 0x14964AC8 200908281414
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
Index: contrib/auto_explain/auto_explain.c
===
RCS file: /projects/cvsroot/pgsql/contrib/auto_explain/auto_explain.c,v
retrieving revision 1.7
diff -u -r1.7 auto_explain.c
--- contrib/auto_explain/auto_explain.c 10 Aug 2009 05:46:49 - 1.7
+++ contrib/auto_explain/auto_explain.c 28 Aug 2009 18:12:49 -
@@ -29,6 +29,7 @@
{text, EXPLAIN_FORMAT_TEXT, false},
{xml, EXPLAIN_FORMAT_XML, false},
{json, EXPLAIN_FORMAT_JSON, false},
+{yaml, EXPLAIN_FORMAT_YAML, false},
{NULL, 0, false}
};
Index: doc/src/sgml/auto-explain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/auto-explain.sgml,v
retrieving revision 1.4
diff -u -r1.4 auto-explain.sgml
--- doc/src/sgml/auto-explain.sgml 10 Aug 2009 05:46:50 - 1.4
+++ doc/src/sgml/auto-explain.sgml 28 Aug 2009 18:12:49 -
@@ -114,7 +114,7 @@
varnameauto_explain.log_format/varname selects the
commandEXPLAIN/ output format to be used.
The allowed values are literaltext/literal, literalxml/literal,
- and literaljson/literal. The default is text.
+ literaljson/literal, and literalyaml/literal. The default is text.
Only superusers can change this setting.
/para
/listitem
Index: doc/src/sgml/release-8.5.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/release-8.5.sgml,v
retrieving revision 1.4
diff -u -r1.4 release-8.5.sgml
--- doc/src/sgml/release-8.5.sgml 19 Aug 2009 08:18:48 - 1.4
+++ doc/src/sgml/release-8.5.sgml 28 Aug 2009 18:12:49 -
@@ -96,7 +96,7 @@
itemizedlist
listitem
para
-EXPLAIN allows output of plans in XML or JSON format for automated
+EXPLAIN allows output of plans in XML, JSON, or YAML format for automated
processing of explain plans by analysis or visualization tools.
/para
/listitem
Index: doc/src/sgml/ref/explain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/explain.sgml,v
retrieving revision 1.46
diff -u -r1.46 explain.sgml
--- doc/src/sgml/ref/explain.sgml 10 Aug 2009 05:46:50 - 1.46
+++ doc/src/sgml/ref/explain.sgml 28 Aug 2009 18:12:49 -
@@ -31,7 +31,7 @@
refsynopsisdiv
synopsis
-EXPLAIN [ ( { ANALYZE replaceable class=parameterboolean/replaceable | VERBOSE replaceable class=parameterboolean/replaceable | COSTS replaceable class=parameterboolean/replaceable | FORMAT { TEXT | XML | JSON } } [, ...] ) ] replaceable class=parameterstatement/replaceable
+EXPLAIN [ ( { ANALYZE replaceable class=parameterboolean/replaceable | VERBOSE replaceable class=parameterboolean/replaceable | COSTS replaceable class=parameterboolean/replaceable | FORMAT { TEXT | XML | JSON | YAML } } [, ...] ) ] replaceable class=parameterstatement/replaceable
EXPLAIN [ ANALYZE ] [ VERBOSE ] replaceable class=parameterstatement/replaceable
/synopsis
/refsynopsisdiv
@@ -143,8 +143,8 @@
termliteralFORMAT/literal/term
listitem
para
- Specify the output format, which can be TEXT, XML, or JSON.
- XML or JSON output contains the same information as the text output
+ Specify the output format, which can be TEXT, XML, JSON, or YAML.
+ Non-text output contains the same information as the text output
format, but is easier for programs to parse. This parameter defaults to
literalTEXT/literal.
/para
Index: src/backend/commands/explain.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/explain.c,v
retrieving revision 1.190
diff -u -r1.190 explain.c
--- src/backend/commands/explain.c 22 Aug 2009 02:06:32 - 1.190
+++ src/backend/commands/explain.c 28 Aug 2009 18:12:49 -
@@ -96,6 +96,7 @@
static void ExplainXMLTag(const char *tagname, int flags, ExplainState *es);
static void ExplainJSONLineEnding(ExplainState *es);
static void escape_json(StringInfo buf, const char *str);
+static void escape_yaml(StringInfo buf, const char *str);
/*
@@ -137,6 +138,8 @@
es.format = EXPLAIN_FORMAT_XML;
else if (strcmp(p, json) == 0)
es.format = EXPLAIN_FORMAT_JSON;
+ else if (strcmp(p, yaml) == 0)
+es.format = EXPLAIN_FORMAT_YAML;
else
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
@@ -1509,6 +1512,18 @@
}
appendStringInfoChar(es-str, ']');
break;
+
+ case EXPLAIN_FORMAT_YAML:
+ appendStringInfoSpaces(es-str, es-indent * 2);
+ appendStringInfo(es-str, %s:\n,
Re: [HACKERS] Add YAML option to explain
Greg Sabino Mullane wrote: Attached patch adds YAML output option to explain: I thought the consensus was that we didn't want to get into supporting more formats. What does YAML provide that JSON does not? 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] StringInfo Macros
Hello Tom, Tom Lane wrote: Don't call them BUFFER_FOO --- that term already has a pretty specific meaning in most of the backend. STRINGINFO_FOO is a bit long but seems to fit the best with the existing naming in stringinfo.h. Understood and agreed. Note however, that lots of places, especially also pgformat.c, call the StringInfo variable buf. A number of the specific things you are proposing above seem to be violations of the abstraction stringinfo is meant to present. Maybe in violation of stringinfo, which is more general, but much less WRT all of the pq_sendXX() and the corresponding pq_getmsgXX() methods. AFAIU the former don't use the cursor and write starting from END_PTR as long as BYTES_FREE 0, while the later uses the cursor field and reads from CURSOR_PTR as long as BYTES_READABLE 0. It's a string, and the fact that there's any extra space beyond the end of the string is an internal matter. I rather think of those as buffers to read from and write to. In that case it makes perfect sense to append new data at the end, IMO. On could argue, that StringInfo itself isn't the best fit, as it doesn't necessarily hold a string. So it might be hard to find a good prefix. PQFORMAT_ might be an option, but it's even less descriptive... Thank you for commenting. Regards Markus Wanner -- 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 Fri, 2009-08-28 at 10:55 -0700, Josh Berkus wrote: Here is my proposal for CFs for this year: We do four CFs, July 15, September 15, November 15, and January 15. However, we rigidly apply the 30-day deadline for the January 15 CF. That is, anything which is not completely ready for commit on February 14 gets punted to the next version. None of the oh it's almost ready, no just 2 more weeks of review. Make sure everything gets reviewed promptly (we *can* do it) and commit or punt. Fine for me. -- Simon Riggs www.2ndQuadrant.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] Add YAML option to explain
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I thought the consensus was that we didn't want to get into supporting more formats. What does YAML provide that JSON does not? Readability and easy editing. All the power of JSON without the annoying quotes, braces, and brackets. By the way, Magnus pointed out an error in the patch: the hunk at - -1693,7 +1736,6 should be ignored. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200908281552 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkqYOmUACgkQvJuQZxSWSsjMogCfVV8hj0QkRQFmOq2nkUV+1bqM QDcAoKAlc6lpuV9jbeIL8ms9HIfhLF2W =nb+s -END PGP SIGNATURE- -- 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] Shipping documentation untarred
On tis, 2009-08-11 at 12:42 +0300, Peter Eisentraut wrote: I've been thinking that we could actually get rid of that build-in-srcdir behavior, which also occasionally puzzles vpath users with respect to gram.c and so on. The new behavior would be to build targets in the local directory. The only requirement would be that distribution tarballs be built in-tree, so that the stuff that is distprep'ed actually ends up in the tarball, but I think that should not be a problem. I have implemented this approach now. -- 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] Add YAML option to explain
* Greg Sabino Mullane: I thought the consensus was that we didn't want to get into supporting more formats. What does YAML provide that JSON does not? Readability and easy editing. All the power of JSON without the annoying quotes, braces, and brackets. But YAML is much more difficult to parse than JSON. Anybody who can afford a YAML parser can also afford a JSON parser, it is miniscule in comparison. 8-) -- 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] Add YAML option to explain
On 8/28/09 1:13 PM, Greg Sabino Mullane wrote: I thought the consensus was that we didn't want to get into supporting more formats. What does YAML provide that JSON does not? Readability and easy editing. All the power of JSON without the annoying quotes, braces, and brackets. How many lines of code does YAML support add to the codebase? While I personally like YAML, it's not like it has broad industry support. And people wouldn't interface with the XML or JSON directly; they'd use a library for that. That's the whole point of having those outputs. -- 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] Add YAML option to explain
On Fri, 2009-08-28 at 14:23 -0700, Josh Berkus wrote: On 8/28/09 1:13 PM, Greg Sabino Mullane wrote: I thought the consensus was that we didn't want to get into supporting more formats. What does YAML provide that JSON does not? Readability and easy editing. All the power of JSON without the annoying quotes, braces, and brackets. How many lines of code does YAML support add to the codebase? While I personally like YAML, it's not like it has broad industry support. And people wouldn't interface with the XML or JSON directly; they'd use a library for that. That's the whole point of having those outputs. I am not keen on having YAML support. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- 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] Add YAML option to explain
On fre, 2009-08-28 at 20:13 +, Greg Sabino Mullane wrote: Readability and easy editing. All the power of JSON without the annoying quotes, braces, and brackets. But these are supposed to be machine-readable formats. So readability and editability are not high priority criteria. -- 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] Logging configuration changes
On ons, 2009-08-26 at 22:13 -0400, Tom Lane wrote:
Seems to me it would be too chatty to be useful, at least for people who
set more than one or two things in postgresql.conf. Would it be that
hard to track which values actually changed? Without having looked at
the code, I'm thinking that much of the infrastructure must be there
already now that we have support for undoing commented-out settings.
Found an easy solution; see attached patch.
On a related note, I suggest reverting or revising this logging change:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=293c816e4aad8e760bcb4eaba0aa16da0ccd2d04
Putting the reason for an error or warning into the detail part is not
acceptable style, IMO.
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.59
diff -u -3 -p -r1.59 guc-file.l
--- src/backend/utils/misc/guc-file.l 9 Apr 2009 14:21:02 - 1.59
+++ src/backend/utils/misc/guc-file.l 28 Aug 2009 21:30:56 -
@@ -283,6 +283,10 @@ ProcessConfigFile(GucContext context)
/* Now we can re-apply the wired-in default */
set_config_option(gconf-name, NULL, context, PGC_S_DEFAULT,
GUC_ACTION_SET, true);
+ if (context == PGC_SIGHUP)
+ ereport(elevel,
+ (errmsg(parameter \%s\ removed from configuration file, reset to default,
+ gconf-name)));
}
/*
@@ -309,9 +313,18 @@ ProcessConfigFile(GucContext context)
/* If we got here all the options checked out okay, so apply them. */
for (item = head; item; item = item-next)
{
+ char *pre_value;
+
+ if (context == PGC_SIGHUP)
+ pre_value = pstrdup(GetConfigOption(item-name));
+
if (set_config_option(item-name, item-value, context,
PGC_S_FILE, GUC_ACTION_SET, true))
{
+ if (context == PGC_SIGHUP strcmp(pre_value, GetConfigOption(item-name)) != 0)
+ereport(elevel,
+ (errmsg(parameter \%s\ changed to \%s\,
+item-name, item-value)));
set_config_sourcefile(item-name, item-filename,
item-sourceline);
}
--
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] Linux LSB init script
I wrote: But before I spend a lot of time fine-tuning it, I wanted to post this as a proof-of-concept draft and see if people think it's on the right track. I chose to take the lack of response as an indication that nobody who cares about this thought there was anything seriously wrong with the draft, so I tidied it up and did more testing. I'm submitting this for the next CommitFest. I'm attaching the file which I propose to include in the contrib/start-scripts subdirectory. If it is preferred that a new file be in patch form, I need a clue from someone how to create that. -Kevin linux-lsb Description: Binary 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] Add YAML option to explain
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 How many lines of code does YAML support add to the codebase? About 80. While I personally like YAML, it's not like it has broad industry support. And people wouldn't interface with the XML or JSON directly; they'd use a library for that. That's the whole point of having those outputs. Not sure how one measures broad industry support or why we would care that much. Nor do I wish to turn this thread into a YAML flamewar. It's a small patch that should be useful to the many people that prefer to program using YAML. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200908281741 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkqYT0QACgkQvJuQZxSWSshPMACg+ho+gTxeKR27pOJrbX7kTJ9E kZIAnRIz57KzuLAAr6PtjupBwletuXRe =ZJO7 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] LWLock Queue Jumping
-- Forwarded message -- From: Simon Riggs si...@2ndquadrant.com To: pgsql-hackers pgsql-hackers@postgresql.org Date: Fri, 28 Aug 2009 20:07:32 +0100 Subject: LWLock Queue Jumping WALInsertLock is heavily contended and likely always will be even if we apply some of the planned fixes. Some callers of WALInsertLock are more important than others * Writing new Clog or Multixact pages (serialized by ClogControlLock) * For Hot Standby, writing SnapshotData (serialized by ProcArrayLock) In these cases it seems like we can skip straight to the front of the WALInsertLock queue without problem. Most other items cannot be safely reordered, possibly no other items. We already re-order the lock queues when we hold shared locks, so we know in principle it is OK to do so. This is an extension of that thought. Implementing this would do much to remove my objection to performance issues associated with simplifying the Hot Standby patch, as recently suggested by Heikki. Possible? If so, we can discuss implementation. No worries if not, but just a side thought that may be fruitful. I'd previously implemented this just by copying and pasting and making some changes, perhaps not the most desirable way but I thought adding another parameter to all existing invocations would be a bit excessive. The attached patch will convert the existing LWLockAcquire into LWLockAcquire_head, rather than adding a new function. Sorry if that is not the optimal way to send this, I wanted to make it easy to see just the changes, even though the functions aren't technically the same thing anymore. I've tested it fairly thoroughly, in the context of using it in AdvanceXLInsertBuffer for acquiring the WALWriteLock. Jeff lwlock.patch Description: Binary 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] Linux LSB init script
On Fri, Aug 28, 2009 at 04:41:47PM -0500, Kevin Grittner wrote: I wrote: But before I spend a lot of time fine-tuning it, I wanted to post this as a proof-of-concept draft and see if people think it's on the right track. I chose to take the lack of response as an indication that nobody who cares about this thought there was anything seriously wrong with the draft, so I tidied it up and did more testing. I'm submitting this for the next CommitFest. I'm attaching the file which I propose to include in the contrib/start-scripts subdirectory. If it is preferred that a new file be in patch form, I need a clue from someone how to create that. cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. 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] Linux LSB init script
David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N contrib/start-scripts/linux-lsb ../linux-lsb.patch cvs diff: I know nothing about contrib/start-scripts/linux-lsb Same behavior with and without the -N flag. What am I missing? -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] Linux LSB init script
On Fri, Aug 28, 2009 at 04:57:24PM -0500, Kevin Grittner wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N contrib/start-scripts/linux-lsb ../linux-lsb.patch cvs diff: I know nothing about contrib/start-scripts/linux-lsb Same behavior with and without the -N flag. What am I missing? Might be easier with git, then :/ Cheers, David (let's move to git!) -- 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] Add YAML option to explain
* Greg Sabino Mullane (g...@turnstep.com) wrote: Attached patch adds YAML output option to explain: explain (format YAML) select * from information_schema.columns; +1 from me. I've read the other comments and just plain don't agree with them. It's a small patch, adds a useful format for EXPLAIN, and would be used. One of the best things about PG is the flexibility and usability. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Linux LSB init script
On Fri, Aug 28, 2009 at 10:57 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: You have to cvs add the file -- 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] [PATCH] DefaultACLs
I had some time to work on this patch, and I implemented the ALTER DEFAULT PRIVILEGES syntax as proposed by Tom and adjusted some other stuff, but before I can submit the new patch for commitfest there is still this fundamental issue about how it should behave. The situation is as following. Josh's and Stephen's idea was basically to solve something like this: you are a dba, you give some users privileges to create tables and you want those new tables to have same privileges no matter who created them. But if I understood Tom's suggestions correctly then his approach does not solve this at all since every one of those users with CREATE TABLE privileges would have to also set same DEFAULT PRIVILEGES and the dba would have no say in the matter. I personally can see use cases for both but I don't really see any reasonable way to have both at the same time. -- Regards Petr Jelinek (PJMODOS) -- 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] Linux LSB init script
On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote: On Fri, Aug 28, 2009 at 10:57 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: You have to cvs add the file That only works if you have write permissions to the central repo. I don't. 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] [PATCH] DefaultACLs
Petr, But if I understood Tom's suggestions correctly then his approach does not solve this at all since every one of those users with CREATE TABLE privileges would have to also set same DEFAULT PRIVILEGES and the dba would have no say in the matter. This latter approach benefits nobody. If default's can't be set by the DBA centrally, the feature is useless. -- 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] Linux LSB init script
On fre, 2009-08-28 at 16:57 -0500, Kevin Grittner wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N contrib/start-scripts/linux-lsb ../linux-lsb.patch cvs diff: I know nothing about contrib/start-scripts/linux-lsb Same behavior with and without the -N flag. What am I missing? If it's a new file, it's pointless to send a patch anyway. You could also consider putting it in place of the linux file. -- 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] Linux LSB init script
On Fri, Aug 28, 2009 at 11:59 PM, David Fetterda...@fetter.org wrote: You have to cvs add the file That only works if you have write permissions to the central repo. I don't. True. The only workable way to use cvs that i found was to rsync the repository and then check out from that. If you cvs add then then the next rsync will overwrite your cvs add but in the meantime i think you could do cvs diff. -- 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] Add YAML option to explain
On Aug 28, 2009, at 3:45 PM, Stephen Frost wrote: +1 from me. I've read the other comments and just plain don't agree with them. It's a small patch, adds a useful format for EXPLAIN, and would be used. One of the best things about PG is the flexibility and usability. I agree, I tend to prefer YAML output where it's parseable (and I expect it the EXPLAIN YAML output won't be doing anything tricky). That said, maybe there should be a way to create modules add formats, instead of adding them to core? Best, David -- 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] Linux LSB init script
David Fetter wrote: On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote: On Fri, Aug 28, 2009 at 10:57 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: You have to cvs add the file That only works if you have write permissions to the central repo. I don't. cvsutils IYF. See http://www.red-bean.com/cvsutils/ If you're on Fedora at least yum install cvsutils should be all you need to do. 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
Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)
The question is still valid, though it's better put in your words - do we want to refactor the existing compiler or write a separate one ? So, for now I went with the path of custom compiler and current executor. I attached current version of the patch. I don't expect this to get committed or anything, but I'd like other eyes to take a look at it. What it does: Adds laninline Oid which points to function handling inline code (aka anonymous code block). Adds DO $$some code$$ [ LANGUAGE lanname ] syntax which sends the source code to that laninline function of the specified language (or language set by default_do_language guc). There is implementation for plpgsql with simpler compiler which still creates function struct for the executor (I believe there is no harm in adjusting executor later, when current one works, just does unnecessary stuff). There is doc and a simple regression test for plpgsql implementation. -- Regards Petr Jelinek (PJMODOS) inlinepl-2009-08-28.diff.gz Description: Unix tar archive -- 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] Add YAML option to explain
Peter Eisentraut wrote: On fre, 2009-08-28 at 20:13 +, Greg Sabino Mullane wrote: Readability and easy editing. All the power of JSON without the annoying quotes, braces, and brackets. But these are supposed to be machine-readable formats. So readability and editability are not high priority criteria. Greg, can we see a few examples of the YAML output compared to both json and text? IMVHO, an advantage of YAML is human readability of structured data even compared to most non-computer-parseable human-intended text formats. But maybe that's just because I read too much yaml. -- 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] phypot - Pygmy Hippotause ?
Kevin Grittner wrote:
The first test seems unnecessary if you have the second.
x = 0, so x can't be zero unless y is, too.
Returning x on y == 0.0 will return 0.0 whenever x == 0.0.
-Kevin
Wish granted. :-)
--
--
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
Index: src/backend/utils/adt/geo_ops.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.103
diff -c -r1.103 geo_ops.c
*** src/backend/utils/adt/geo_ops.c 28 Jul 2009 09:47:59 - 1.103
--- src/backend/utils/adt/geo_ops.c 29 Aug 2009 02:47:14 -
***
*** 32,37
--- 32,38
* Internal routines
*/
+ static double phypot(double x, double y);
static intpoint_inside(Point *p, int npts, Point *plist);
static intlseg_crossing(double x, double y, double px, double py);
static BOX *box_construct(double x1, double x2, double y1, double y2);
***
*** 825,831
box_cn(a, box1);
box_cn(b, box2);
! PG_RETURN_FLOAT8(HYPOT(a.x - b.x, a.y - b.y));
}
--- 826,832
box_cn(a, box1);
box_cn(b, box2);
! PG_RETURN_FLOAT8(phypot(a.x-b.x, a.y-b.y));
}
***
*** 1971,1977
Point *pt1 = PG_GETARG_POINT_P(0);
Point *pt2 = PG_GETARG_POINT_P(1);
! PG_RETURN_FLOAT8(HYPOT(pt1-x - pt2-x, pt1-y - pt2-y));
}
double
--- 1972,1978
Point *pt1 = PG_GETARG_POINT_P(0);
Point *pt2 = PG_GETARG_POINT_P(1);
! PG_RETURN_FLOAT8(phypot(pt1-x - pt2-x, pt1-y - pt2-y));
}
double
***
*** 1979,1987
{
#ifdef GEODEBUG
printf(point_dt- segment (%f,%f),(%f,%f) length is %f\n,
! pt1-x, pt1-y, pt2-x, pt2-y, HYPOT(pt1-x - pt2-x, pt1-y -
pt2-y));
#endif
! return HYPOT(pt1-x - pt2-x, pt1-y - pt2-y);
}
Datum
--- 1980,1988
{
#ifdef GEODEBUG
printf(point_dt- segment (%f,%f),(%f,%f) length is %f\n,
! pt1-x, pt1-y, pt2-x, pt2-y, phypot(pt1-x - pt2-x, pt1-y -
pt2-y));
#endif
! return phypot(pt1-x - pt2-x, pt1-y - pt2-y);
}
Datum
***
*** 2444,2450
dist_pl_internal(Point *pt, LINE *line)
{
return (line-A * pt-x + line-B * pt-y + line-C) /
! HYPOT(line-A, line-B);
}
Datum
--- 2445,2451
dist_pl_internal(Point *pt, LINE *line)
{
return (line-A * pt-x + line-B * pt-y + line-C) /
! phypot(line-A, line-B);
}
Datum
***
*** 4916,4922
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius *= HYPOT(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
--- 4917,4923
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius *= phypot(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
***
*** 4936,4942
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius /= HYPOT(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
--- 4937,4943
PointPGetDatum(point)));
result-center.x = p-x;
result-center.y = p-y;
! result-radius /= phypot(point-x, point-y);
PG_RETURN_CIRCLE_P(result);
}
***
*** 5401,5403
--- 5402,5465
return FALSE;
}
+
+
+ /*-
+ * Determine the hypotenuse.
+ *
+ * If required, x and y are swapped to make x the larger number. The
+ * traditional formulae of x^2+y^2 is rearranged to factor x outside the
+ * sqrt. This allows computation of the hypotenuse for significantly
+ * larger values, and with a higher precision than otherwise normally
+ * possible.
+ *
+ * Only arguments of 1.27e308 are at risk of causing overflow. Whereas
+ * the naive approach limits arguments to 9.5e153.
+ *
+ * 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 )
+ *
+ * It is expected that this routine will eventually be replaced with the
+ * C99 hypot() function.
+ *
+ * This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the
+ * case of hypot(inf,nan) results in INF, and not NAN. To obtain Single
+ * UNIX Specification behaviour, swap the order of the isnan() and isinf()
+ * test sections.
+ *
+ * The HYPOT macro this function is
Re: [HACKERS] Add YAML option to explain
On Fri, Aug 28, 2009 at 04:37:41PM -0700, David E. Wheeler wrote: On Aug 28, 2009, at 3:45 PM, Stephen Frost wrote: +1 from me. I've read the other comments and just plain don't agree with them. It's a small patch, adds a useful format for EXPLAIN, and would be used. One of the best things about PG is the flexibility and usability. I agree, I tend to prefer YAML output where it's parseable (and I expect it the EXPLAIN YAML output won't be doing anything tricky). That said, maybe there should be a way to create modules add formats, instead of adding them to core? +1 -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] WIP: remove use of flat auth file for client authentication
Attached is a patch that removes the use of the flat auth file during client authentication, instead using regular access to the pg_auth catalogs. As previously discussed, this implies pushing the authentication work down to InitPostgres. I didn't yet do anything about the idea of falling back to connecting to postgres when the specified target DB doesn't exist, but other than that small change I think it's about ready to go. The main thing that turned out to be unexpectedly, um, interesting was signal handling. What we have been doing during client authentication is to point SIGTERM, SIGALRM, etc to the authdie handler, which just does proc_exit(1) directly. This will *not* do once we've entered a transaction --- in general you can't expect to just interrupt the backend in a random place and start doing something different. I'm not really sure it was safe even during authentication, but for sure it's not safe during database access. The solution that's adopted here is to use the regular backend SIGINT, SIGTERM, SIGQUIT, and SIGALRM signal handling, and to turn on ImmediateInterruptOK while we are doing client interactions during authentication, but not while we are doing database accesses during authentication. It's a bit ugly because the signal handlers have to be taught to do something different when ClientAuthInProgress, but I don't see a better way. Another interesting point is that for this to work, those signal interrupts have to actually be enabled (doh) ... and up to now we have been running InitPostgres with most signals disabled. I suspect that this means some things are actively broken during InitPostgres's initial transaction --- for example, if it happens to try to take a lock that completes a deadlock cycle, the deadlock won't be detected because the lock timeout SIGALRM interrupt will never occur. Another example is that SI inval messaging isn't working during InitPostgres either. The patch addresses this by moving up PostgresMain's PG_SETMASK(UnBlockSig); call to before InitPostgres. We might need to back-patch that bit, though I'm hesitant to fool with such a thing in back branches. Thoughts, objections, better ideas? regards, tom lane bin4PfkfnnJ8h.bin Description: no-flat-auth-file-1.patch.gz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
