Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> > > Earlier, Vadim was talking about arranging to share fsyncs of the WAL > > > log file across transactions (after writing your commit record to the > > > log, sleep a few milliseconds to see if anyone else fsyncs before you > > > do; if not, issue the fsync yourself). That would offer less-than- > > > one-fsync-per-transaction performance without giving up any > > > guarantees. > > > If people feel a compulsion to have a tunable parameter, let 'em tune > > > the length of the pre-fsync sleep ... > > > > Already implemented (without ability to tune this parameter - > > xact.c:CommitDelay, - yet). Currently CommitDelay is 5, so > > backend sleeps 1/200 sec before checking/forcing log fsync. > > But it returns _completed_ to the client before sleeping, right? No. Vadim
Re: [HACKERS] int4 or int32
> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> I think that int32 etc are better choices at the C level because of > >> the well-established precedent for naming integer types after numbers > >> of bits in C code. I don't feel any strong urge to go around and > >> change the existing misusages, but if you want to, I won't object. > > > Tom, I am wondering. If we don't change to int4/int8 internally now, > > will we ever do it? > > As I thought I'd just made clear, I'm against standardizing on int4/int8 > at the C level. The average C programmer would think that "int8" is > a one-byte type, not an eight-byte type. There's way too much history > behind that for us to swim against the tide. Having different naming > conventions at the C and SQL levels seems a better approach, especially > since it will exist to some extent anyway (int != integer, for > instance). OK. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] int4 or int32
Bruce Momjian <[EMAIL PROTECTED]> writes: >> I think that int32 etc are better choices at the C level because of >> the well-established precedent for naming integer types after numbers >> of bits in C code. I don't feel any strong urge to go around and >> change the existing misusages, but if you want to, I won't object. > Tom, I am wondering. If we don't change to int4/int8 internally now, > will we ever do it? As I thought I'd just made clear, I'm against standardizing on int4/int8 at the C level. The average C programmer would think that "int8" is a one-byte type, not an eight-byte type. There's way too much history behind that for us to swim against the tide. Having different naming conventions at the C and SQL levels seems a better approach, especially since it will exist to some extent anyway (int != integer, for instance). regards, tom lane
Re: [HACKERS] int4 or int32
> Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Which one of these should we use? > > int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no > > DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has > > PG_GETARG_INT32 et al. Inconsistency everywhere. > > The original convention was to use int4 etc at the SQL level, int32 etc > at the C level. However the typedefs int4 etc have to be visible in > the include/catalog/pg_*.h headers, and so there's been a certain amount > of leakage of those typedefs into the C sources. > > I think that int32 etc are better choices at the C level because of > the well-established precedent for naming integer types after numbers > of bits in C code. I don't feel any strong urge to go around and > change the existing misusages, but if you want to, I won't object. > > I also have to plead guilty to having changed all the float-datatype > code to use float4 and float8 recently. This was mainly because the > existing typedefs for float32 and float64 had a built-in assumption > that these types would always be pass-by-reference, and I wanted to > abstract the code away from that assumption. We can't touch those > typedefs for a release or three (else we'll break existing user > functions written in C), so switching to the SQL-level names seemed > like the best bet. But it's not real consistent with the integer-type > naming conventions :-( Tom, I am wondering. If we don't change to int4/int8 internally now, will we ever do it? The function manager change seems like the only good time to do it, if we ever will. Basically, I am asking if we should drop backward C compatibility for 7.1 and bite the bullet on the change? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: [PATCHES] A Patch for MIC to EUC_TW code convertingin mbsupport
Can someone tell me where we are on this? Tatsuo, I think you said you wanted to apply this fix. > [Cced to hackers list] > > > > BTW I have found another bug with EUC_TW support. line 917 in conv.c: > > > > > > *p++ = c1 - LC_CNS11643_3 + 0xa3; > > > > > > this should be: > > > > > > *p++ = *mic++ - LC_CNS11643_3 + 0xa3; > > > > > > Otherwise, CNS 11643-1992 Plane 3 or more won't work. Could you test > > > it out with CNS 11643-1992 Plane 3 or more? > > > > Thanks for your very quickly reply!! > > You are welcome. > > > I think you are right, but I have not test it. > > Because original Big5 encoding does not contain characters in CNS 11643-1992 > > Plane 3. > > But I will have a chance to test it, we here are seeking the support for Big5E > > (an extendied Big5 > > encoding) in PostgreSQL. Though most people who use PostgresSQL in Taiwan only > > cares about > > Big5 encoding . > > > > Would you like to answer some mb related questions for me? I am a newbie :P > > > > 1.) Because the 2nd byte of Big5 encoding overlaps with ASCII, > > such as '\' (this is very bad for many programs to work with Big5). > > As long as frontend side knows the current client side encoding is > Big5, this should be no problem. At least for libpq. It examins the > first byte of Big5. If it is greater than 0x7f, then it must be a > double byte Hanji. So libpq reads 2 bytes in this case, not matter the > second byte is '\'. > > > For example: If we initdb -E MULE_INTERNAL first, > > SET CLIENT_ENCODING TO 'BIG5', and > > INSERT INTO some_table VALUES (..., 'the last byte of some Big5 char is > > backslash\',...), > > then we can not successfully complete this SQL INSERT -- the prompt of psql > > changes > > but psql does not execute it. If we initdb -E with EUC_TW, it's OK. > > Is this is a parsing problem? What's your suggestion for the solution? > > Hum. initdb -E MULE_INTERNAL should work as well. Let me dig into the > problem. It would be nice if you could send me the Big5 data for > testing by a private mail. > > BTW I would not recommend "SET CLIENT_ENCODING TO 'BIG5'" to do an > on-the-fly encoding changes. Since in this way, frontend side has no > idea what the client encoding is. 7.0.x overcome this problem by > introducing new \encoding command. For 6.5 or before I would recommend > to use PGCLIENTENCODING environment variable. > > > 2.) Is using MULE_INTERNAL faster than EUC_TW as backend encoding when > > PostgreSQL processing Big5 data? (It seems > > BIG5->big52mic()->mic2euc_tw()->EUC_TW > > needs 2 code converting procedures, but BIG5->big52mic()->EUC_TW only needs > > one from > > the mb sources) > > Yes. But the difference would be very small. The expensive part is a > table look-up in big52mic. > > BTW 7.1 will support automatic encoding conversion between Unicode > (UTF-8) and Big5 (or EUC_TW). Try the snapshot if you like. > > > 3.) Dose PostgreSQL's ODBC driver support mb? > > I don't think so. For Japanese (EUC_JP/SJIS) Kataoka has made patches > to enable MB support in ODBC. It should not be very difficult to > support EUC_TW/Big5, I don't know. > -- > Tatsuo Ishii > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Syslog Facility Patch
Applied.
> Here is one with a stray character removed.
>
>
> Index: src/backend/utils/misc/guc-file.l
> ===
> RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
> retrieving revision 1.4
> diff -c -r1.4 guc-file.l
> *** src/backend/utils/misc/guc-file.l 2000/07/27 19:49:18 1.4
> --- src/backend/utils/misc/guc-file.l 2000/11/15 19:50:32
> ***
> *** 16,21
> --- 16,22
> #include
> #include
> #include
> + #include
>
> #include "miscadmin.h"
> #include "storage/fd.h"
> ***
> *** 32,37
> --- 33,39
> GUC_INTEGER = 3,
> GUC_REAL = 4,
> GUC_EQUALS = 5,
> + GUC_UNQUOTED_STRING = 6,
> GUC_EOL = 99,
> GUC_ERROR = 100
> };
> ***
> *** 45,51
>
> /* prototype, so compiler is happy with our high warnings setting */
> int GUC_yylex(void);
> !
> %}
>
> SIGN("-"|"+")
> --- 47,53
>
> /* prototype, so compiler is happy with our high warnings setting */
> int GUC_yylex(void);
> ! char *GUC_scanstr(char *);
> %}
>
> SIGN("-"|"+")
> ***
> *** 61,77
> LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
>
> ID {LETTER}{LETTER_OR_DIGIT}*
> - /*
> - * FIXME: This string syntax is nice and all but of course the quotes
> - * need to be stripped before we can make any use of the string value.
> - * There is a function in parser/scansup.c that does this but it uses
> - * palloc and there might be a little more magic needed to get it to
> - * work right. Now there are no string options, and if there were then
> - * the unquoted (`ID') tokens should still work. Of course this only
> - * affects the configuration file.
> - */
> - STRING \'([^'\n]|\\.)*'
>
> %%
>
> \n ConfigFileLineno++; return GUC_EOL;
> --- 63,72
> LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
>
> ID {LETTER}{LETTER_OR_DIGIT}*
>
> + UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._:/])*
> + STRING \'([^'"\n]|\\.)*\'
> +
> %%
>
> \n ConfigFileLineno++; return GUC_EOL;
> ***
> *** 80,85
> --- 75,81
>
> {ID}return GUC_ID;
> {STRING}return GUC_STRING;
> + {UNQUOTED_STRING} return GUC_UNQUOTED_STRING;
> {INTEGER} return GUC_INTEGER;
> {REAL} return GUC_REAL;
> = return GUC_EQUALS;
> ***
> *** 139,145
> int elevel;
> FILE * fp;
>
> ! Assert(context == PGC_POSTMASTER || context == PGC_BACKEND || context ==
>PGC_SIGHUP);
> Assert(DataDir);
> elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
>
> --- 135,142
> int elevel;
> FILE * fp;
>
> ! Assert(context == PGC_POSTMASTER || context == PGC_BACKEND
> ! || context == PGC_SIGHUP);
> Assert(DataDir);
> elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
>
> ***
> *** 210,220
> if (token == GUC_EQUALS)
> token = yylex();
>
> ! if (token != GUC_ID && token != GUC_STRING && token != GUC_INTEGER
>&& token != GUC_REAL)
> goto parse_error;
> opt_value = strdup(yytext);
> if (opt_value == NULL)
> goto out_of_memory;
> parse_state = 2;
> break;
>
> --- 207,230
> if (token == GUC_EQUALS)
> token = yylex();
>
> ! if (token != GUC_ID && token != GUC_STRING &&
> ! token != GUC_INTEGER && token != GUC_REAL &&
> ! token != GUC_UNQUOTED_STRING)
> goto parse_error;
> opt_value = strdup(yytext);
> if (opt_value == NULL)
> goto out_of_memory;
> + if (token == GUC_STRING)
> + {
> + /* remove the beginning and ending quote/apostrophe */
> + /* first: shift the whole shooting match down one
> + character */
> + memmove(opt_value,opt_value+1,strlen(opt_value)-1);
> + /* second: null out the 2 characters we shifted */
> + opt_value[strlen(opt_value)-2]='\0';
> + /* do the escape thing. free()'s the strdup above */
> + opt_value=GUC_scanstr(opt_value);
> + }
> parse_state = 2;
> break;
>
> ***
> *** 266,272
> FreeFile(fp);
> free(filename);
> free_name_value_list(head);
> ! elog(elevel, CONFIG_FILENAME ":%u: syntax error", ConfigFileLineno);
> return;
>
>out_of_memory:
> --- 276,28
Re: [HACKERS] Syslog Facility Patch
Sorry, this was not applied. Seems it is already fixed.
> * Peter Eisentraut <[EMAIL PROTECTED]> [001113 23:52]:
> > Okay, but you can't make these options PGC_SIGHUP unless you make sure to
> > close and re-open the syslog channel whenever these options
> > change. Probably ought to be PGC_POSTMASTER.
> Here is a patch to change to PGC_POSTMASTER...
>
>
> Index: guc.c
> ===
> RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
> retrieving revision 1.19
> diff -c -r1.19 guc.c
> *** guc.c 2000/11/14 01:15:02 1.19
> --- guc.c 2000/11/14 13:11:33
> ***
> *** 309,317
> {"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
>"", NULL},
> #ifdef ENABLE_SYSLOG
> ! {"syslog_facility", PGC_SIGHUP, &Syslog_facility,
> "LOCAL0", check_facility},
> ! {"syslog_progid", PGC_SIGHUP, &Syslog_progid,
> "postgres", NULL},
> #endif
>
> --- 309,317
> {"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
>"", NULL},
> #ifdef ENABLE_SYSLOG
> ! {"syslog_facility", PGC_POSTMASTER, &Syslog_facility,
> "LOCAL0", check_facility},
> ! {"syslog_progid", PGC_POSTMASTER, &Syslog_progid,
> "postgres", NULL},
> #endif
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Syslog Facility Patch
Applied.
> * Peter Eisentraut <[EMAIL PROTECTED]> [001113 23:52]:
> > Okay, but you can't make these options PGC_SIGHUP unless you make sure to
> > close and re-open the syslog channel whenever these options
> > change. Probably ought to be PGC_POSTMASTER.
> Here is a patch to change to PGC_POSTMASTER...
>
>
> Index: guc.c
> ===
> RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
> retrieving revision 1.19
> diff -c -r1.19 guc.c
> *** guc.c 2000/11/14 01:15:02 1.19
> --- guc.c 2000/11/14 13:11:33
> ***
> *** 309,317
> {"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
>"", NULL},
> #ifdef ENABLE_SYSLOG
> ! {"syslog_facility", PGC_SIGHUP, &Syslog_facility,
> "LOCAL0", check_facility},
> ! {"syslog_progid", PGC_SIGHUP, &Syslog_progid,
> "postgres", NULL},
> #endif
>
> --- 309,317
> {"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
>"", NULL},
> #ifdef ENABLE_SYSLOG
> ! {"syslog_facility", PGC_POSTMASTER, &Syslog_facility,
> "LOCAL0", check_facility},
> ! {"syslog_progid", PGC_POSTMASTER, &Syslog_progid,
> "postgres", NULL},
> #endif
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.cxlog.c)
[ Charset ISO-8859-1 unsupported, converting... ] > > Earlier, Vadim was talking about arranging to share fsyncs of the WAL > > log file across transactions (after writing your commit record to the > > log, sleep a few milliseconds to see if anyone else fsyncs before you > > do; if not, issue the fsync yourself). That would offer less-than- > > one-fsync-per-transaction performance without giving up any > > guarantees. > > If people feel a compulsion to have a tunable parameter, let 'em tune > > the length of the pre-fsync sleep ... > > Already implemented (without ability to tune this parameter - > xact.c:CommitDelay, - yet). Currently CommitDelay is 5, so > backend sleeps 1/200 sec before checking/forcing log fsync. But it returns _completed_ to the client before sleeping, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] 486 Optimizations...
> * Peter Eisentraut <[EMAIL PROTECTED]> [001115 08:15] wrote: > > > > I couldn't say I like these options, because they seem arbitrary, but > > given that it only affects the 0 univel users and the 3 bsdi users left > > (freebsd will be fixed), I wouldn't make a fuzz. > > BSDi still has a market niche, and they are actively porting to > more platforms. The template/bsdi file has: case $host_cpu in i?86) CFLAGS="$CFLAGS -m486";; esac Leave to BSDI to do it right. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: UUNET socket-file-location patch
> Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Tom Lane writes: > and make "/tmp" the default in guc.c. > >> > >> No, because this has to work on the client side too. The default path > >> *must* be determined at compile time, or clients and servers will be > >> unable to find each other. > > > The only difference between your snippet and mine is that yours sets the > > default to "" and interprets it as "/tmp" when it is used, whereas mine > > sets the default to "/tmp" to begin with. Clients don't see the > > difference. > > Clients that don't contain guc.c are going to see a difference, no? > Where are they getting the default from? Good point. This macro is called by the backend, and the libpq frontend code. We would have to push the /tmp default into libpq code too, which seems messier. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Coping with 'C' vs 'newC' function language namesh
At 23:42 15/11/00 -0500, Bruce Momjian wrote: >> To answer another misconception that I saw in this thread: >> >> : The old language names "internal" and "C" will continue to refer to >> : functions with the old calling convention. We should deprecate >> : old-style functions because of their portability problems, but the >> : support for them will only be one small function handler routine, >> : so we can leave them in place for as long as necessary. > >My question is can we drop newC and use just plain C in 7.2 or 7.3? I plan to work on a a proposal for a (hopefully) version independant function manager interface; the idea behind the proposal is to allow PGSQL to query the modules for information about the functions, but calling a single known entry point. The information stored in the database relation would be substantially reduced, and the backends would load the module then enquire about the functions, storing the results in memory. The kind of SQL required would be: Create Function foo(int4, int4) from library 'path-to-lib'; and possibly, Create Module foo_mod from library 'path-to-lib'; The idea being to only store whe function signature and enough details to get to the info-function. If 'Create Module' were allowed, then it would automatically create appropriate function definitions when the statement was executed. The info-function would return data in a struct passed from the backend, and part of the struct would include version information. The backend would then be responsible for handling new & old protocols. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] SearchSysCacheTuple(Copy)
> 4. SearchSysCacheTupleCopy() goes away, since we may as well use >SearchSysCacheTuple() and ReleaseSysCache() instead of >SearchSysCacheTupleCopy() and heap_freetuple(). Agreed. The rest sounds good too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Coping with 'C' vs 'newC' function language namesh
> To answer another misconception that I saw in this thread: > > : The old language names "internal" and "C" will continue to refer to > : functions with the old calling convention. We should deprecate > : old-style functions because of their portability problems, but the > : support for them will only be one small function handler routine, > : so we can leave them in place for as long as necessary. My question is can we drop newC and use just plain C in 7.2 or 7.3? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] int4 or int32
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Which one of these should we use? > int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no > DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has > PG_GETARG_INT32 et al. Inconsistency everywhere. The original convention was to use int4 etc at the SQL level, int32 etc at the C level. However the typedefs int4 etc have to be visible in the include/catalog/pg_*.h headers, and so there's been a certain amount of leakage of those typedefs into the C sources. I think that int32 etc are better choices at the C level because of the well-established precedent for naming integer types after numbers of bits in C code. I don't feel any strong urge to go around and change the existing misusages, but if you want to, I won't object. I also have to plead guilty to having changed all the float-datatype code to use float4 and float8 recently. This was mainly because the existing typedefs for float32 and float64 had a built-in assumption that these types would always be pass-by-reference, and I wanted to abstract the code away from that assumption. We can't touch those typedefs for a release or three (else we'll break existing user functions written in C), so switching to the SQL-level names seemed like the best bet. But it's not real consistent with the integer-type naming conventions :-( regards, tom lane
Re: [HACKERS] termcap and curses
Peter Eisentraut <[EMAIL PROTECTED]> writes: > To start with, what do we need libtermcap and libcurses for? Readline > requires one or the other, but not both. Anything else? I think that psql once required these. It probably does not anymore (except indirectly via readline). There's certainly no reason to be linking them into the backend. Try yanking 'em and see what happens. On HPUX, at least, it would be real nice not to include libcurses; some genius thought it would be OK to define a function named select() in libcurses ... regards, tom lane
[HACKERS] WAL and offline backups
One question: will Postgres 7.1 be able to do offline backups? -- "And I'm happy, because you make me feel good, about me." - Melvin Udall - Martín Marqués email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] Syslog Facility Patch
Here is one with a stray character removed.
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.4
diff -c -r1.4 guc-file.l
*** src/backend/utils/misc/guc-file.l 2000/07/27 19:49:18 1.4
--- src/backend/utils/misc/guc-file.l 2000/11/15 19:50:32
***
*** 16,21
--- 16,22
#include
#include
#include
+ #include
#include "miscadmin.h"
#include "storage/fd.h"
***
*** 32,37
--- 33,39
GUC_INTEGER = 3,
GUC_REAL = 4,
GUC_EQUALS = 5,
+ GUC_UNQUOTED_STRING = 6,
GUC_EOL = 99,
GUC_ERROR = 100
};
***
*** 45,51
/* prototype, so compiler is happy with our high warnings setting */
int GUC_yylex(void);
!
%}
SIGN("-"|"+")
--- 47,53
/* prototype, so compiler is happy with our high warnings setting */
int GUC_yylex(void);
! char *GUC_scanstr(char *);
%}
SIGN("-"|"+")
***
*** 61,77
LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
ID {LETTER}{LETTER_OR_DIGIT}*
- /*
- * FIXME: This string syntax is nice and all but of course the quotes
- * need to be stripped before we can make any use of the string value.
- * There is a function in parser/scansup.c that does this but it uses
- * palloc and there might be a little more magic needed to get it to
- * work right. Now there are no string options, and if there were then
- * the unquoted (`ID') tokens should still work. Of course this only
- * affects the configuration file.
- */
- STRING \'([^'\n]|\\.)*'
%%
\n ConfigFileLineno++; return GUC_EOL;
--- 63,72
LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
ID {LETTER}{LETTER_OR_DIGIT}*
+ UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._:/])*
+ STRING \'([^'"\n]|\\.)*\'
+
%%
\n ConfigFileLineno++; return GUC_EOL;
***
*** 80,85
--- 75,81
{ID}return GUC_ID;
{STRING}return GUC_STRING;
+ {UNQUOTED_STRING} return GUC_UNQUOTED_STRING;
{INTEGER} return GUC_INTEGER;
{REAL} return GUC_REAL;
= return GUC_EQUALS;
***
*** 139,145
int elevel;
FILE * fp;
! Assert(context == PGC_POSTMASTER || context == PGC_BACKEND || context ==
PGC_SIGHUP);
Assert(DataDir);
elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
--- 135,142
int elevel;
FILE * fp;
! Assert(context == PGC_POSTMASTER || context == PGC_BACKEND
! || context == PGC_SIGHUP);
Assert(DataDir);
elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
***
*** 210,220
if (token == GUC_EQUALS)
token = yylex();
! if (token != GUC_ID && token != GUC_STRING && token != GUC_INTEGER
&& token != GUC_REAL)
goto parse_error;
opt_value = strdup(yytext);
if (opt_value == NULL)
goto out_of_memory;
parse_state = 2;
break;
--- 207,230
if (token == GUC_EQUALS)
token = yylex();
! if (token != GUC_ID && token != GUC_STRING &&
! token != GUC_INTEGER && token != GUC_REAL &&
! token != GUC_UNQUOTED_STRING)
goto parse_error;
opt_value = strdup(yytext);
if (opt_value == NULL)
goto out_of_memory;
+ if (token == GUC_STRING)
+ {
+ /* remove the beginning and ending quote/apostrophe */
+ /* first: shift the whole shooting match down one
+ character */
+ memmove(opt_value,opt_value+1,strlen(opt_value)-1);
+ /* second: null out the 2 characters we shifted */
+ opt_value[strlen(opt_value)-2]='\0';
+ /* do the escape thing. free()'s the strdup above */
+ opt_value=GUC_scanstr(opt_value);
+ }
parse_state = 2;
break;
***
*** 266,272
FreeFile(fp);
free(filename);
free_name_value_list(head);
! elog(elevel, CONFIG_FILENAME ":%u: syntax error", ConfigFileLineno);
return;
out_of_memory:
--- 276,283
FreeFile(fp);
free(filename);
free_name_value_list(head);
! elog(elevel, CONFIG_FILENAME ":%u: syntax error, token=\"%s\"",
! ConfigFileLineno,yytext);
return;
out_of_memory
Re: [HACKERS] Syslog Facility Patch
* Peter Eisentraut <[EMAIL PROTECTED]> [001115 13:11]:
> Larry Rosenman writes:
>
> > > syntax is lexically compatible with the syntax of the SET command.
> > > Therefore you can't have "funny" characters in 'value' unless
> > > single-quoted.
> > I added period(.), hyphen(-), and underscore(_).
>
> Probably '/' and ':' as well, for krb_server_keyfile.
Added.
>
> > ! UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._])*
> > ! STRING (\'|\")([^'"\n]|\\.)*(\'|\")
>
> That will accept strings that start with one kind of quote and end with
> another. Please stick to single-quotes only, unless you want to make a
> case for the double-quotes.
Done.
>
> I'm also not quite sure about
>
> > + if (s[i] == '\'')
> > + {
> > +
> > + /*
> > +* Note: if scanner is working right, unescaped quotes can
> > +* only appear in pairs, so there should be another character.
> > +*/
> > + i++;
> > + newStr[j] = s[i];
> > + }
>
> The SQL scanner accepts 'foo''bar' as the SQL-approved method of escaping
> quotes in quotes. GUC doesn't do that (way too complicated for now), so
> this probably needs to be adjusted.
Removed.
>
> Other than that, looks good.
I also added the token that caused the parse error to be printed out.
I also added some whitespace on a couple of places that the lines
were getting, err, long.
New Version:
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.4
diff -c -r1.4 guc-file.l
*** src/backend/utils/misc/guc-file.l 2000/07/27 19:49:18 1.4
--- src/backend/utils/misc/guc-file.l 2000/11/15 19:34:54
***
*** 16,21
--- 16,22
#include
#include
#include
+ #include
#include "miscadmin.h"
#include "storage/fd.h"
***
*** 32,37
--- 33,39
GUC_INTEGER = 3,
GUC_REAL = 4,
GUC_EQUALS = 5,
+ GUC_UNQUOTED_STRING = 6,
GUC_EOL = 99,
GUC_ERROR = 100
};
***
*** 45,51
/* prototype, so compiler is happy with our high warnings setting */
int GUC_yylex(void);
!
%}
SIGN("-"|"+")
--- 47,53
/* prototype, so compiler is happy with our high warnings setting */
int GUC_yylex(void);
! char *GUC_scanstr(char *);
%}
SIGN("-"|"+")
***
*** 61,77
LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
ID {LETTER}{LETTER_OR_DIGIT}*
- /*
- * FIXME: This string syntax is nice and all but of course the quotes
- * need to be stripped before we can make any use of the string value.
- * There is a function in parser/scansup.c that does this but it uses
- * palloc and there might be a little more magic needed to get it to
- * work right. Now there are no string options, and if there were then
- * the unquoted (`ID') tokens should still work. Of course this only
- * affects the configuration file.
- */
- STRING \'([^'\n]|\\.)*'
%%
\n ConfigFileLineno++; return GUC_EOL;
--- 63,72
LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
ID {LETTER}{LETTER_OR_DIGIT}*
+ UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._:/×])*
+ STRING \'([^'"\n]|\\.)*\'
+
%%
\n ConfigFileLineno++; return GUC_EOL;
***
*** 80,85
--- 75,81
{ID}return GUC_ID;
{STRING}return GUC_STRING;
+ {UNQUOTED_STRING} return GUC_UNQUOTED_STRING;
{INTEGER} return GUC_INTEGER;
{REAL} return GUC_REAL;
= return GUC_EQUALS;
***
*** 139,145
int elevel;
FILE * fp;
! Assert(context == PGC_POSTMASTER || context == PGC_BACKEND || context ==
PGC_SIGHUP);
Assert(DataDir);
elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
--- 135,142
int elevel;
FILE * fp;
! Assert(context == PGC_POSTMASTER || context == PGC_BACKEND
! || context == PGC_SIGHUP);
Assert(DataDir);
elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
***
*** 210,220
if (token == GUC_EQUALS)
token = yylex();
! if (token != GUC_ID && token != GUC_STRING && token != GUC_INTEGER
&& token != GUC_REAL)
goto parse_error;
opt_value = strdup(yytext);
if (opt_value == NULL)
goto out_of_memory;
parse_state = 2;
break;
--- 207,230
if (token == GUC_EQUALS)
token = yylex();
! if (token != GUC_ID && token != GUC_STRING &&
! token != GU
[HACKERS] int4 or int32
Which one of these should we use? int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has PG_GETARG_INT32 et al. Inconsistency everywhere. The C standard has things like int32_t, but technically there's no guarantee that int32 is really 32 bits, you only know sizeof(int32) == 4. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] termcap and curses
So Sun has pulled another one on us. Not sure which versions of Solaris this affects, but some have libncurses and libtermcap with overlapping symbols of different sizes. This leads to a bunch of complaints every time 'ld' is run; perhaps it could also lead to busted executables. (Via a complex chain of events this also causes the AC_HEADER_STDC in 7.0*'s configure to fail, which is the underlying cause of the regular bug reports about something from stdarg.h (va_xxx) undefined.) To start with, what do we need libtermcap and libcurses for? Readline requires one or the other, but not both. Anything else? I'm not going to do anything about this now, but if we get more of these it'd be good to be prepared. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
RE: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> > I am just suggesting that instead of flushing the log on every > > transaction end, just do it every X seconds. > > Or maybe more practical is, when the log buffer fills. > And of course during checkpoints. Also before backend's going to write dirty buffer from pool to system cache - changes must be logged before reflected in data files. Vadim
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
markw <[EMAIL PROTECTED]> writes: > Just a question, however, what is the feeling about the way statistics are > currently being calculated? They suck, no question about it ;-) > My feeling is that some sort of windowing > algorithm be used to normalize the statistics to the majority of the entries > in a table. It could be as simple as discarding the upper and lower 10% of > the record stats, and use the remaining 80% for statistics. I think what most of the discussion has focused on is building histograms. The current upper-and-lower-bounds-only approach just plain isn't enough data, even if you discard outliers so that the data isn't actively misleading. As far as the most-common-value issue goes, if you have one value that is vastly more common than any other, I think it would be a real mistake to throw away that information --- that would mean the planner would do the wrong thing for queries that do involve that value. What we need is to save info about several top-frequency values, maybe three or so, not just one. Also the finding of those values needs to be much more robust than it is currently. See past discussions in pghackers --- there have been plenty... regards, tom lane
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
At 01:53 PM 11/15/00 -0500, markw wrote:
>I'd rather not pollute the application's SQL with postgres-isms. Not that I
>don't love postgres, but there are always critics looking for a reason to use
>Oracle or (gasp) MS-SQL.
Define some global variable with the name of the database being run (currently
only Postgres) and guard the SET statement with a conditional...
In the OpenACS project we've got little functions that return query snippets
called things like "db_nextval" that return either "sequence_name.nextval"
or "nextval('sequence_name')" depending on whether the code's running
under Oracle or Postgres. That helps us minimize differences in the source.
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
RE: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> Earlier, Vadim was talking about arranging to share fsyncs of the WAL > log file across transactions (after writing your commit record to the > log, sleep a few milliseconds to see if anyone else fsyncs before you > do; if not, issue the fsync yourself). That would offer less-than- > one-fsync-per-transaction performance without giving up any > guarantees. > If people feel a compulsion to have a tunable parameter, let 'em tune > the length of the pre-fsync sleep ... Already implemented (without ability to tune this parameter - xact.c:CommitDelay, - yet). Currently CommitDelay is 5, so backend sleeps 1/200 sec before checking/forcing log fsync. Vadim
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
Andrew McMillan wrote: > mlw wrote: > > > > My music database has 50,000 arises and 210,000 albums. Many artists > > have only one or 2 entries in the albums table (for the youngsters, CD > > table ;-). About 34,000 have the integer key for "Various Artists" as > > their artist entry, and another few thousand have things like "Movie > > Soundtrack" and so on. > > > > When the statistics are computed, these relatively few records with a > > huge number of relations distort the statistics and make it impossible > > to get postgres to use an index on that table without the -fs switch. > > > > This is bad because it always forces use of an index, even when postgres > > would legitimately ignore it. > > What about doing: > SET enable_seqscan TO 'Off'; > Just before the query in question? > > That way you'd only affect the single query. Possibly you could even > code to spot the two aberrant situations and not do it in those ones. I'd rather not pollute the application's SQL with postgres-isms. Not that I don't love postgres, but there are always critics looking for a reason to use Oracle or (gasp) MS-SQL. As for "code to spot.." I am fairly new to hacking postgres. (Though, I have been using it in various projects since ~1995), but I am excellent C/C++ guy, give me a pointer to where (a) statistics are calculated, and (b) where they are interpreted, and I would do that. Just a question, however, what is the feeling about the way statistics are currently being calculated? My feeling is that some sort of windowing algorithm be used to normalize the statistics to the majority of the entries in a table. It could be as simple as discarding the upper and lower 10% of the record stats, and use the remaining 80% for statistics. That would certainly take care of my problem (and others I am sure), and I'd be glad to write it. ;-) > > > Regards, > Andrew. > -- > _ > Andrew McMillan, e-mail: [EMAIL PROTECTED] > Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington > Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
At 09:27 AM 11/15/00 -0800, Tom Samplonius wrote: > AOLServer isn't the only system that can pool database connections, so >can servlets/JSP, ColdFusion, ASP, etc. No doubt AOLServer would be more >widely accepted if it used something other than TCL. There are two separate modules that support Java in AOLserver: ns_tomcat which provides an identical interface as Apache tomcat (and no real advantages) and ns_java, which is coming out of the OpenACS project. ns_java exposes AOLserver's pooled, persistent database API to java. There's also support available for Python, though there's still a lot of work to be done to support the full AOLserver API (same's true of ns_java, actually). If you use ADP pages, your use of Tcl is typically restricted to snippets of code anyway, so I've never really understood the complaints about Tcl... - Don Baccus, Portland OR <[EMAIL PROTECTED]> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
Re: [HACKERS] Syslog Facility Patch
* Peter Eisentraut <[EMAIL PROTECTED]> [001115 10:26]:
> Larry Rosenman writes:
>
> > Ok, so what I think(?) needs to happen is the FIXME: tag needs to be
> > handled. We need to code a version of src/backend/parser/scansup.c
> > that doesn't use palloc, and also strips the apostrophes from the
> > front and end of the string? This doesn't look that hard. Do I have
> > "permission" to play with it, and submit a patch when I've got it
> > fixed?
>
> Some background information: The current
>
> name = value
>
> syntax is lexically compatible with the syntax of the SET command.
> Therefore you can't have "funny" characters in 'value' unless
> single-quoted.
I added period(.), hyphen(-), and underscore(_).
>
> Now in the context of the config file this seems overly restrictive.
> Therefore I'd agree that we relax that a bit and allow more characters to
> go into 'value' unquoted. I'm not quite sure which, but to prevent
> confusion I'd prefer no semicolons, whitespace, or equal signs, possibly
> others.
>
> This would require making 'value' a different token type from 'name',
> because the latter should not accept these characters.
done, as GUC_UNQUOTED_STRING.
>
> Additionally, the FIXME ought to be done. I'd prefer it if it accepted
> the exact same escapes and all as does the SQL parser/scanner. So it
> ought to be a copy and paste from scansup.c. I'm not excited about
> allowing double-quotes though.
Done. Added as GUC_scanstr.
Here is a patch. Comments?
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.4
diff -c -r1.4 guc-file.l
*** src/backend/utils/misc/guc-file.l 2000/07/27 19:49:18 1.4
--- src/backend/utils/misc/guc-file.l 2000/11/15 18:13:20
***
*** 16,21
--- 16,22
#include
#include
#include
+ #include
#include "miscadmin.h"
#include "storage/fd.h"
***
*** 32,37
--- 33,39
GUC_INTEGER = 3,
GUC_REAL = 4,
GUC_EQUALS = 5,
+ GUC_UNQUOTED_STRING = 6,
GUC_EOL = 99,
GUC_ERROR = 100
};
***
*** 45,51
/* prototype, so compiler is happy with our high warnings setting */
int GUC_yylex(void);
!
%}
SIGN("-"|"+")
--- 47,53
/* prototype, so compiler is happy with our high warnings setting */
int GUC_yylex(void);
! char *GUC_scanstr(char *);
%}
SIGN("-"|"+")
***
*** 69,76
* work right. Now there are no string options, and if there were then
* the unquoted (`ID') tokens should still work. Of course this only
* affects the configuration file.
*/
! STRING \'([^'\n]|\\.)*'
%%
--- 71,83
* work right. Now there are no string options, and if there were then
* the unquoted (`ID') tokens should still work. Of course this only
* affects the configuration file.
+ * LER 14NOV2000: I set it up to accept either a quoted string or a string
+ * in apostrophes. I then kill off the 1st and last characters. There is
+ * no special handling for doubled terminators or 'C' escapes.
+ * this allows most other characters to be used.
*/
! UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._])*
! STRING (\'|\")([^'"\n]|\\.)*(\'|\")
%%
***
*** 80,85
--- 87,93
{ID}return GUC_ID;
{STRING}return GUC_STRING;
+ {UNQUOTED_STRING} return GUC_UNQUOTED_STRING;
{INTEGER} return GUC_INTEGER;
{REAL} return GUC_REAL;
= return GUC_EQUALS;
***
*** 210,220
if (token == GUC_EQUALS)
token = yylex();
! if (token != GUC_ID && token != GUC_STRING && token != GUC_INTEGER
&& token != GUC_REAL)
goto parse_error;
opt_value = strdup(yytext);
if (opt_value == NULL)
goto out_of_memory;
parse_state = 2;
break;
--- 218,239
if (token == GUC_EQUALS)
token = yylex();
! if (token != GUC_ID && token != GUC_STRING && token != GUC_INTEGER
&& token != GUC_REAL && token != GUC_UNQUOTED_STRING)
goto parse_error;
opt_value = strdup(yytext);
if (opt_value == NULL)
goto out_of_memory;
+ if (token == GUC_STRING)
+ {
+ /* remove the beginning and ending quote/apostrophe */
+ /* first: shift the whole shooting match down one
+ character */
+ memmove(opt_value,opt_value+1,strlen(opt_value)-1);
+ /* second: null out the
Re: [HACKERS] Re: Commit finished?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> distclean does not remove gram.c because we include gram.c in the >> distribution. Perhaps there should be another target that gets rid >> of *all* the derived files (maintainer-clean might be the GNU-approved >> name for that, not sure). Peter, any comment here? > Not only that, but we've had it for several months... :-) Ah, my mistake. I looked in backend/parser/Makefile and didn't see any rule for maintainer-clean, so assumed it wasn't there yet :-( regards, tom lane
Re: [HACKERS] Re: UUNET socket-file-location patch
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: and make "/tmp" the default in guc.c. >> >> No, because this has to work on the client side too. The default path >> *must* be determined at compile time, or clients and servers will be >> unable to find each other. > The only difference between your snippet and mine is that yours sets the > default to "" and interprets it as "/tmp" when it is used, whereas mine > sets the default to "/tmp" to begin with. Clients don't see the > difference. Clients that don't contain guc.c are going to see a difference, no? Where are they getting the default from? regards, tom lane
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
On Wed, 15 Nov 2000, carl garland wrote: > >perhaps why, even at 5 clients, the page views he shows never went > >significantly above 10/sec? > > I think alot of it has to do with the web server/db setup not pg. They are > using Apache/PHP and looking at their code every page has the additional > overhead of making the db connection. Now if they had used AOLserver with > its persistent db connecction pooling scheme they may have faired better ;) I doubt it. PostgreSQL has a higher connection startup overhead than MySQL, so if every view required a new database connection, it would been quite a detriment to the PostgreSQL scores. PHP can maintain persisitant connections. Unfortunately, this means that you end up with a database connection per httpd process. That really isn't a problem for PostgreSQL though, it just requires sufficent memory. No doubt that is what was being done. AOLServer isn't the only system that can pool database connections, so can servlets/JSP, ColdFusion, ASP, etc. No doubt AOLServer would be more widely accepted if it used something other than TCL. Tom
WHERE-clause evaluation order (was [BUGS] Problem with BETWEEN and a view)
Andrew Snow <[EMAIL PROTECTED]> writes: > Here's a simpler script which reproduces the bug: Well, after looking at this some more, I'm not convinced it's a bug; or at least, if it's a bug it's one that can't be fixed without a fundamental redefinition of rules/views. Boiled down, here's what you are doing: CREATE TABLE Joy (x int4, z text); INSERT INTO Joy VALUES (1, 'i love postgresql'); INSERT INTO Joy VALUES (2, CURRENT_TIMESTAMP - '5 days'::interval); INSERT INTO Joy VALUES (3, CURRENT_TIMESTAMP + '5 days'::interval); CREATE VIEW foo AS SELECT z::timestamp AS Start FROM Joy WHERE x = 2; SELECT * FROM foo; start 2000-11-10 01:45:09-05 (1 row) SELECT * FROM foo WHERE Start < CURRENT_TIMESTAMP; ERROR: Bad timestamp external representation 'i love postgresql' Now the first select is OK because the WHERE clause filters out the rows that don't have timestamp-looking values of z before the SELECT's output values get evaluated. But the second SELECT gets expanded by the rule rewriter into SELECT z::timestamp AS Start FROM Joy WHERE x = 2 AND z::timestamp < CURRENT_TIMESTAMP; Then it's all a matter of what order the WHERE clauses happen to get applied in --- if the timestamp check gets applied first, the query fails with exactly the result you see. There is no guarantee that the clauses that came from inside the view will be applied before those that came from outside. Indeed, the planner would be very foolish to make such a guarantee, since the clauses coming from outside the view might be far more selective and/or might enable use of an index. In 7.1 it would be possible to force the view to be evaluated as an independently-planned subplan, and have the outer WHERE clauses be applied only as filters on the result. However, the performance implications of doing that are painful enough that I don't really want to do it. Essentially, we'd be lobotomizing the planner so that it would not be able to make any choices about when to evaluate WHERE clauses. This would cause it to miss a lot of good plans for queries involving views and sub-selects. The relevant part of SQL92 seems to be section 3.3.4.4 "Rule evaluation order". As far as I can tell, this leaves implementations a great deal of freedom to determine evaluation order of elements of a WHERE expression. Does anyone want to argue that the spec requires us to be stupid about evaluation order? regards, tom lane
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
On Wed, 15 Nov 2000, carl garland wrote: # >perhaps why, even at 5 clients, the page views he shows never went # >significantly above 10/sec? # # I think alot of it has to do with the web server/db setup not pg. They are # using Apache/PHP and looking at their code every page has the additional # overhead of making the db connection. Now if they had used AOLserver with # its persistent db connecction pooling scheme they may have faired better ;) I haven't actually looked at their code they used to test with to see if they are actually using it, but Apache/PHP has the ability to do persistent db connections. I would be surprised that someone like Tim ( who seems to have done a fair bit of php with db stuff) would not make use of such a feature. If you can point out an example of where they are not using this feature I will gladly stand corrected. | Joseph Scott The Office Of Water Programs | | [EMAIL PROTECTED] [EMAIL PROTECTED] |
Re: [HACKERS] 486 Optimizations...
* Peter Eisentraut <[EMAIL PROTECTED]> [001115 08:15] wrote: > > I couldn't say I like these options, because they seem arbitrary, but > given that it only affects the 0 univel users and the 3 bsdi users left > (freebsd will be fixed), I wouldn't make a fuzz. BSDi still has a market niche, and they are actively porting to more platforms. > > I do feel more strongly about removing '-pipe', but it's not something I'm > going to pursue. Why? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] Re: UUNET socket-file-location patch
Peter Eisentraut <[EMAIL PROTECTED]> writes: > #define UNIXSOCK_PATH(sun,port,defpath) \ > snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \ > (defpath), (port)) > and make "/tmp" the default in guc.c. No, because this has to work on the client side too. The default path *must* be determined at compile time, or clients and servers will be unable to find each other. I wouldn't object to having "/tmp" be given as a macro PG_STD_SOCKET_DIR in config.h, making it potentially configurable on a site-wide basis, but that's as far as I think we can go. regards, tom lane
Re: [HACKERS] Coping with 'C' vs 'newC' function language names
mlw <[EMAIL PROTECTED]> writes: > I'm not sure what "NewC" is, nor do I understand what problem it is > attempting to fix. I haven't gotten around to updating the main documentation yet (my bad) but the design document about the fmgr rewrite is in current sources as src/backend/utils/fmgr/README --- you can read it on the web at http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/backend/utils/fmgr/README if you don't have a local copy. The key issues are summarized in that document as: : We know that the existing mechanism for calling Postgres functions needs : to be redesigned. It has portability problems because it makes : assumptions about parameter passing that violate ANSI C; it fails to : handle NULL arguments and results cleanly; and "function handlers" that : support a class of functions (such as fmgr_pl) can only be done via a : really ugly, non-reentrant kluge. (Global variable set during every : function call, forsooth.) Here is a proposal for fixing these problems. To answer another misconception that I saw in this thread: : The old language names "internal" and "C" will continue to refer to : functions with the old calling convention. We should deprecate : old-style functions because of their portability problems, but the : support for them will only be one small function handler routine, : so we can leave them in place for as long as necessary. regards, tom lane
Re: [HACKERS] Re: UUNET socket-file-location patch
> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Peter Eisentraut <[EMAIL PROTECTED]> writes: > Should the parameter determine the directory or the full file name? I'd > go for the former, but it's not a strong case. > >> > >> Directory was what I had in mind too, but I'm not sure what Bruce > >> actually did ... > > > I did whatever the patch did. I believe it is the full path. I believe > > it is used here: > > > #define UNIXSOCK_PATH(sun,port,defpath) \ > > ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path, > > defpath, sizeof((sun).sun_path)), > > (sun).sun_path[sizeof((sun).sun_path)-1] = '\0') : > > sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port))) > > Hmm. I think it would make more sense to make the parameter be just > the directory, not the full path including filename --- for one thing, > doing it like that renders the port-number parameter useless. Why not > > #define UNIXSOCK_PATH(sun,port,defpath) \ > snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \ > (((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \ > (port)) I can do that. Of course, I have to now change all the documentation to match it. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Coping with 'C' vs 'newC' function language names
'Marko Kreen' wrote:
>
> On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
> >
> > > > We need the 7.0 style for compatibility with other DB's. Postgres was
> > > > "the" pioneer in this area, but similar functionality is now available in
>other DB's.
> > >
> > > Could you explain? PostgreSQL cant be compatible in C level, why
> > > the SQL compatibility? (I mean the LANGUAGE 'C' specifically)
> >
> > C code compatible with Informix:
> >
> > int32 intadd (int32 a, int32 b)
> > {
> > return a + b;
> > }
> >
> > This is the same code that was standard in PostgreSQL 7.0
>
> Hmm, I have not actually researched if 7.1 supports 7.0 'C' code
> or not. Butthe 'newC' is anyway incompatible with 'C'. So:
>
> * CREATE FUNCTION .. AS 'foo.so', .. LANGUAGE 'C';
>
> creates the old¬ 'C', 7.0 and ifnormix compatible funtion.
>
> And it is documented as deprecated, for-compatibility.
>
> * CREATE FUNCTION .. FROM LIBRARY 'foo.so.2' ..{name in .so}
> [WITH VERSION abi_ver]
> {the actual syntax needs polishing}
>
> creates by default the newC style fn's
> but WITH VERSION 0 (e.g.) you can create the old style
> functions too.
>
> Comments?
I generally like the idea, but I am working on a text index/search
project that will rely heavily on C interfacing with Postgres.
I'm not sure what "NewC" is, nor do I understand what problem it is
attempting to fix.
--
http://www.mohawksoft.com
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
carl garland wrote: > > >perhaps why, even at 5 clients, the page views he shows never went > >significantly above 10/sec? > > I think alot of it has to do with the web server/db setup not pg. They are > using Apache/PHP and looking at their code every page has the additional > overhead of making the db connection. Now if they had used AOLserver with > its persistent db connecction pooling scheme they may have faired better ;) PHP has a persistent PostgreSQL open pg_pConnect() and it does make a difference. I use postgres as a music database back-end for a PHP web server. (Actually it is a web farm, with many instances of the database, one per web server) The one problem I have had with Postgres is its stubborn refusal to use an index. I understand the reasons why it won't, but it is wrong, so I sped it up by starting the backends with -fs. That may be the issue. On a side note: I'm not sure of the current workings of the vacuum and statistics vs indexing issue, I am new to this list, but I do have a 7.0.2 relevant observation: My music database has 50,000 arises and 210,000 albums. Many artists have only one or 2 entries in the albums table (for the youngsters, CD table ;-). About 34,000 have the integer key for "Various Artists" as their artist entry, and another few thousand have things like "Movie Soundtrack" and so on. When the statistics are computed, these relatively few records with a huge number of relations distort the statistics and make it impossible to get postgres to use an index on that table without the -fs switch. This is bad because it always forces use of an index, even when postgres would legitimately ignore it. -- http://www.mohawksoft.com
Re: [HACKERS] Coping with 'C' vs 'newC' function language names
On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
>
> > > We need the 7.0 style for compatibility with other DB's. Postgres was
> > > "the" pioneer in this area, but similar functionality is now available in other
>DB's.
> >
> > Could you explain? PostgreSQL cant be compatible in C level, why
> > the SQL compatibility? (I mean the LANGUAGE 'C' specifically)
>
> C code compatible with Informix:
>
> int32 intadd (int32 a, int32 b)
> {
> return a + b;
> }
>
> This is the same code that was standard in PostgreSQL 7.0
Hmm, I have not actually researched if 7.1 supports 7.0 'C' code
or not. Butthe 'newC' is anyway incompatible with 'C'. So:
* CREATE FUNCTION .. AS 'foo.so', .. LANGUAGE 'C';
creates the old¬ 'C', 7.0 and ifnormix compatible funtion.
And it is documented as deprecated, for-compatibility.
* CREATE FUNCTION .. FROM LIBRARY 'foo.so.2' ..{name in .so}
[WITH VERSION abi_ver]
{the actual syntax needs polishing}
creates by default the newC style fn's
but WITH VERSION 0 (e.g.) you can create the old style
functions too.
Comments?
--
marko
AW: [HACKERS] Coping with 'C' vs 'newC' function language names
> > We need the 7.0 style for compatibility with other DB's. Postgres was
> > "the" pioneer in this area, but similar functionality is now available in other
>DB's.
>
> Could you explain? PostgreSQL cant be compatible in C level, why
> the SQL compatibility? (I mean the LANGUAGE 'C' specifically)
C code compatible with Informix:
int32 intadd (int32 a, int32 b)
{
return a + b;
}
This is the same code that was standard in PostgreSQL 7.0
Andreas
Re: [HACKERS] Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
>perhaps why, even at 5 clients, the page views he shows never went >significantly above 10/sec? I think alot of it has to do with the web server/db setup not pg. They are using Apache/PHP and looking at their code every page has the additional overhead of making the db connection. Now if they had used AOLserver with its persistent db connecction pooling scheme they may have faired better ;) _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: [HACKERS] Coping with 'C' vs 'newC' function language names
On Mon, Nov 13, 2000 at 09:58:30AM +0100, Zeugswetter Andreas SB wrote: > > > > because as said, it can be any other language besides C and also > > > the 'AS file' is weird. > > > > This is interesting. It allows us to control the default behavour of > > "C". I would vote to default to 7.0-style when no version is used for > > 7.1, then default to 7.1 style in 7.2 and later. We don't need > > backward C function compatibility for more than one release, I think. > > We need the 7.0 style for compatibility with other DB's. Postgres was > "the" pioneer in this area, but similar functionality is now available in other DB's. Could you explain? PostgreSQL cant be compatible in C level, why the SQL compatibility? (I mean the LANGUAGE 'C' specifically) I see already three different C interfaces: 1) 7.0.x 2) 7.1.x 3) > 7.1 where is possible to give a generic funtion/struct where the backend can guess the actual params, also with some docstrings, etc... Per-function interface needs not to change. How do you see it possible to solve with current LANGUAGE 'fooC' approach? -- marko
Re: [GENERAL] PHPBuilder article -- Postgres vs MySQL
On Lun 13 Nov 2000 13:22, Robert D. Nelson wrote: > > Still...Regardless of what database they're running, either their > abstraction layer is shit or their queries really need optimized. Is that > perhaps why, even at 5 clients, the page views he shows never went > significantly above 10/sec? In the article it was said that the querys were unoptimized to get the best out of the database. Tim said that with some changes to the querys they could have gotten much better results. Saludos... :-) -- "And I'm happy, because you make me feel good, about me." - Melvin Udall - Martín Marqués email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
