Re: [HACKERS] Simple thing to make pg_autovacuum more useful
On Fri, Jan 18, 2008 at 01:07:27AM +, Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > >> You are offering what appears to be a "solution". A perfectly valid one > >> in fact. Which one is going to get done first? Which one is going to > >> provide immediate benefit? > > > > The problem is that your "immediate benefit" is to encourage people > > to do direct manual insertions into pg_autovacuum, which is something > > that we shouldn't be encouraging, because it's not the correct long-term > > solution. Or even short-term --- it seems reasonably likely to me that > > something could be done about building a decent API in the 8.4 cycle, > > which is the soonest we could entertain a proposal to put defaults on > > pg_autovacuum anyway. > > Are you picturing adding ALTER TABLE commands to set autovacuum parameters? Or > do you mean for tools like pgadmin to control this? Because the latter could > happen even during the 8.3 cycle (though I perhaps not with pgadmin itself > which I think follows the Postgres release cycle). Of course, pgadmin already does this :-P Ask that tall guy sitting next to you for a demo... What it doesn't do is help you figure out what values to put in... //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Simple thing to make pg_autovacuum more useful
On 18/01/2008, Gregory Stark <[EMAIL PROTECTED]> wrote: > Are you picturing adding ALTER TABLE commands to set autovacuum parameters? Or > do you mean for tools like pgadmin to control this? Because the latter could > happen even during the 8.3 cycle (though I perhaps not with pgadmin itself > which I think follows the Postgres release cycle). pgAdmin already has an interface to pg_autovacuum. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Simple thing to make pg_autovacuum more useful
On Thursday 17 January 2008 19:17:00 Joshua D. Drake wrote: > On Thu, 17 Jan 2008 21:43:46 -0300 > > Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > Tom Lane wrote: > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > > All this thread is a waste of time. We've previously agreed that > > > > we're going to store autovacuum per-table settings in > > > > pg_class.reloptions. > > > > > > I had forgotten that discussion. So the plan is for the > > > pg_autovacuum catalog to go away entirely, correct? > > > > Yup. > > Wait .reloptions is a column... how are we going to populate it and > array? ALTER TABLE foo SET autovacuum to true; ALTER TABLE foo SET autovacuum_naptime to '1min'; (or there about) I suppose we could also have pg_autovacuum become a view, with rules to manage relopts. > > Sincerely, > > Joshua D. Drake -- Darcy Buskermolen Command Prompt, Inc. +1.503.667.4564 X 102 http://www.commandprompt.com/ PostgreSQL solutions since 1997 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] modularity of PostgreSQL
On Jan 18, 2008 8:09 AM, Jonah H. Harris <[EMAIL PROTECTED]> wrote: > On Jan 17, 2008 6:46 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > Uh, does anyone authoritative describe it that way? I think we can > > legitimately claim that Postgres is pretty extensible, but as for > > modularity I'm not sure that it's got any great claim to fame. > > To me modularity connotes an emphasis on dividing the system into > > pieces separated by carefully-defined, small-footprint interfaces, > > and we have not done spectacularly well on that score. > > Agreed. Postges is extensible, not modular. s/ges/gres/g no coffee yet :( -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] proposal: generic function, constructor function
On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: > > I propose two kinds of functions: > > > a) generic functions - this function allows any params without any > > implicit casting (it can implemented only in C language). > > Can't you do that already with ANYELEMENT, or at the worst ANY? Anyelement is related with casting to common type. postgres=# create or replace function fx(anyelement, anyelement) returns text as $$begin return 'ahoj'; end; $$ language plpgsql; CREATE FUNCTION postgres=# select fx(1,'a'); ERROR: invalid input syntax for integer: "a" postgres=# select fx(1,'a'); I would to have independent parameters and move type checking to function. Then I don't need register function exactly and then I can have different numbers of arguments. It's similar like C varargs functions so now I cannot effectively implement printf function, because all parameters are casted to varchar. Using any is broken. ? postgres=# create or replace function fx1(any) returns text as $$begin return 'ahoj'; end; $$ language plpgsql; ERROR: syntax error at or near "any" LINE 1: create or replace function fx1(any) returns text as $$begin ... ^ > > > It allows unspecified number of params > > without parser changes. > > Why is that a good idea (and if you think it won't take parser changes, > you're wrong)? Of course. Implementation needs some changes in parser. But new generic function doesn't need it. With generic functions some xml functions could exists outside parser. And it's simple tool for constructors. > > > Limits: only one function with specified name can exists in schema. > > This is why it's a bad idea. Please note that the unique index on > pg_proc cannot enforce that, even if we wanted such a restriction. > we can use partial unique index, if it is possible - I didn't test it. Regards Pavel Stehule > regards, tom lane > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Recent pg_regress changes break testing under SELinux
Tom Lane wrote: > Who decided this part of pg_regress.c was a good idea? > > /* try to create the test tablespace dir if it doesn't exist */ > snprintf(testtablespace, MAXPGPATH, "%s/testtablespace", abs_builddir); > if (directory_exists(testtablespace)) > rmtree(testtablespace, true); > make_directory(testtablespace); Hmm, AFAICS it was applied by me in 1.26, a patch from Magnus apparently. This was quite some time ago! I think I just passed that part verbatim from Magnus' patch. > The regression test Makefile is responsible for preparing that > directory, not pg_regress. This is important because in the Postgres > RPMs, we have to be careful to appease SELinux: Interesting. Certainly I didn't have that in mind when I applied it. > As far as I can see the rmtree/make_directory thrashing is useless, and > I'm going to remove it unless a pretty good counter-argument is made. Fine with me ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Recent pg_regress changes break testing under SELinux
Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The original design had only the Makefile knowing exactly where the >> testtablespace directory lurks, making it changeable in one place, >> and also confining the whole business to src/test/regress which is good >> because none of the other uses of pg_regress need it. As CVS tip >> stands, the location of testtablespace is hard-wired into the pg_regress >> executable, and I think it's mostly blind accident that it doesn't >> clutter contrib/* and src/pl/* with testtablespace directories. > Commandline parameter, perhaps? I was trying to avoid that, but only because it'd make the patch bigger. It would be one way to resolve the above gripes. But I'm still thinking that it's fairly silly to expect Windows users to type out the equivalent of ./pg_regress --psqldir=$(PSQLDIR) --schedule=$(srcdir)/parallel_schedule --srcdir=$(abs_srcdir) --multibyte=$(MULTIBYTE) --load-language=plpgsql $(MAXCONNOPT) $(NOLOCALE) especially when no other platform is that hard. (Admittedly, some of these switches have usable defaults, but many don't.) So it really seems like the right answer is a .BAT script, and I'm kinda surprised to hear there's not one already. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Recent pg_regress changes break testing under SELinux
Magnus Hagander <[EMAIL PROTECTED]> writes: > Yeah, agreed. The original idea was to have a shortcut created by the > installer to do that for you. > ... > Well, there is a way to run it from the msvc build. The idea was to be > able to run after a binary install. Granted it doesn't make that much > sense, but it was mostly a "customer feel good" thing. But there's > nothing preventing that from being done from a .BAT file instead of a > direct shortcut. Well, I suppose anything along this line is more code churn than we should engage in post-RC2. What I propose for now is that we just "#ifdef WIN32" the directory deletion/remaking in pg_regress.c, with a suitable comment, and then we can revisit the issue in 8.4 or later. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] proposal: generic function, constructor function
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > But I am not able create function with > ANY params. Is it possible do it via CREATE FUNCTION .. ? It's a reserved word :-(. Try "any" regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Traveling to London
FYI, I am leaving for London tomorrow/Saturday to do training for EnterpriseDB and a breakfast event: http://momjian.us/main/events.html I return next Friday, January 25. I will try to keep current on email while I am away. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Traveling to London
Save trip ,enjoy the flight and please bring a big umbrella its raining here. Gottfried www.5152.co.uk On 1/19/08, Bruce Momjian <[EMAIL PROTECTED]> wrote: > FYI, I am leaving for London tomorrow/Saturday to do training for > EnterpriseDB and a breakfast event: > > http://momjian.us/main/events.html > > I return next Friday, January 25. I will try to keep current on email > while I am away. > > -- > Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us > EnterpriseDB http://postgres.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Recent pg_regress changes break testing under SELinux
Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: Tom Lane wrote: The original design had only the Makefile knowing exactly where the testtablespace directory lurks, making it changeable in one place, and also confining the whole business to src/test/regress which is good because none of the other uses of pg_regress need it. As CVS tip stands, the location of testtablespace is hard-wired into the pg_regress executable, and I think it's mostly blind accident that it doesn't clutter contrib/* and src/pl/* with testtablespace directories. Commandline parameter, perhaps? I was trying to avoid that, but only because it'd make the patch bigger. It would be one way to resolve the above gripes. But I'm still thinking that it's fairly silly to expect Windows users to type out the equivalent of ./pg_regress --psqldir=$(PSQLDIR) --schedule=$(srcdir)/parallel_schedule --srcdir=$(abs_srcdir) --multibyte=$(MULTIBYTE) --load-language=plpgsql $(MAXCONNOPT) $(NOLOCALE) Yeah, agreed. The original idea was to have a shortcut created by the installer to do that for you. especially when no other platform is that hard. (Admittedly, some of these switches have usable defaults, but many don't.) So it really seems like the right answer is a .BAT script, and I'm kinda surprised to hear there's not one already. Well, there is a way to run it from the msvc build. The idea was to be able to run after a binary install. Granted it doesn't make that much sense, but it was mostly a "customer feel good" thing. But there's nothing preventing that from being done from a .BAT file instead of a direct shortcut. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Recent pg_regress changes break testing under SELinux
Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Tom Lane wrote: Who decided this part of pg_regress.c was a good idea? Hmm, AFAICS it was applied by me in 1.26, a patch from Magnus apparently. This was quite some time ago! I think I just passed that part verbatim from Magnus' patch. Hmm ... I wonder if the unstated agenda was to run the regression tests without having any supporting Makefile? AFAIK, that was the *stated* agenda. Or rather, a part of the stated agenda. I'd be willing to make it #ifdef WIN32, instead of diking it out entirely, if that's what the problem is. I would prefer to remove it though. The original design had only the Makefile knowing exactly where the testtablespace directory lurks, making it changeable in one place, and also confining the whole business to src/test/regress which is good because none of the other uses of pg_regress need it. As CVS tip stands, the location of testtablespace is hard-wired into the pg_regress executable, and I think it's mostly blind accident that it doesn't clutter contrib/* and src/pl/* with testtablespace directories. Commandline parameter, perhaps? At this point what I'd really prefer is that pg_regress be completely uninvolved with testtablespace, which we could manage by getting rid of @testtablespace@ in the regression test files in favor of @abs_builddir@/testtablespace. This would mean that both the Makefile and the regression test files know where the directory lurks, but either of those are easier to change than a precompiled binary. Now this isn't gonna work if there's a prerequisite for pg_regress to execute without any external setup, but surely we don't expect users to enter all its switch arguments by hand. What's the actual intended arrangement on Windows ... is there a .BAT script or something that could make the directory? Yeah, there could be that. The idea was to be able to run it without the need for mingw - meaning no Makefile support and no shellscript. But .BAT is supported on all Windows. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] proposal: generic function, constructor function
On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: > > On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote: > >> Can't you do that already with ANYELEMENT, or at the worst ANY? > > > I would to have independent parameters and move type checking to > > function. > > Okay, then you want ANY. > > > Then I don't need register function exactly and then I can > > have different numbers of arguments. > > The different-numbers-of-arguments bit is what I'm objecting to. > Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY), > etc, and you're done without breaking anything else. It's what I unlike - but maybe. But I am not able create function with ANY params. Is it possible do it via CREATE FUNCTION .. ? > > > we can use partial unique index, if it is possible - I didn't test it. > > It's not --- partial indexes on system catalogs are not supported, and > pg_proc is certainly one catalog that that restriction will never be > relaxed for. (How you going to execute a predicate without doing > function lookups?) I don't believe that the constraint could be > expressed as a partial index predicate anyway --- how will you say > that foo(...) and foo(int) conflict, but foo(int) and foo(int,int) > don't? > no, I spoke about constraint - there can be only one function foo(anyparams) or any current functions. So lookup find nearest function or find generic function. Current implementation ensure unique params for overloaded functions without unique index too - so I thing Its possible. It's same mechanism. regards Pavel Stehule > regards, tom lane > ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] proposal: generic function, constructor function
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > I propose two kinds of functions: > a) generic functions - this function allows any params without any > implicit casting (it can implemented only in C language). Can't you do that already with ANYELEMENT, or at the worst ANY? > It allows unspecified number of params > without parser changes. Why is that a good idea (and if you think it won't take parser changes, you're wrong)? > Limits: only one function with specified name can exists in schema. This is why it's a bad idea. Please note that the unique index on pg_proc cannot enforce that, even if we wanted such a restriction. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] proposal: generic function, constructor function
Hello
I propose two kinds of functions:
a) generic functions - this function allows any params without any
implicit casting (it can implemented only in C language). This
function have to have specified return type. It usable for constructor
function and for some other. It allows unspecified number of params
without parser changes. There are not limits for params (only max
number) and there are not any implicit casting. Any parameter can take
additional tag with AS keyword.
Limits: only one function with specified name can exists in schema.
Sample:
CREATE FUNCTION format(any)
RETURNS text LANGUAGE C ;
SELECT format(1, 'aaa' AS b, ARRAY[1,2,3]) -> '(1, b:"aaa",[1,2,3])'
generic function can be well used for constructor function
b) constructor function - this function returns typed composite or
array value. It's in conformance with ANSI SQL. Constructor function
is any generic function where name is same like any composite type or
domain. Behave of constructor is same for all types.
Sample:
CREATE TYPE ftype AS (a integer, b integer);
SELECT ftype(), ftype(10), ftype(10,20); ->
(NULL, NULL), (10,NULL), (10,20) ~ (10,20)::ftype
CREATE DOMAIN fdom AS int[];
SELECT fdom(), fdom(10,20,30); ->
'{}','{10,20,30}'; ~ it's eq ARRAY[10,20,30]::int[];
Why constructors?
Composite values are referenced in SQL/PSM. When I wont to fill
composite variables directly, I have to call constructor before:
DECLARE v mytype;
SET v = mytype();
SET v.f = 10; ~ or shortly SET v = mytype(10);
Any comments are welcome
Regards
Pavel Stehule
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] modularity of PostgreSQL
On Jan 17, 2008 6:46 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Uh, does anyone authoritative describe it that way? I think we can > legitimately claim that Postgres is pretty extensible, but as for > modularity I'm not sure that it's got any great claim to fame. > To me modularity connotes an emphasis on dividing the system into > pieces separated by carefully-defined, small-footprint interfaces, > and we have not done spectacularly well on that score. Agreed. Postges is extensible, not modular. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Problem with correct compiling and linking server side C function on Windows ,c++ Builder
Hello I tried to find soultion for this problem on -cygwin list , but there they sent me to teh list -win32. But I foun on the site that this is that list (also -hacker-win32),so I came here to -hackers. My problem is as follows , maybe you can help me: I ma working on a server-side function written in "C" which should get a bytea type image - simple jpg picture , resize and compress it with defined paramters and return also a bytea type. I made working test code that worked fine as a console program. My boss demands it to be compiled in Windows (postgreSQL server is running on Windows 2003) , so I created this project in Borland C++ Builder 6.0. I am not using Cygwin. PostgreSQL C external function has to be built into dll , so I created new project DLL Wizard - C style dll. Later I changed some code , and pasted it to the DLL "C" style , and wanted to build dll. My Code: - #include "postgres.h " #include#include #include #include #include #include "jerror.h" #include "jpeglib.h" #pragma argsused extern __declspec(dllexport) bytea* kompresuj(bytea* obrazek,int zdjwyj_sz, int zdjwyj_w,int stkompr); int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { return 1; } struct my_error_mgr { struct jpeg_error_mgr pub; jmp_buf setjmp_buffer; }; typedef struct my_error_mgr *my_error_ptr; void my_error_exit(j_common_ptr cinfo) { my_error_ptr myerr = (my_error_ptr) cinfo->err; (*cinfo->err->output_message) (cinfo); longjmp(myerr->setjmp_buffer, 1); } int czytajwymiarywej(char *filename,int wymiary[]) {struct jpeg_decompress_struct cinfo; struct my_error_mgr jerr; FILE *infile; if ((infile = open(filename, O_RDONLY|O_BINARY,S_IREAD)) == NULL) { return -1; } jerr.pub.error_exit = my_error_exit; cinfo.err = jpeg_std_error(&jerr.pub); jpeg_CreateDecompress(&cinfo,JPEG_LIB_VERSION,(size_t)sizeof(cinfo)); if (setjmp(jerr.setjmp_buffer)) { jpeg_destroy_decompress(&cinfo); fclose(infile); return -2; } jpeg_stdio_src(&cinfo, infile); (void) jpeg_read_header(&cinfo, TRUE); wymiary[0] = cinfo.image_width; wymiary[1] = cinfo.image_height; jpeg_destroy_decompress(&cinfo); return 0; } int read_jpeg(j_decompress_ptr cinfoptr, unsigned char **image_buffer,int *image_width, int *image_height) { JSAMPARRAY jpeg_buffer; long int i_buffer, i_image; (void) jpeg_start_decompress(cinfoptr); *image_buffer = (unsigned char *) malloc(*image_width * *image_height * (*cinfoptr).out_color_components* sizeof(unsigned char)); if (*image_buffer == NULL) { (void) jpeg_finish_decompress(cinfoptr); jpeg_destroy_decompress(cinfoptr); return -3; } jpeg_buffer = (*(*cinfoptr).mem->alloc_sarray)((j_common_ptr) cinfoptr, JPOOL_IMAGE,(*cinfoptr).output_width * (*cinfoptr).output_components, 1); i_image = 0; while ((*cinfoptr).output_scanline < (*cinfoptr).output_height) { (void) jpeg_read_scanlines(cinfoptr, jpeg_buffer, 1); if ((*cinfoptr).output_components == 3) { for (i_buffer = 0; (unsigned)i_buffer < (*cinfoptr).output_width * (*cinfoptr).output_components; i_buffer++, i_image++) (*image_buffer)[i_image] = jpeg_buffer[0][i_buffer]; } } (void) jpeg_finish_decompress(cinfoptr); jpeg_destroy_decompress(cinfoptr); return 0; } int write_jpeg(j_compress_ptr cinfoptr, unsigned char *image_buffer,int quality, int image_width, int image_height) { JSAMPROW row_pointer[1]; if (quality < 0) quality = 0; else if(quality > 100) quality = 100; jpeg_set_quality(cinfoptr, quality, FALSE); jpeg_start_compress(cinfoptr, TRUE); while ((*cinfoptr).next_scanline < (*cinfoptr).image_height) { row_pointer[0] = &image_buffer[(*cinfoptr).next_scanline* image_width * (*cinfoptr).input_components]; (void) jpeg_write_scanlines(cinfoptr, row_pointer, 1); } jpeg_finish_compress(cinfoptr); jpeg_destroy_compress(cinfoptr); return 0; } bytea* kompresuj(bytea* obrazek,int zdjwyj_sz, int zdjwyj_w,int stkompr) { int rc;unsigned char *zdjwej,*zdjwyj; int zdjwej_w, zdjwej_sz; int jakosc,i, j, k, ib, jb; double ratio; int rozmiar; bytea* zdjwyjwyn; /* Dekompresja - ustawianie obiektu cinfo */ struct jpeg_decompress_struct cinfo; struct my_error_mgr jerr; /* Kompresja dane do kompresji */ struct jpeg_compress_struct cinfokompr; struct my_error_mgr jerr1; /* */ //typedef void* declspec(dllimport) funkcjaTYP (MemoryContext,Size); //HINSTANCE uchwytDLL = LoadLibrary("libecpg.dll");
Re: [HACKERS] testing result overview (was: 8.3 beta testing suggestions welcome)
>>> On Tue, Aug 21, 2007 at 1:12 PM, in message <[EMAIL PROTECTED]>, Greg Smith <[EMAIL PROTECTED]> wrote: > My suggestion for a starting 8.3 configuration for you would be adjusting > these settings as follows: > > shared_buffers=1GB > checkpoint_segments = 50 > > And then try replaying your data with checkpoint_completion_target at 0.5 > (default), 0.7, and 0.9 and see how each of those works out for you (0.7 > is the least useful of those if you only did two). Hopefully the data > replay you have can be setup to invoke the same tightly spaced checkpoint > behavior you commented about. Under 8.2.4, 8.2.5, 8.3beta4 and a recent compile of the CVS tip, the test machine (4 2 GHz Xeons with 6 GB RAM) was unable to create the clusters of timeouts which we saw on the production box (8 3GHz Xeons with 12 GB RAM), in spite of concerted efforts to recreate the conditions. It's possible that updates to PostgreSQL or the OS have made the difference, although I think it's more likely that the larger OS cache and/or the higher CPU power of the production box are needed to create the problem on this type of disk array. We're working on getting a couple new boxes on line, which will allow us to test using the current production box, but that's weeks away. Performance under 8.3 is better in general, and there is a very noticeable smoothing of the output spikes at the OS level. I didn't notice much difference in vmstat output with the different checkpoint_completion_target settings. Our testing methoodology involved playing transaction streams from both our replication engine and our web site, at the same time, against the test server, through the normal middle tier software we use in production. We have timestamps on all of it, which allowed us to play the streams at various percentages of the production load. Based on the timeouts from the web renderers (which cancel a request if the middle tier hasn't responded within 20 seconds), the middle tier metrics of actual run time once the request is pulled from the request queue, and the vmstat output, 8.3 shows significant performance improvement as long as the fix for the OUTER JOIN optimizer regression is used (that is, with a recent checkout from the CVS tip, or beta/RC with Tom's patch applied). -Kevin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Recent pg_regress changes break testing under SELinux
Who decided this part of pg_regress.c was a good idea? /* try to create the test tablespace dir if it doesn't exist */ snprintf(testtablespace, MAXPGPATH, "%s/testtablespace", abs_builddir); if (directory_exists(testtablespace)) rmtree(testtablespace, true); make_directory(testtablespace); The regression test Makefile is responsible for preparing that directory, not pg_regress. This is important because in the Postgres RPMs, we have to be careful to appease SELinux: # The tests command the server to write into testtablespace and results. # On a SELinux-enabled system this will fail unless we mark those directories # as writable by the server. cleandirs: -rm -rf testtablespace results mkdir testtablespace results [ -x /usr/bin/chcon ] && /usr/bin/chcon -u system_u -r object_r -t postgresql_db_t testtablespace results By blowing away the directory and remaking it, pg_regress causes this carefully-applied labeling to be lost. As far as I can see the rmtree/make_directory thrashing is useless, and I'm going to remove it unless a pretty good counter-argument is made. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Recent pg_regress changes break testing under SELinux
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Who decided this part of pg_regress.c was a good idea? > Hmm, AFAICS it was applied by me in 1.26, a patch from Magnus > apparently. This was quite some time ago! I think I just passed that > part verbatim from Magnus' patch. Hmm ... I wonder if the unstated agenda was to run the regression tests without having any supporting Makefile? I'd be willing to make it #ifdef WIN32, instead of diking it out entirely, if that's what the problem is. I would prefer to remove it though. The original design had only the Makefile knowing exactly where the testtablespace directory lurks, making it changeable in one place, and also confining the whole business to src/test/regress which is good because none of the other uses of pg_regress need it. As CVS tip stands, the location of testtablespace is hard-wired into the pg_regress executable, and I think it's mostly blind accident that it doesn't clutter contrib/* and src/pl/* with testtablespace directories. At this point what I'd really prefer is that pg_regress be completely uninvolved with testtablespace, which we could manage by getting rid of @testtablespace@ in the regression test files in favor of @abs_builddir@/testtablespace. This would mean that both the Makefile and the regression test files know where the directory lurks, but either of those are easier to change than a precompiled binary. Now this isn't gonna work if there's a prerequisite for pg_regress to execute without any external setup, but surely we don't expect users to enter all its switch arguments by hand. What's the actual intended arrangement on Windows ... is there a .BAT script or something that could make the directory? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] proposal: generic function, constructor function
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote: >> Can't you do that already with ANYELEMENT, or at the worst ANY? > I would to have independent parameters and move type checking to > function. Okay, then you want ANY. > Then I don't need register function exactly and then I can > have different numbers of arguments. The different-numbers-of-arguments bit is what I'm objecting to. Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY), etc, and you're done without breaking anything else. > we can use partial unique index, if it is possible - I didn't test it. It's not --- partial indexes on system catalogs are not supported, and pg_proc is certainly one catalog that that restriction will never be relaxed for. (How you going to execute a predicate without doing function lookups?) I don't believe that the constraint could be expressed as a partial index predicate anyway --- how will you say that foo(...) and foo(int) conflict, but foo(int) and foo(int,int) don't? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Traveling to London
Bruce, > FYI, I am leaving for London tomorrow/Saturday to do training for > EnterpriseDB and a breakfast event: Right when I'm coming to New York, too. Darn it! (I'll be in NYC Jan 21-25). -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
