Re: [PATCHES] psql \! WIN32 cleanup
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The attached applied patch tests for COMSPEC in the right place and supplies a reasonable shell default on Win32. + #define DEFAULT_SHELL c:/windows/system32/cmd.exe Is it really a good idea to assume that the Windows installation is on drive C: ? (This is an honest question, not a rhetorical one. I dunno whether inserting the C: is better than leaving it off. I can think of cases where either way will break, but I'm unsure what's most likely in practice.) Not sure. Should we just do /windows/system32/cmd.exe and leave off the C:? The previous default was /bin/sh and that certainly will not work on Win32. I think another path to try if COMSPEC is not defined is: %SystemRoot%/system32/cmd.exe Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] CVS should die
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Can this be discussed for 8.1? It's been discussed, and rejected, several times already. There aren't any alternatives that are enough better than CVS to be worth the changeover effort. The effort is not so big: http://cvs2svn.tigris.org Do not rename or move around a file because your SCM limits, is insane. Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] additional GCC warning flags
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: -Wpointer-arith might be worth enabling. I'll add it to the GCC CFLAGS in the next patch I send in. If PG builds cleanly or nearly so with it on, by all means. As you said, -Wcast-align can't be enabled in general at the moment because it flags a ton of warnings on certain platforms (at least on IA64, probably other 64-bit platforms as well). Yes, HPPA as well. I have long harbored a wish to clean this up but it never gets to the top of the to-do list. I am not sure that it would really repay the effort to make the code clean against this --- I can only recall one or two bugs in the last several years that this might have caught. When I looked at the current gcc Info docs, I noticed that there seem to be several new warning types that might be worth turning on. Did you consider others beyond the three you're proposing now? Time ago I compiled 8.0 using gcc 4.0 with a bunch of warning, did you see my post ? I report it here: -- Hi all, I succesfull compiled postgres 8.0beta2 with a recent gcc 4.0 snapshot: gcc (GCC) 4.0.0 20040911 (experimental) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # select version(); version - PostgreSQL 8.0.0beta2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.0 20040911 (experimental) (1 row) All the tests passed, however I had a bunch of warning during the compilation, the more common was: left-hand operand of comma expression has no effect These are some examples: = gist.c: In function `gistlayerinsert': gist.c:463: warning: left-hand operand of comma expression has no effect gist.c: In function `gistreadbuffer': gist.c:644: warning: left-hand operand of comma expression has no effect gist.c: In function `gistchoose': gist.c:1479: warning: left-hand operand of comma expression has no effect = pg_conversion.c: In function `pg_convert_using': pg_conversion.c:334: warning: pointer targets in passing arg 1 of `strlen' differ in signedness = nbtinsert.c: In function `_bt_insertonpg': nbtinsert.c:380: warning: 'itup_blkno' may be used uninitialized in this function nbtinsert.c:379: warning: 'itup_off' may be used uninitialized in this function = pg_proc.c: In function `match_prosrc_to_query': pg_proc.c:915: warning: pointer targets in passing arg 1 of `pg_mbstrlen_with_len' differ in signedness pg_proc.c:929: warning: pointer targets in passing arg 1 of `pg_mbstrlen_with_len' differ in signedness pg_proc.c: In function `match_prosrc_to_literal': pg_proc.c:982: warning: pointer targets in passing arg 1 of `pg_mblen' differ in signedness = orindxpath.c: In function `best_or_subclause_indexes': orindxpath.c:258: warning: 'best_indexinfo' may be used uninitialized in this function orindxpath.c:260: warning: 'best_indexquals' may be used uninitialized in this function orindxpath.c:259: warning: 'best_indexclauses' may be used uninitialized in this function orindxpath.c:261: warning: 'best_startup_cost' may be used uninitialized in this function orindxpath.c:262: warning: 'best_total_cost' may be used uninitialized in this function = createplan.c: In function `create_plan': createplan.c:1244: warning: 'opclass' may be used uninitialized in this function = Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] error report on slru.c
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: here a patch that 1) Rise the information about the file missing on pg_clog from detail to error This violates the message style guidelines, IMHO. Tom, your opinion is not humble but is is really appreciated, however I think that a missing file is not a detail information. 2) Insert the offset information also for a missing file It's hardly necessary, since the transaction number tells you everything you need to know if you really need it, and the offset is certainly not relevant to a file-open failure. Good to know, how is possible then retrive the informations about the file needed and the offset without rise the logs detail ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] error report on slru.c
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: This violates the message style guidelines, IMHO. My first impression is that it should be swapped. The error is that the file could not be opened. The detail is that the files is related to transaction status information. No, the error is that the transaction status couldn't be accessed. The fact that it is stored in a file is implementation detail, and primary messages should not focus on implementation detail. Right, so the only way a DBA have is to look the details! Is there another way to know the file and the offset a transaction belong to ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] psql tab-completion improvements
Bruce Momjian wrote: Neil Conway wrote: Bruce Momjian wrote: Is this for 8.0? Seems it is fixes. Personally, I think it is more feature work than fixes. But I wouldn't object to committing it to HEAD in time for 8.0, because it is likely low-impact. That was my feeling. Part fix, part low impact. Is there a low impact concept that override the feature freeze ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] 8.0 libpq: missing get_home_path()
Bruce Momjian wrote: OK, patch attached and applied. I also updated the docs. Just a note for the docs: %USERPROFILE%/.pgpass shall be not %USERPROFILE%\.pgpass ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] psql - missing tab-completion support for tablespaces
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: When looking through the code I found that there seem to be much more places where the tabcomplete-code is not 100% in sync with what the doc's show as possible syntax. Is there interest in fixing those up (ie qualifing as BUGS that can get fixed during BETA) ? If so I could take a look at those in the next days ... Yes, please send in any tab completion improvements you can make. Thanks. About this I usefull have in the rollback to tab tab the list of save point, I did the autocomplete patch for the nested transaction but I was not able to retrieve the active savepoints, is it really impossible to hack that part ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pg_ctl.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Momjian wrote: | Gaetano Mendola wrote: | |Bruce Momjian wrote: | | |Here is the C version of pg_ctl.c written by Andrew Dunstan and updated |by me. | |You can use it by creating a src/bin/pg_ctl_test directory and putting |the C and Makefile into that directory. You can then do a make install |and use it for testing. | |Unless someone finds a problem, I will apply the change soon. This |removes our last shell script! | |It desn't compile on my platform: | |$ gcc -I /usr/include/pgsql/server pg_ctl.c |pg_ctl.c: In function `start_postmaster': |pg_ctl.c:219: error: `DEVNULL' undeclared (first use in this function) |pg_ctl.c:219: error: (Each undeclared identifier is reported only once |pg_ctl.c:219: error: for each function it appears in.) | | | DEVNULL is in CVS port.h. Are you running against CVS? No. Against 7.4.1 |2) xstrdup protected by duplicate NULL string | | | You mean that you can't pass NULL to xstrdup? Yea, but if we do, it | will crash and we will hear about it right away. Yea u'r right, it will crash without know why, for the same reason you can avoid to use the xstrdup then. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAtE3h7UpzwH2SGd4RAjDhAKDV8lRn7XEAGqHLBJzQTvrBlyJsXgCgrw5c CljcRIysGU3+IGoVbHU9vYg= =9jrs -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pg_ctl.c
Andrew Dunstan wrote: Gaetano Mendola wrote: Bruce Momjian wrote: however below the result of my quich review: 1) exit(1) = exit(EXIT_FAILURE) If we used a number of different error codes I might agree. But it seems pointless here, and the style is widely used in our code base (I just counted 201 other occurrrences, not including cases of exit(0) ). This doesn't mean that we don't have to. 2) xstrdup protected by duplicate NULL string I don't object, but it is redundant - in every case where it is called the argument is demonstrably not NULL. Now it's true, and in the future ? Bruce was arguing about that check that if the string is null the program simply will exit crashing! I really appreciate the quality software of Postgres but some time I don't understand why test NULL pointer is an overkill for you. I mean xstrdup is supposed to be the strdup safe version, and without that control is not safe, why don't use directly the strdup then ? If there is no memory available before postgresql start go figure after! Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_ctl.c
Bruce Momjian wrote:
Here is the C version of pg_ctl.c written by Andrew Dunstan and updated
by me.
You can use it by creating a src/bin/pg_ctl_test directory and putting
the C and Makefile into that directory. You can then do a make install
and use it for testing.
Unless someone finds a problem, I will apply the change soon. This
removes our last shell script!
It desn't compile on my platform:
$ gcc -I /usr/include/pgsql/server pg_ctl.c
pg_ctl.c: In function `start_postmaster':
pg_ctl.c:219: error: `DEVNULL' undeclared (first use in this function)
pg_ctl.c:219: error: (Each undeclared identifier is reported only once
pg_ctl.c:219: error: for each function it appears in.)
however below the result of my quich review:
1) exit(1) = exit(EXIT_FAILURE)
2) xstrdup protected by duplicate NULL string
I seen also that you don't use always the _ macro for error display.
Regards
Gaetano Mendola
*** pg_ctl.c2004-05-26 02:48:38.0 +0200
--- pg_ctl.c.orig 2004-05-26 02:43:32.0 +0200
***
*** 26,33
/* postmaster version ident string */
#define PM_VERSIONSTR postmaster (PostgreSQL) PG_VERSION \n
- #define EXIT_FAILURE 1
-
typedef enum
{
--- 26,31
***
*** 100,106
if (!result)
{
fprintf(stderr, _(%s: out of memory\n), progname);
! exit(EXIT_FAILURE);
}
return result;
}
--- 98,104
if (!result)
{
fprintf(stderr, _(%s: out of memory\n), progname);
! exit(1);
}
return result;
}
***
*** 112,130
{
char *result;
-
- if (!s)
- {
- fprintf(stderr, %s: can not duplicate null pointer, progname);
- exit(EXIT_FAILURE);
- }
-
-
result = strdup(s);
if (!result)
{
fprintf(stderr, _(%s: out of memory\n), progname);
! exit(EXIT_FAILURE);
}
return result;
}
--- 110,120
{
char *result;
result = strdup(s);
if (!result)
{
fprintf(stderr, _(%s: out of memory\n), progname);
! exit(1);
}
return result;
}
***
*** 146,152
else
{
perror(openning pid file);
! exit(EXIT_FAILURE);
}
}
fscanf(pidf, %ld, pid);
--- 136,142
else
{
perror(openning pid file);
! exit(1);
}
}
fscanf(pidf, %ld, pid);
***
*** 353,359
else
{
fprintf(stderr, %s: cannot read %s\n, progname,
postopts_file);
! exit(EXIT_FAILURE);
}
}
else if (optlines[0] == NULL || optlines[1] != NULL)
--- 343,349
else
{
fprintf(stderr, %s: cannot read %s\n, progname,
postopts_file);
! exit(1);
}
}
else if (optlines[0] == NULL || optlines[1] != NULL)
***
*** 361,367
fprintf(stderr, %s: option file %s must have exactly 1
line\n,
progname, ctl_command == RESTART_COMMAND ?
postopts_file : def_postopts_file);
! exit(EXIT_FAILURE);
}
else
{
--- 351,357
fprintf(stderr, %s: option file %s must have exactly 1
line\n,
progname, ctl_command == RESTART_COMMAND ?
postopts_file : def_postopts_file);
! exit(1);
}
else
{
***
*** 411,417
but was not the same version as
\%s\.\n
Check your installation.\n),
progname, progname);
! exit(EXIT_FAILURE);
}
postgres_path = postmaster_path;
}
--- 401,407
but was not the same version as
\%s\.\n
Check your installation.\n),
progname, progname);
! exit(1);
}
postgres_path = postmaster_path;
}
***
*** 428,434
%s: cannot start postmaster\n
Examine
Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Conway wrote: | Tom Lane wrote: | | Maybe the best documentation answer is to create a new subsection in the | Functions chapter. This may be our first standard set-returning | function but I bet it will not be the last, so the shortness of the | subsection doesn't bother me. | | | A first shot at documentation for generate_series() is available here in | html form: | http://www.joeconway.com/functions-srf.html I seen there: select * from generate_series(5,1,-2); ~ generate_series - - ~ 5 ~ 3 ~ 1 (3 rows) I understood on your past posts that instead this result was obtained with: select * from generate_series(5,1,2); ~ generate_series - - ~ 5 ~ 3 ~ 1 (3 rows) I think that is better have: ~ if start end the series is ascending ~ if start end the series is descending ~ if step 0 the series is ascending ~ if step 0 the series is descending ~ ( step can not be 0 ) if ( start end ) and ( step 0 ) the result set is empty if ( start end ) and ( step 0 ) the result set is empty IMHO this is the more natural behavior. my 2 cents. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAIYxo7UpzwH2SGd4RAnr9AJ4//4AO9VaIQmweneB0BJe8DvKJQgCfSJOF ejQN8TlGBjvntxoBJgk3uIk= =HcPJ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] New List
Neil Conway wrote: Gaetano Mendola [EMAIL PROTECTED] writes: 10E6 INSERT = real 0m5.161s user 0m4.010s sys0m1.150s What operation is this benchmarking? Only linked-list appends, or something else? Only the head append. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] New List
Hi all, in the thread equal() perf tweak I and Neil we were discussing about the new implementation of a list. We add a little discussion on how implement it these are my results: 1) Neil list and length linear time 10E6 INSERT = real 0m5.161s user 0m4.010s sys0m1.150s 2) Neil list and length constant time 10E6 INSERT = real 0m5.232s user 0m4.200s sys0m1.030s 3) stl::list fashion and length linear time 10E6 INSERT = real 0m5.352s user 0m4.260s sys0m1.090s 4) stl::list fashion and length constant time 10E6 INSERT = real 0m5.480s user 0m4.340s sys0m1.110s this show, at list on my HW Pentium III (Coppermine) 870.587 MHz 256 KB cache that implement the length in constant time is almost the same ( less than 2% of the total time) This show also that the classical implementation win vs the stl::list fashion. We shall consider also that in case of stl::list all methods are inlined, I tried also inlining the function replacing the function call with the body function: 5) Neil list real 0m4.909s user 0m3.790s sys0m1.110s 6) stl::list real 0m5.146s user 0m3.980s sys0m1.090s So at the end I think that the best solution is the Neil classical proposal and mantain the length function constant time. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] equal() perf tweak
Bruce Momjian wrote: Is there a TODO here? I'm just evaluating the performances of two version the one proposed by Neil and the one in a stl::list fashion. Tom suggested also to see if is the case to implement the function size() constant time or not. Regards Gaetano Mendola. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] SIGPIPE handling, take two.
Gaetano Mendola wrote:
Bruce Momjian wrote:
I think this is the patch I like. It does the auto-detect handling as I
hoped. I will just do the doc updates to mention it.
My only issue is that this is per-connection, while I think you have to
create a global variable that defaults to false, and on first connect,
check, and not after. Based on the code below, a second connection
would have the SIGPIPE signal set to SIG_IGN, not SIG_DEF, and you
would be back to setting SIG_IGN around each send, even though it was
already set.
Are others OK with this too?
I believe that the are some errors on the following code:
#if !defined(HAVE_POSIX_SIGNALS)
{
pqsigfunc old;
old = signal(SIGPIPE, SIG_IGN);
if (old != SIG_DFL)
conn-do_sigaction = false;
signal(SIGPIPE, old);
}
#else
{
struct sigaction oact;
if (sigaction(SIGPIPE, NULL, oact) == 0 oact.sa_handler !=
SIG_DFL)
conn-do_sigaction = false;
}
#endif /* !HAVE_POSIX_SIGNALS */
the old signal handler is not reinstated in case of
HAVE_POSIX_SIGNAL
Forget the message :-)
Gaetano
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[PATCHES] cancel 3FB0C0CE.6050007@bigfoot.com
This message was cancelled from within Mozilla. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] equal() perf tweak
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: [ use list with master node and circular linking ] now is very late here ( 04:17 AM ) so I wrote the wrong code ( not checked ) but show the idea of avoid if. This saves an if during addition of a list item, at the cost of greater expense during list traversal. (Instead of a loop termination test like ptr != NULL, you need something like ptr != master_node. This may not take an extra cycle, but only if you can afford to dedicate a register to holding the value of master_node within the loop. That hurts, especially on architectures with not very many registers.) Well, if the same architecture have not so many register I guess don't have a double prefetch instruction queue and an if branch will hurt/destroy that queue, am I wrong ? I'm going to post on comp.lang.c++.moderated and comp.std.c++ in order to have better argumentations Anyway, we should build the code that way and then do profiling with and without support for constant-cost length(). I totally agree with you. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] equal() perf tweak
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: [ use list with master node and circular linking ] now is very late here ( 04:17 AM ) so I wrote the wrong code ( not checked ) but show the idea of avoid if. This saves an if during addition of a list item, at the cost of greater expense during list traversal. (Instead of a loop termination test like ptr != NULL, you need something like ptr != master_node. This may not take an extra cycle, but only if you can afford to dedicate a register to holding the value of master_node within the loop. That hurts, especially on architectures with not very many registers.) Well, if the same architecture have not so many register I guess don't have a double prefetch instruction queue and an if branch will hurt/destroy that queue, am I wrong ? I'm going to post on comp.lang.c++.moderated and comp.std.c++ in order to have better argumentations Anyway, we should build the code that way and then do profiling with and without support for constant-cost length(). I totally agree with you. Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] equal() perf tweak
Neil Conway wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
Why instead of reinvent the whell not use, or at least do a C port of
stl::list ?
Because (a) implementing a linked list is pretty trivial (b) the only
difficult part is getting the semantics / API right. I don't see how
std::list would help with (b), and (a) negates the benefit of
importing the code from elsewhere.
We'd also have to gut std::list, since we wouldn't be able to make use
of C++ templates.
That said, if you know of any specific techniques from std::list
implementations that would be useful, please let me know.
An interesting think that stl::list do is to never do
an if branch during an insert/remove phase, an stl::list is a struct
with a Master Node:
struct node
{
void* value;
node* next;
node* prev;
}
struct list
{
node* master_node;
};
here respect your proposal a node is saved.
an empty list is initialized with:
master_node = [ ... create a node ... ]
master_node-next = master_node;
master_node-prev = master_node;
and the insertion phase sound like:
void
AddHead(list *l, node *e)
{
node *where = l-master_node-next;
e-next = where;
e-prev = where-prev;
where-prev-next = e;
where-prev = e;
}
void
AddTail(list *l, node *e)
{
node *where = l-master_node;
e-next = where;
e-prev = where-prev;
where-prev-next = e;
where-prev = e;
}
now is very late here ( 04:17 AM ) so I wrote
the wrong code ( not checked ) but show the idea of
avoid if.
PS: My 2 cents: I don't like too much have the lenght inside the list
struct.
Why not?
What if you will never call the size() on a list doing massive
insert ? May be we need two list, depending on the way we are going
to use it?
I'm too much C++ oriented and another very weak argument is: for the
same reason that STL (at least in gcc) doesn't have it:
http://gcc.gnu.org/ml/gcc-bugs/1998-12/msg00270.html
may be the third point not apply to us.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] pg_autovacuum README patch
Gaetano Mendola wrote: --- README.good 2003-10-21 02:40:19.0 +0200 +++ README 2003-10-21 02:37:43.0 +0200 @@ -1,3 +1,3 @@ -PG_autovacuum README +pg_autovacuum README @@ -148,8 +148,8 @@ vacuum analyze is performed. -AnalyzeThreshold is equal to: +deleteThreshold is equal to: vacuum_base_value + (vacuum_scaling_factor * number of tuples in the table) -VacuumThreshold is equal to: +insertThreshold is equal to: analyze_base_value + (analyze_scaling_factor * number of tuples in the table) Was I wrong ? Regards Gaeatano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] pg_autovacuum README patch
--- README.good 2003-10-21 02:40:19.0 +0200 +++ README 2003-10-21 02:37:43.0 +0200 @@ -1,3 +1,3 @@ -PG_autovacuum README +pg_autovacuum README @@ -148,8 +148,8 @@ vacuum analyze is performed. -AnalyzeThreshold is equal to: +deleteThreshold is equal to: vacuum_base_value + (vacuum_scaling_factor * number of tuples in the table) -VacuumThreshold is equal to: +insertThreshold is equal to: analyze_base_value + (analyze_scaling_factor * number of tuples in the table) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql italian translation
Peter Eisentraut wrote: Fabrizio Mazzoni writes: I just translated the psql.pot file into Italian language and tested it in 7.4beta3. Installed. But please check out psql --help and \? within psql and line up the strings correctly. I don't know if there is some problem but some messages are not translated in psql. The thing is that these messages are not present in the .pot file .. Anyway if you want to check you must check the SQL help for the DROP command and you will see it for yourself. Works here: peter=# \help DROP TABLE Comando: DROP TABLE Descrizione: elimina una tabella Sinstassi: DROP TABLE nome [, ...] [ CASCADE | RESTRICT ] Please see my post ( I choose the wron address) on hackers, there are some typos on the traslation. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Waiting the patch applied
Peter Eisentraut wrote: Gaetano Mendola writes: one question just to know the right action to take: After having submitted a patch in order to work on a new patch shall I open another fresh CVS snapshot or shall I work on top of my old patch not yet applied ( or refused )? Since applying the patch will change the CVS header in the affected files, this will mess up your next diff. Details depend on how you work exactly, but I remember having been burned by this exact issue several times. If your new work depends on your old patch being applied, then you'll just have to keep an extended set of working and reference trees around. Ok, I will take a fresh sandbox then. Thank you Gaetano Mendola ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Waiting the patch applied
Hi, one question just to know the right action to take: After having submitted a patch in order to work on a new patch shall I open another fresh CVS snapshot or shall I work on top of my old patch not yet applied ( or refused )? Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] strdup = xstrdup patche
Hi, I think that I cover know all strdup not checked on the tree backend. I'm going to investigate now for malloc unchecked. Regards Gaetano Mendola psql.patch Description: Binary data ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] strdup = xstrdup patche
Mendola Gaetano [EMAIL PROTECTED] wrote: Hi, I think that I cover know all strdup not checked on the tree backend. Of course I forgot to remove the null pointer check inside the xstrdup, please use this patch instead. Regards Gaetano Mendola psql.patch Description: Binary data ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] mcxt.c
Tom Lane [EMAIL PROTECTED] wrote:
Mendola Gaetano [EMAIL PROTECTED] writes:
A test for null string is missing here:
MemoryContextStrdup(MemoryContext context, const char *string)
{
char *nstr;
-
- if ( !string )
- {
- elog(ERROR, MemoryContextStrdup called with a NULL pointer);
- return NULL;
- }
This seems inappropriate to me. Are you going to suggest that every
routine that takes a pointer parameter needs to explicitly test for
null? We could bloat the code a great deal that way, and slow it down,
without gaining anything at all in debuggability (IMHO anyway).
Of course I'm not suggesting this, what I'm suggesting is put an
assert( ) if the test can slow down the performances and an if ( )
in places that are not going to touch the performances.
I think that is reasonable.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[PATCHES] mcxt.c
A test for null string is missing here:
*** pgsql/src/backend/utils/mmgr/mcxt.c 2003-09-02 13:30:05.0 +0200
--- pgsql.old/src/backend/utils/mmgr/mcxt.c 2003-08-04 04:40:08.0
+0200
*** char *
*** 620,632
MemoryContextStrdup(MemoryContext context, const char *string)
{
char *nstr;
-
- if ( !string )
- {
- elog(ERROR, MemoryContextStrdup called with a NULL pointer);
- return NULL;
- }
-
Size len = strlen(string) + 1;
nstr = (char *) MemoryContextAlloc(context, len);
--- 620,625
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
