Re: [HACKERS] Failure to recognise new database
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> Is it just me? > I'm pretty sure I saw something similar on a newly initialized database. Are you guys running with WAL enabled? If so, this is probably the BufferSync issue that Hiroshi thought I broke a couple days ago. Let me know... regards, tom lane
Re: [HACKERS] Failure to recognise new database
> Is it just me? I'm pretty sure I saw something similar on a newly initialized database. The sequence was: initdb postmaster -i -o -F createdb psql (database "thomas" not found) psql template1 \d (see "thomas") psql (database "thomas" found just fine) - Thomas
[HACKERS] Failure to recognise new database
I did a CVS checkout today, and the following database creation fails. In psql:- You are now connected to database template1 as user postgres. template1=# select version(); version PostgreSQL 7.1devel on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66 (1 row) template1=# create database test; CREATE DATABASE template1=# \c test FATAL 1: Database "test" does not exist in the system catalog. Previous connection kept >> Now restart the postmaster template1=# \c test You are now connected to database test. Is it just me? Regards, Grant -- > Poorly planned software requires a genius to write it > and a hero to use it. Grant Finnemore BSc(Eng) (mailto:[EMAIL PROTECTED]) Software Engineer Universal Computer Services Tel (+27)(11)712-1366PO Box 31266 Braamfontein 2017, South Africa Cell (+27)(82)604-553620th Floor, 209 Smit St., Braamfontein Fax (+27)(11)339-3421Johannesburg, South Africa
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
On Thu, 16 Nov 2000, Alfred Perlstein wrote: > * Larry Rosenman <[EMAIL PROTECTED]> [001116 12:09] wrote: > > * Bruce Momjian <[EMAIL PROTECTED]> [001116 14:02]: > > > > > This sounds like an interesting approach, yes. > > > > Question: Is sleep(0) guaranteed to at least give up control? > > > > > > > > The way I read my UnixWare 7's man page, it might not, since alarm(0) > > > > just cancels the alarm... > > > > > > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel > > > call return. > > BUT, do we know for sure that sleep(0) is not optimized in the library > > to just return? > > sleep(3) should conform to POSIX specification, if anyone has the > reference they can check it to see what the effect of sleep(0) > should be. Yes, but Posix also specifies sched_yield() which rather explicitly allows a process to yield its timeslice. No idea how well that is supported. > -- > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > "I have the heart of a child; I keep it in a jar on my desk." Tom
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
Philip Warner <[EMAIL PROTECTED]> writes: > So long as the version is always in the first bytes of the struct, we are > covered for compatibility. Right ... > I'd still argue for a PG_FUNCTION_API_V2 macro for the reasons above. What > the fmgrs needs to do is: > - call pg_fmgr_api_version() to get the protocol version > - when it wants to call a function 'foo' see if there is a 'pg_api_foo' > entry point, and if so, use the new interface, o/wise use the old one. No > need to even call it. This strikes me as completely backwards, because it prejudges an assumption that protocol decisions can be made on a library-wide basis. I see no need for a library-wide protocol definition. What I want to do is call 'pg_api_foo' (if it exists) to find out all about the function 'foo', without any restriction on whether 'foo' is like 'bar' that happens to have been linked into the same shlib. The test to see if 'pg_api_foo' exists is going to be the expensive part of this anyway. Once you've done that, you may as well call it... > My only real issue with all of this is that we need to separate the > protocol selection from the the data exchange. Negotiating a protocol to negotiate protocol strikes me as considerable overkill. It should be plenty sufficient to say that a parameterless function with a determinable name will hand back a struct whose first word identifies the contents of the struct. Why do we need another layer on top of that? Especially if it's a layer that makes the unsupported assumption that all functions in a given shlib are similar? That way reduces flexibility, rather than increasing it. regards, tom lane
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
At 22:10 16/11/00 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> For possible future compatibility, can you also do something like:
>> PG_FUNCTION_API_V2;
>> PG_FUNCTION_V2(foo);
>> PG_FUNCTION_V2(bar);
>> ...
>
>> Where
>> PG_FUNCTION_API_V2 expands to:
>> int pg_fmgr_api_version(void) { return 2; }
>> And PG_FUNCTION_V2(foo) either does nothing or expands to:
>> int pg_fmgr_api2_version_foo(void) { return 2; }
>
>I'm not following the point here. Why two different macros? It doesn't
>look to me like the first one does anything. The per-routine macro
>calls should be capable of doing everything that needs to be done.
I think the PG_FUNCTION_API_V2 macros is very important because it will
tell the function manager which 'protocol' to use.
In my view, the individual stub entry points for each function are part of
the protocol and should not be assumed. Returning a struct would be ideal
since it allows more flexibility in the furture.
So long as the version is always in the first bytes of the struct, we are
covered for compatibility.
>> The first call will tell PG that (because it is version 2), it should
>> expect the next set of entry points. Since we will not be allowing mixed
>> versions in this version of the API (I think),
>
>Yes, we will, because there is a case in the regression tests that
>will break anything that doesn't cope with mixed versions ;-).
>I deliberately left some of the routines in regress.c old-style ...
I'd still argue for a PG_FUNCTION_API_V2 macro for the reasons above. What
the fmgrs needs to do is:
- call pg_fmgr_api_version() to get the protocol version
- when it wants to call a function 'foo' see if there is a 'pg_api_foo'
entry point, and if so, use the new interface, o/wise use the old one. No
need to even call it.
Future versions will call pg_fmgr_api_version() and possibly pass
appropriate structs to info-functions or whatever.
>
>Hmm. This stub idea might be a sufficient reason to say that we want to
>do a function call rather than look for a global variable.
I agree.
>I am unpersuaded by the idea that a one-liner function per useful entry
>point is an intolerable amount of overhead. Let's keep it simple here.
Wasn't worried about the overhead at all, just the offense to my aesthetics
8-).
>> PG_FUNCTION_V3(foo, false, true, foo_entry_point)
>> expand to:
>> void pg_fmgr_api_version_foo(fmgr_info *i)
>>{ i->iscacheable=false;
>i-> isstrict=true;
>i-> entrypoint=foo_entry_point; }
>
>I prefer something like
>
> const inforec * pg_api_foo(void)
> {
> static inforec foo_info = { ... };
> return &foo_info;
> }
>
>since this avoids prejudging anything. (In your example, how does
>the version function *know* how big the record it's been handed is?
Becuase the function manager called pg_fmgr_api_version and made sure it
passed the right structure.
>Loading a version-N library into a Postgres version < N might bomb
>hard because the info function scribbles on fields that aren't there.
If it calls pg_fmgr_api_version and can't get an acceptable version, it
would bomb nicely. Maybe in future versions we could even support some kind
of protocol negotiation, but that seems less than useful at this stage.
>Handing back a pointer to something that the main code then treats
>as read-only seems much safer.)
This is fine too; but in all cases they have to be sure that they agree on
what is being handed back. So long at the blocks always have the version
number on the header it is fine.
>> Perhaps in PG_FUNCTION_API_V4 we can implement some kind of interface for
>> listing supported entry points for module loading...
>
>I think that should be seen as a separate feature, rather than
>mixing it up with support information about any individual function.
Fine.
My only real issue with all of this is that we need to separate the
protocol selection from the the data exchange.
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] [rfc] new CREATE FUNCTION (and more)
Philip Warner <[EMAIL PROTECTED]> writes:
> For possible future compatibility, can you also do something like:
> PG_FUNCTION_API_V2;
> PG_FUNCTION_V2(foo);
> PG_FUNCTION_V2(bar);
> ...
> Where
> PG_FUNCTION_API_V2 expands to:
> int pg_fmgr_api_version(void) { return 2; }
> And PG_FUNCTION_V2(foo) either does nothing or expands to:
> int pg_fmgr_api2_version_foo(void) { return 2; }
I'm not following the point here. Why two different macros? It doesn't
look to me like the first one does anything. The per-routine macro
calls should be capable of doing everything that needs to be done.
Per your comments and Marko's about future extension, it seems that
a single-word result might start to get a little cramped before long.
I like Marko's design:
struct pg_function_info_header {
int api_ver;
};
The api_ver field is sufficient for now, but for values > 2 there
might be additional fields defined.
We can either have this struct be an initialized global variable,
or have a called function that returns a pointer to it, depending on
the question of which way seems easier to implement/more portable.
The macro can hide the details of how it's done.
> The first call will tell PG that (because it is version 2), it should
> expect the next set of entry points. Since we will not be allowing mixed
> versions in this version of the API (I think),
Yes, we will, because there is a case in the regression tests that
will break anything that doesn't cope with mixed versions ;-).
I deliberately left some of the routines in regress.c old-style ...
> This way we make it more independant of future API versions by not
> requiring a specific special entry point for each function. Then can do
> things like use the same entry point for multiple functions, possibly act
> as stubs pointing to other libraries (by loading & returning another
> library entry point) etc etc.
Hmm. This stub idea might be a sufficient reason to say that we want to
do a function call rather than look for a global variable. However,
I am unpersuaded by the idea that a one-liner function per useful entry
point is an intolerable amount of overhead. Let's keep it simple here.
> PG_FUNCTION_V3(foo, false, true, foo_entry_point)
> expand to:
> void pg_fmgr_api_version_foo(fmgr_info *i)
>{ i->iscacheable=false;
i-> isstrict=true;
i-> entrypoint=foo_entry_point; }
I prefer something like
const inforec * pg_api_foo(void)
{
static inforec foo_info = { ... };
return &foo_info;
}
since this avoids prejudging anything. (In your example, how does
the version function *know* how big the record it's been handed is?
Loading a version-N library into a Postgres version < N might bomb
hard because the info function scribbles on fields that aren't there.
Handing back a pointer to something that the main code then treats
as read-only seems much safer.) The above implementation with a
preset static inforec is of course only one way it could be done
without breaking the ABI for the info function...
> Perhaps in PG_FUNCTION_API_V4 we can implement some kind of interface for
> listing supported entry points for module loading...
I think that should be seen as a separate feature, rather than
mixing it up with support information about any individual function.
regards, tom lane
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
At 21:08 16/11/00 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>>> I'd be inclined to define a macro that creates the signal object,
>>> so that you'd write something like
>>>
>>> PG_FUNCTION_API_V2(foo);
...
>
>What I was thinking was that the macro would expand either to
>
> int pg_api_foo = 2;
>
>or
>
> int pg_api_foo(void) { return 2; }
>
For possible future compatibility, can you also do something like:
PG_FUNCTION_API_V2;
PG_FUNCTION_V2(foo);
PG_FUNCTION_V2(bar);
...
Where
PG_FUNCTION_API_V2 expands to:
int pg_fmgr_api_version(void) { return 2; }
And PG_FUNCTION_V2(foo) either does nothing or expands to:
int pg_fmgr_api2_version_foo(void) { return 2; }
The first call will tell PG that (because it is version 2), it should
expect the next set of entry points. Since we will not be allowing mixed
versions in this version of the API (I think), we could really have the
subsequent macros do nothing.
This way we make it more independant of future API versions by not
requiring a specific special entry point for each function. Then can do
things like use the same entry point for multiple functions, possibly act
as stubs pointing to other libraries (by loading & returning another
library entry point) etc etc.
>I like this way better than a central info function for the whole
>library, because you'd write the version declaration right with the
>function itself. A central info function would be more of a pain to
>maintain, I think.
In the plans for PG_FUNCTION_API_V3(?), I actually have the info function
returning a struct with values for 'iscacheable', 'isstrict', and the
actual entry point to use. This reduces duplication since the programmer is
the best person to know these attributes. But using macros is fine:
PG_FUNCTION_API_V3 expand to:
typedef struct {bool iscacheable, bool isstrict, ptr entrypoint }
pg_fmgr_info;
int pg_fmgr_api_version(void) { return 3; }
and
PG_FUNCTION_V3(foo, false, true, foo_entry_point)
expand to:
void pg_fmgr_api_version_foo(fmgr_info *i)
{ i->iscacheable=false;
i->isstrict=true;
i->entrypoint=foo_entry_point; }
will work as well.
Perhaps in PG_FUNCTION_API_V4 we can implement some kind of interface for
listing supported entry points for module loading...
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] Re: [PATCHES] A Patch for MIC to EUC_TW codeconverting in mbsupport
> Can someone tell me where we are on this? Tatsuo, I think you said you > wanted to apply this fix. I wanted to apply the fix after Chih-Chang Hsieh tested it out. But he said he couldn't becuase no test data was available for it. However I and he now are in the same opinion that the fix seems correct, and I am going to apply the fix, probably by tomorrow. > > [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
[HACKERS] Re: [PATCHES] A Patch for MIC to EUC_TW code converting inmbsupport
> > 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.
>
> You are right! When I do \encoding BIG5, it works.
> But it seems that "\encoding" can only be issued in
> psql's command prompt or be done with
> PQsetClientEncoding() in libpq.
Yes.
> If our application for input is written in PHP (4.0.2)
> How do we notify PostgreSQL that the frontend encoding
> is 'BIG5' ? (pg_exec("\encoding BIG5") failed.)
I know there are some patches for supporting \encoding in PHP. Do you
want to get them?
> PostgreSQL 7.1 will support automatic code conversion for
> BIG5 to utf-8. Does it means that we do not have to
> announce client encoding as long as the backend is utf-8?
No. You still need to declare that frontend side encoding is BIG5.
> I have also tried to set the environment variable
> PGCLIENTENCODING to 'BIG5'. But when I execute
> psql and then issue \encoding, it shows 'SQL_ASCII' in 7.0.2.
> Is this environment variable useless in 7.0.x and latter?
After checking the souce, I found the capability to recognize the
PGCLIENTENCODING environment variable has been broken since 7.0.
Attached is the patches for 7.0.3. I am going to fix current as well.
*** postgresql-7.0.3/src/interfaces/libpq/fe-connect.c~ Mon May 22 06:19:53 2000
--- postgresql-7.0.3/src/interfaces/libpq/fe-connect.c Fri Nov 17 10:37:23 2000
***
*** 1505,1514
{
const char *env;
- /* query server encoding */
env = getenv(envname);
if (!env || *env == '\0')
{
if (!PQsendQuery(conn,
"select
getdatabaseencoding()"))
goto error_return;
--- 1505,1515
{
const char *env;
env = getenv(envname);
if (!env || *env == '\0')
{
+ /* query server encoding if PGCLIENTENCODING
+ is not specified */
if (!PQsendQuery(conn,
"select
getdatabaseencoding()"))
goto error_return;
***
*** 1516,1521
--- 1517,1535
conn->setenv_state =
SETENV_STATE_ENCODINGS_WAIT;
return PGRES_POLLING_READING;
}
+ else
+ {
+ /* otherwise set client encoding in pg_conn
+struct */
+ int encoding = pg_char_to_encoding(env);
+ if (encoding < 0)
+ {
+ strcpy(conn->errorMessage.data,
+ "PGCLIENTENCODING has no
+valid encoding name.\n");
+ goto error_return;
+ }
+ conn->client_encoding = encoding;
+ }
+
}
case SETENV_STATE_ENCODINGS_WAIT:
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
Philip Warner <[EMAIL PROTECTED]> writes:
>> I'd be inclined to define a macro that creates the signal object,
>> so that you'd write something like
>>
>> PG_FUNCTION_API_V2(foo);
> This sounds perfect. Would you generate an 'info' function to return a list
> of entry points, or just use dummy object names? The info function has the
> advantage that it can return version information as well, and a clutter of
> dummy entry points might look a little messy.
What I was thinking was that the macro would expand either to
int pg_api_foo = 2;
or
int pg_api_foo(void) { return 2; }
The former would be more compact, presumably, but the latter would
probably be more portable --- we already have to have the ability to
find and call functions in a dynamic-link library, whereas I'm not so
sure about the ability to find and read values of global variables.
In either case, the system would be able to extract an integer version
value associated with each function defined by the library. (If we
don't find the version-defining symbol, we assume old-style C API.)
Meaning of values other than "2" reserved for future definition.
I like this way better than a central info function for the whole
library, because you'd write the version declaration right with the
function itself. A central info function would be more of a pain to
maintain, I think.
regards, tom lane
Re: [HACKERS] coding style guidelines?
> Larry Rosenman <[EMAIL PROTECTED]> writes: > > Is there any guidelines on the formatting of the C code in > > PG? As I was working on guc-file.l yesterday, I noticed > > some things with LONG lines (I broke some of them up). > > I was wondering if there were formal standards? > > Brace layout, comment layout and indentation are all brought into line > by pg_indent, which Bruce runs at least once per release cycle. > However, I don't think pg_indent will consider breaking non-comment lines > into multiple lines, so it's up to the code author to be reasonable in > that area. It does wrap >80 lines. > > My own practice is to try to make the code look nice in an 80-column > window. > > BTW, if you are writing a comment that you don't want to have > reformatted by pg_indent's rather braindead reformatter, protect it > with some dashes: > > /*-- >* This text will not get reformatted. >*-- >*/ > > > > Also, do we care about extraneous #include's? > > Not very much. You have to be particularly cautious about removing > system-header #includes, since what looks redundant on your platform > may not be redundant for other platforms. I think Bruce has a tool > to look for unnecessary includes of our own header files, but it > doesn't risk trying to remove system headers. Yes, it does not touch system includes. -- 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] [rfc] new CREATE FUNCTION (and more)
On Thu, Nov 16, 2000 at 08:06:30PM -0500, Tom Lane wrote:
> Nathan Myers <[EMAIL PROTECTED]> writes:
> > - Keep the name 'C' for both old-style and new-style module declarations.
> > - Require that new-style modules define a distinguished symbol, such as
> >"int __postgresql_call_7_1;".
>
> I was thinking along the same lines myself. I'd want to do it on a
> per-function basis, though, rather than assuming that all functions in
> a module must use the same interface.
>
> I'd be inclined to define a macro that creates the signal object,
> so that you'd write something like
>
> PG_FUNCTION_API_V2(foo);
>
> Datum
> foo(PG_FUNCTION_ARGS)
> {
> ...
> }
>
> to create a dynamically loadable new-style function.
>
> Comments?
I like it :)
e.g.
struct pg_function_info_header {
int api_ver;
};
and
PG_FUNCTION_TAG(foo);
expands to
struct pg_function_info_header __pg_function_foo_info = { 0 };
so when we sometimes get around to add more fields to it
we increase the api_ver. For more info also the macros will
be different. This _TAG means "no info is given it is only
tagged as newC".
Comments?
--
marko
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
At 20:06 16/11/00 -0500, Tom Lane wrote: >Nathan Myers <[EMAIL PROTECTED]> writes: >> - Keep the name 'C' for both old-style and new-style module declarations. >> - Require that new-style modules define a distinguished symbol, such as >>"int __postgresql_call_7_1;". > >I was thinking along the same lines myself. I'd want to do it on a >per-function basis, though, rather than assuming that all functions in >a module must use the same interface. > >I'd be inclined to define a macro that creates the signal object, >so that you'd write something like > >PG_FUNCTION_API_V2(foo); This sounds perfect. Would you generate an 'info' function to return a list of entry points, or just use dummy object names? The info function has the advantage that it can return version information as well, and a clutter of dummy entry points might look a little messy. I had been thinking along the lines of a generic extensible interface using a known function, but by using macros you can even hide that layer, making whatever we do now completely compatible. What's also cute, is if the underlying method is designed carefully you may be able to get one library working with multiple interfaces, especially if the stuff that comes with PG_FUNCTION_ARGS can also provide version information. 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] [rfc] new CREATE FUNCTION (and more)
At 12:59 16/11/00 -0800, Nathan Myers wrote: > > - Keep the name 'C' for both old-style and new-style module declarations. > - Require that new-style modules define a distinguished symbol, such as > "int __postgresql_call_7_1;". > >The module loader can look for symbols that start with "__postgresql_call" >and adjust automatically, or report an error. This Cute idea. *If* people like the idea of an info function of some kind then all we have to do is agree on it's name (not even the parameters, I think), then we can get the 7.1 function manager to look for it. This is definitely the simplest implementation of a brain-dead info function! 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] [rfc] new CREATE FUNCTION (and more)
Nathan Myers <[EMAIL PROTECTED]> writes:
> - Keep the name 'C' for both old-style and new-style module declarations.
> - Require that new-style modules define a distinguished symbol, such as
>"int __postgresql_call_7_1;".
I was thinking along the same lines myself. I'd want to do it on a
per-function basis, though, rather than assuming that all functions in
a module must use the same interface.
I'd be inclined to define a macro that creates the signal object,
so that you'd write something like
PG_FUNCTION_API_V2(foo);
Datum
foo(PG_FUNCTION_ARGS)
{
...
}
to create a dynamically loadable new-style function.
Comments?
regards, tom lane
Re: [HACKERS] Varchar standard compliance
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is > incorrectly interpreted as VARCHAR(). Any reason for that, > besides the fact that it of course makes much more sense than VARCHAR(1)? On what grounds do you claim that behavior is incorrect? regards, tom lane
Re: [HACKERS] coding style guidelines?
Larry Rosenman <[EMAIL PROTECTED]> writes: > Is there any guidelines on the formatting of the C code in > PG? As I was working on guc-file.l yesterday, I noticed > some things with LONG lines (I broke some of them up). > I was wondering if there were formal standards? Brace layout, comment layout and indentation are all brought into line by pg_indent, which Bruce runs at least once per release cycle. However, I don't think pg_indent will consider breaking non-comment lines into multiple lines, so it's up to the code author to be reasonable in that area. My own practice is to try to make the code look nice in an 80-column window. BTW, if you are writing a comment that you don't want to have reformatted by pg_indent's rather braindead reformatter, protect it with some dashes: /*-- * This text will not get reformatted. *-- */ > Also, do we care about extraneous #include's? Not very much. You have to be particularly cautious about removing system-header #includes, since what looks redundant on your platform may not be redundant for other platforms. I think Bruce has a tool to look for unnecessary includes of our own header files, but it doesn't risk trying to remove system headers. regards, tom lane
[HACKERS] SearchSysCache changes committed
I have committed changes to keep reference counts for system cache entries.
This should eliminate the issues we've had with cache entries sometimes
getting dropped while still in use. Some notes:
1. The routine formerly called SearchSysCacheTuple is now SearchSysCache().
It increments the reference count on the returned cache entry. You must
drop the reference count when done using the cache entry, so the typical
call scenario is now something like
tuple = SearchSysCache(...);
if (HeapTupleIsValid(tuple))
{
... use tuple ...
ReleaseSysCache(tuple);
}
2. If a cache inval message arrives for a cache entry with refcount > 0,
the cache entry will not be dropped until the refcount goes to zero.
However, it will immediately be marked "dead" and so will not be found
by subsequent cache searches.
3. It turned out not to be hard to make the parser drop reference counts
when done with cache entries, so I went over to a hard-and-fast rule
that everyone must drop acquired refcounts. If you don't, you'll get
an annoying NOTICE at commit time, just like for buffer refcount leaks.
4. There are several convenience routines for common usage patterns:
* SearchSysCacheCopy() --- formerly SearchSysCacheTupleCopy() --- still
exists, although the need for it is less than before. You do NOT need
this routine just to hang onto a reference to a cache entry for awhile.
You use it if you want to update the tuple and need a modifiable copy
to scribble on. When you use this routine, you get back a palloc'd
tuple (free it with heap_freetuple), and the original cache entry does
not have its refcount bumped.
* SearchSysCacheExists() just probes for the existence of a tuple via
the cache; it returns true or false without bumping the refcount.
* GetSysCacheOid() returns the cache entry's OID, or InvalidOid if no
entry found, leaving the refcount un-bumped.
* There are some other new convenience routines too in parse_oper.c,
parse_type.c, and lsyscache.c, to reduce the number of places that
have to bother with the full SearchSysCache/ReleaseSysCache protocol.
regards, tom lane
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> A long ago you, Bruce, made me gift - book about transaction processing
> (thanks again -:)). This sleeping before fsync in commit is described
> there as standard technique. And the reason is cleanest.
> Men, cost of fsync is very high! { write (64 bytes) + fsync() }
> takes ~ 1/50 sec. Yes, additional 1/200 sec or so results in worse
> performance when there is only one backend running but greatly
> increase overall performance for 100 simultaneous backends. Ie this
> delay is trade off to gain better scalability.
> I agreed that it must be configurable, smaller or probably 0 by
> default, use approximate # of simultaneously running backends for
> guessing (postmaster could maintain this number in shmem and
> backends could just read it without any locking - exact number is
> not required), good described as tuning patameter in documentation.
> Anyway I object sleep(0).
Good points. Another idea that Bruce and I kicked around on the phone
was to make the pre-fsync delay be self-adjusting; that is, it'd
automatically move up and down based on system load. For example,
you could keep track of the time since the last xact commit, and guess
that the time to the next one will be similar. If that's greater than
your intended sleep delay, forget the sleep and just fsync. But the
shorter the time since the last commit, the longer you should be willing
to delay. This'd need some experimentation to get right, but it seems a
lot better than asking the dbadmin to pick a value.
Another thing that should happen is that once someone fsyncs, all the
other backends waiting should be awoken immediately, instead of waiting
for their delays to time out. Not sure how doable this is --- there's
no wait-for-semaphore-with-timeout in SysV IPC, is there? Perhaps we
can distinguish the first waiter (the guy who will ultimately do the
fsync, he's just hoping for some passengers) from the rest, who see
that someone's already waiting for fsync and just wait for him to do it.
Those other guys don't do a time wait, they sleep on a semaphore that
the first waiter will release once he's done the fsync.
regards, tom lane
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Alfred Perlstein <[EMAIL PROTECTED]> writes: >> That's the hard way to do it. We just need to keep track of the >> endpoint of the log as of the last fsync. > Well that breaks when you move to a overwriting storage manager, No, because the log is just a series of records written sequentially --- it has nothing to do with storage management in data files. regards, tom lane
RE: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> > > > No. Checkpoints are to speedup after crash recovery and > > > > to remove/archive log files. With WAL server doesn't write > > > > any datafiles on commit, only commit record goes to log > > > > (and log fsync-ed). Dirty buffers remains in memory long > > Ok, so with CHECKPOINTS, we could move the offline log files to > somewhere else so that we could archive them, in my > undertstanding. Now question is, how we could recover from disaster > like losing every table files except log files. Can we do this with > WAL? If so, how can we do it? Not currently. WAL based BAR is required. I think there will be no BAR in 7.1, but it may be added in 7.1.X (no initdb will be required). Anyway BAR implementation is not in my plans. All in your hands, guys -:) Vadim
RE: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> > You are going to kernel call/yield anyway to fsync, so why > > not try and if someone does the fsync, we don't need to do it. > > I am suggesting re-checking the need for fsync after the return > > from sleep(0). > > It might make more sense to keep a private copy of the last time > the file was modified per-backend by that particular backend and > a timestamp of the last fsync shared globally so one can forgo the > fsync if "it hasn't been dirtied by me since the last fsync" > > This would provide a rendevous point for the fsync call although > cost more as one would need to periodically call gettimeofday to > set the modified by me timestamp as well as the post-fsync shared > timestamp. Already made, but without timestamps. WAL maintains last byte of log written/fsynced in shmem, so XLogFlush(_last_byte_to_be_flushed_) will do nothing if data are already on disk. Vadim
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
* Bruce Momjian <[EMAIL PROTECTED]> [001116 12:31] wrote: > > > In OS kernel design, you try to avoid process herding bottlenecks. > > > Here, we want them herded, and giving up the CPU may be the best way to > > > do it. > > > > Yes, but if everyone yeilds you're back where you started, and with > > 128 or more backends do you really want to cause possibly that many > > context switches per fsync? > > You are going to kernel call/yield anyway to fsync, so why not try and > if someone does the fsync, we don't need to do it. I am suggesting > re-checking the need for fsync after the return from sleep(0). It might make more sense to keep a private copy of the last time the file was modified per-backend by that particular backend and a timestamp of the last fsync shared globally so one can forgo the fsync if "it hasn't been dirtied by me since the last fsync" This would provide a rendevous point for the fsync call although cost more as one would need to periodically call gettimeofday to set the modified by me timestamp as well as the post-fsync shared timestamp. -- -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: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
* Tom Lane <[EMAIL PROTECTED]> [001116 13:31] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > It might make more sense to keep a private copy of the last time > > the file was modified per-backend by that particular backend and > > a timestamp of the last fsync shared globally so one can forgo the > > fsync if "it hasn't been dirtied by me since the last fsync" > > This would provide a rendevous point for the fsync call although > > cost more as one would need to periodically call gettimeofday to > > set the modified by me timestamp as well as the post-fsync shared > > timestamp. > > That's the hard way to do it. We just need to keep track of the > endpoint of the log as of the last fsync. You need to fsync (after > returning from sleep()) iff your commit record position > fsync > endpoint. No need to ask the kernel for time-of-day. Well that breaks when you move to a overwriting storage manager, however if you use oid instead that optimization would survive the change to a overwriting storage manager. ? -Alfred
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Alfred Perlstein <[EMAIL PROTECTED]> writes: > It might make more sense to keep a private copy of the last time > the file was modified per-backend by that particular backend and > a timestamp of the last fsync shared globally so one can forgo the > fsync if "it hasn't been dirtied by me since the last fsync" > This would provide a rendevous point for the fsync call although > cost more as one would need to periodically call gettimeofday to > set the modified by me timestamp as well as the post-fsync shared > timestamp. That's the hard way to do it. We just need to keep track of the endpoint of the log as of the last fsync. You need to fsync (after returning from sleep()) iff your commit record position > fsync endpoint. No need to ask the kernel for time-of-day. regards, tom lane
RE: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> > BUT, do we know for sure that sleep(0) is not optimized in
> > the library to just return?
>
> We can only do our best here. I think guessing whether other backends
> are _about_ to commit is pretty shaky, and sleeping every time is a
> waste. This seems the cleanest.
A long ago you, Bruce, made me gift - book about transaction processing
(thanks again -:)). This sleeping before fsync in commit is described
there as standard technique. And the reason is cleanest.
Men, cost of fsync is very high! { write (64 bytes) + fsync() }
takes ~ 1/50 sec. Yes, additional 1/200 sec or so results in worse
performance when there is only one backend running but greatly
increase overall performance for 100 simultaneous backends. Ie this
delay is trade off to gain better scalability.
I agreed that it must be configurable, smaller or probably 0 by
default, use approximate # of simultaneously running backends for
guessing (postmaster could maintain this number in shmem and
backends could just read it without any locking - exact number is
not required), good described as tuning patameter in documentation.
Anyway I object sleep(0).
Vadim
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
On Thu, Nov 16, 2000 at 11:20:58AM -0500, Tom Lane wrote: > I don't have any great love for the names 'C' and 'newC' either, but > unless we are willing to break backward-compatibility of function > declarations in 7.1, I think we are stuck with those names or ones > isomorphic to them. > > In the long run, it seems that it'd be a good idea to embed function > declaration info straight into a loadable module, per Philip's idea > of a special function or your idea of a table. Until somebody implements Philip's idea, a much simpler approach could obviate the whole issue: - Keep the name 'C' for both old-style and new-style module declarations. - Require that new-style modules define a distinguished symbol, such as "int __postgresql_call_7_1;". The module loader can look for symbols that start with "__postgresql_call" and adjust automatically, or report an error. This - Breaks no backward compatibility, - Defines a clear method for handling future changes, to prevent this problem from arising again, - Creates no particular inconvenience for writers of modules, and - Might be very easy to implement. Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Bruce Momjian writes: > > The way I read my UnixWare 7's man page, it might not, since alarm(0) > > just cancels the alarm... > > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel > call return. In glibc, sleep(0) just does "return 0;", so if the compiler has a good day the call will disappear completely. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.cxlog.c)
> * Bruce Momjian <[EMAIL PROTECTED]> [001116 14:02]:
> > > > This sounds like an interesting approach, yes.
> > > Question: Is sleep(0) guaranteed to at least give up control?
> > >
> > > The way I read my UnixWare 7's man page, it might not, since alarm(0)
> > > just cancels the alarm...
> >
> > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel
> > call return.
> BUT, do we know for sure that sleep(0) is not optimized in the library
> to just return?
We can only do our best here. I think guessing whether other backends
are _about_ to commit is pretty shaky, and sleeping every time is a
waste. This seems the cleanest.
Funny you should mention the optimization. I just checked BSDI and saw:
u_int
sleep(secs)
u_int secs;
{
struct timeval nt, ot;
long diff;
int rc;
if (secs == 0)
return (0);
So maybe we need another _fake_ kernel call, or a select/usleep with a
very small value.
--
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.c xlog.c)
* Larry Rosenman <[EMAIL PROTECTED]> [001116 12:09] wrote: > * Bruce Momjian <[EMAIL PROTECTED]> [001116 14:02]: > > > > This sounds like an interesting approach, yes. > > > Question: Is sleep(0) guaranteed to at least give up control? > > > > > > The way I read my UnixWare 7's man page, it might not, since alarm(0) > > > just cancels the alarm... > > > > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel > > call return. > BUT, do we know for sure that sleep(0) is not optimized in the library > to just return? sleep(3) should conform to POSIX specification, if anyone has the reference they can check it to see what the effect of sleep(0) should be. -- -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: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.c)
> > In OS kernel design, you try to avoid process herding bottlenecks. > > Here, we want them herded, and giving up the CPU may be the best way to > > do it. > > Yes, but if everyone yeilds you're back where you started, and with > 128 or more backends do you really want to cause possibly that many > context switches per fsync? You are going to kernel call/yield anyway to fsync, so why not try and if someone does the fsync, we don't need to do it. I am suggesting re-checking the need for fsync after the return from sleep(0). -- 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)
> * Don Baccus <[EMAIL PROTECTED]> [001116 13:46]: > > At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote: > > > > >> I think the default should probably be no delay, and the documentation > > >> on enabling this needs to be clear and obvious (i.e. hard to miss). > > > > > >I just talked to Tom Lane about this. I think a sleep(0) just before > > >the flush would be the best. It would reliquish the cpu slice if > > >another process is ready to run. If no other backend is running, it > > >probably just returns. If there is another one, it gives it a chance to > > >complete. On return from sleep(0), it can check if it still needs to > > >flush. This would tend to bunch up flushers so they flush only once, > > >while not delaying cases where only one backend is running. > > > > This sounds like an interesting approach, yes. > Question: Is sleep(0) guaranteed to at least give up control? > > The way I read my UnixWare 7's man page, it might not, since alarm(0) > just cancels the alarm... Well, it certainly is a kernel call, and most OS's re-evaluate on kernel call return. -- 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.c xlog.c)
* Bruce Momjian <[EMAIL PROTECTED]> [001116 11:59] wrote: > > At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote: > > > > >> I think the default should probably be no delay, and the documentation > > >> on enabling this needs to be clear and obvious (i.e. hard to miss). > > > > > >I just talked to Tom Lane about this. I think a sleep(0) just before > > >the flush would be the best. It would reliquish the cpu slice if > > >another process is ready to run. If no other backend is running, it > > >probably just returns. If there is another one, it gives it a chance to > > >complete. On return from sleep(0), it can check if it still needs to > > >flush. This would tend to bunch up flushers so they flush only once, > > >while not delaying cases where only one backend is running. > > > > This sounds like an interesting approach, yes. > > In OS kernel design, you try to avoid process herding bottlenecks. > Here, we want them herded, and giving up the CPU may be the best way to > do it. Yes, but if everyone yeilds you're back where you started, and with 128 or more backends do you really want to cause possibly that many context switches per fsync? -- -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: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
* Bruce Momjian <[EMAIL PROTECTED]> [001116 14:02]: > > > This sounds like an interesting approach, yes. > > Question: Is sleep(0) guaranteed to at least give up control? > > > > The way I read my UnixWare 7's man page, it might not, since alarm(0) > > just cancels the alarm... > > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel > call return. BUT, do we know for sure that sleep(0) is not optimized in the library to just return? -- 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
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
> At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote: > > >> I think the default should probably be no delay, and the documentation > >> on enabling this needs to be clear and obvious (i.e. hard to miss). > > > >I just talked to Tom Lane about this. I think a sleep(0) just before > >the flush would be the best. It would reliquish the cpu slice if > >another process is ready to run. If no other backend is running, it > >probably just returns. If there is another one, it gives it a chance to > >complete. On return from sleep(0), it can check if it still needs to > >flush. This would tend to bunch up flushers so they flush only once, > >while not delaying cases where only one backend is running. > > This sounds like an interesting approach, yes. In OS kernel design, you try to avoid process herding bottlenecks. Here, we want them herded, and giving up the CPU may be the best way to do 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] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
* Don Baccus <[EMAIL PROTECTED]> [001116 13:46]: > At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote: > > >> I think the default should probably be no delay, and the documentation > >> on enabling this needs to be clear and obvious (i.e. hard to miss). > > > >I just talked to Tom Lane about this. I think a sleep(0) just before > >the flush would be the best. It would reliquish the cpu slice if > >another process is ready to run. If no other backend is running, it > >probably just returns. If there is another one, it gives it a chance to > >complete. On return from sleep(0), it can check if it still needs to > >flush. This would tend to bunch up flushers so they flush only once, > >while not delaying cases where only one backend is running. > > This sounds like an interesting approach, yes. Question: Is sleep(0) guaranteed to at least give up control? The way I read my UnixWare 7's man page, it might not, since alarm(0) just cancels the alarm... Larry > > > > - 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. -- 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
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote: >> I think the default should probably be no delay, and the documentation >> on enabling this needs to be clear and obvious (i.e. hard to miss). > >I just talked to Tom Lane about this. I think a sleep(0) just before >the flush would be the best. It would reliquish the cpu slice if >another process is ready to run. If no other backend is running, it >probably just returns. If there is another one, it gives it a chance to >complete. On return from sleep(0), it can check if it still needs to >flush. This would tend to bunch up flushers so they flush only once, >while not delaying cases where only one backend is running. This sounds like an interesting approach, yes. - 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)
> At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote: > >* Bruce Momjian <[EMAIL PROTECTED]> [001116 08:59] wrote: > > >> Ewe, so we have this 1/200 second delay for every transaction. Seems > >> bad to me. > > > >I think as long as it becomes a tunable this isn't a bad idea at > >all. Fixing it at 1/200 isn't so great because people not wrapping > >large amounts of inserts/updates with transaction blocks will > >suffer. > > I think the default should probably be no delay, and the documentation > on enabling this needs to be clear and obvious (i.e. hard to miss). I just talked to Tom Lane about this. I think a sleep(0) just before the flush would be the best. It would reliquish the cpu slice if another process is ready to run. If no other backend is running, it probably just returns. If there is another one, it gives it a chance to complete. On return from sleep(0), it can check if it still needs to flush. This would tend to bunch up flushers so they flush only once, while not delaying cases where only one backend is running. -- 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
[HACKERS] Questions on RI spec (poss. bugs)
There's a message on -general about a possible problem in the deferred RI constraints. He was doing a sequence like: begin delete insert end and having it fail even though the deleted key was back in place at the end. My understanding of the spec is that that sequence should have succeeded, but I could very well be wrong. Changing the noaction check to fix this is probably fairly minimal (making sure that there isn't now a key with the old value before checking for violated rows would probably be sufficient for match full and unspecified). And I guess technically this could happen for immediate constraints as well if a single update changed a key to a new value and another to the old one so the constraint was still satisifed. But, this brings up a question for the referential actions. It doesn't look like the actions are limited to whether or not the row would be violating, but instead based on what row it was associated with before. (Makes sense, you'd want a cascade update to keep the same associations). But that made me wonder about exactly *when* the actions were supposed to take place for deferred constraints. You could say at check time, but that doesn't make sense for RESTRICT really, and restrict doesn't have any special wording I see in its definition. So if you had a deferred on delete cascade constraint, and you do begin; delete from pk; select * from fk; end; do you see the fk rows that were associated with the deleted pk rows?
Re: [HACKERS] Varchar standard compliance
I've been wondering the difference in varchar and TEXT in the aspect of length and indexing - what would happen if you tried to index a varchar(BLCKSZ) ? I know you can index smaller portions of text (at least it appears you can) so why not larger alphanumeric data? (I'm not complaining, just trying to understand.) I just made a varchar(3) field, inserted some data into it and created an index on it, it seemed to work OK -- is it really only indexing X characters or something? -Mitch - Original Message - From: "Peter Eisentraut" <[EMAIL PROTECTED]> To: "PostgreSQL Development" <[EMAIL PROTECTED]> Sent: Thursday, November 16, 2000 10:16 AM Subject: [HACKERS] Varchar standard compliance > Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is > incorrectly interpreted as VARCHAR(). Any reason for that, > besides the fact that it of course makes much more sense than VARCHAR(1)? > > Additionally, neither CHAR nor VARCHAR seem to bark on too long input, > they just truncate silently. > > I'm wondering because should the bit types be made to imitate this > incorrect behaviour, or should they start out correctly? > > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > >
Re: AW: AW: AW: [HACKERS] Coping with 'C' vs 'newC' function language nam esh
Bruce Momjian writes: > OK, lets call the old style "stdC" and the new one "C". The old style has the be 'C' because otherwise you break every old script, including dumps for upgrades, and Lamar will *really* be on your case this time. ;-) Also, the grammar clause "LANGUAGE C" is actually part of the standard, so naming it "LANGUAGE stdC" will make it *less* standard. (Not that I buy Informix as being a "standard".) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Varchar standard compliance
Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is incorrectly interpreted as VARCHAR(). Any reason for that, besides the fact that it of course makes much more sense than VARCHAR(1)? Additionally, neither CHAR nor VARCHAR seem to bark on too long input, they just truncate silently. I'm wondering because should the bit types be made to imitate this incorrect behaviour, or should they start out correctly? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote: >* Bruce Momjian <[EMAIL PROTECTED]> [001116 08:59] wrote: >> Ewe, so we have this 1/200 second delay for every transaction. Seems >> bad to me. > >I think as long as it becomes a tunable this isn't a bad idea at >all. Fixing it at 1/200 isn't so great because people not wrapping >large amounts of inserts/updates with transaction blocks will >suffer. I think the default should probably be no delay, and the documentation on enabling this needs to be clear and obvious (i.e. hard to miss). - 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: AW: AW: AW: [HACKERS] Coping with 'C' vs 'newC' function language nam esh
[ Charset ISO-8859-1 unsupported, converting... ] > > > But we have very few Informix functions moving to PostgreSQL. > > I do not understand this comment. > What you imho forget here is that a definition for an interface will eventually be > included in the SQL standard. > And it will be what Oracle or DB/2 (maybe even Informix) does. OK, lets call the old style "stdC" and the new one "C". -- 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
AW: AW: AW: [HACKERS] Coping with 'C' vs 'newC' function language nam esh
> But we have very few Informix functions moving to PostgreSQL. I do not understand this comment. What you imho forget here is that a definition for an interface will eventually be included in the SQL standard. And it will be what Oracle or DB/2 (maybe even Informix) does. I conclude from previous mails, that none of us have the slightest idea how this works in DB/2 or Oracle. This is imho bad. > My concern is that this is confusing. All our documentation says the > style is called C. Functions are confusing enough. Adding a new name > for our default function type could add to the confusion. Yes, that is why imho some more research and adjustments are necessary before we make this the new default interface, and postpone public advertisement to 7.2. Andreas
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
* Bruce Momjian <[EMAIL PROTECTED]> [001116 08:59] wrote: > [ 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? > > > > No. > > Ewe, so we have this 1/200 second delay for every transaction. Seems > bad to me. I think as long as it becomes a tunable this isn't a bad idea at all. Fixing it at 1/200 isn't so great because people not wrapping large amounts of inserts/updates with transaction blocks will suffer. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: AW: AW: [HACKERS] Coping with 'C' vs 'newC' function language namesh
[ Charset ISO-8859-1 unsupported, converting... ] > > > > Actually my proposal would be to not advertise "newC" in 7.1 and do > > > some more research in that area until we have a solid and > > maybe compatible > > > interface that also makes the missing features possible > > > (multiple columns and rows for return, enter the function > > more than once > > > to retrieve only part of the result if it consists of many rows). > > > > My problem with newC is that I think it is going to cause confusing by > > people who create new-style functions and call the language "C". I > > recommend making our current code "C" style, and calling pre-7.1 > > functions "C70", that way, we can still enable old functions to work, > > they just have to use "C70" to make them work, and all our new code is > > the clean "C" type. > > This would be ok if the "newC" would be like any one other implementation, > but it is not. It is a PostgreSQL specific fmgr interface. > > Our old "C" fmgr interface is more or less exactly the same as in Informix > (no wonder, they copied Illustra). In Informix this fmgr interface is called "C", > that is why I would like to keep the "old" style "C" also. > It is something with a sort of pseudo standard character. But we have very few Informix functions moving to PostgreSQL. > > For the new interface, something that makes clear that it is PostgreSQL specific > would imho be good, like "pgC". > Or see my previous mail about "parameter style postgresql". My concern is that this is confusing. All our documentation says the style is called C. Functions are confusing enough. Adding a new name for our default function type could add to the confusion. -- 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
AW: AW: [HACKERS] Coping with 'C' vs 'newC' function language namesh
> > Actually my proposal would be to not advertise "newC" in 7.1 and do > > some more research in that area until we have a solid and > maybe compatible > > interface that also makes the missing features possible > > (multiple columns and rows for return, enter the function > more than once > > to retrieve only part of the result if it consists of many rows). > > My problem with newC is that I think it is going to cause confusing by > people who create new-style functions and call the language "C". I > recommend making our current code "C" style, and calling pre-7.1 > functions "C70", that way, we can still enable old functions to work, > they just have to use "C70" to make them work, and all our new code is > the clean "C" type. This would be ok if the "newC" would be like any one other implementation, but it is not. It is a PostgreSQL specific fmgr interface. Our old "C" fmgr interface is more or less exactly the same as in Informix (no wonder, they copied Illustra). In Informix this fmgr interface is called "C", that is why I would like to keep the "old" style "C" also. It is something with a sort of pseudo standard character. For the new interface, something that makes clear that it is PostgreSQL specific would imho be good, like "pgC". Or see my previous mail about "parameter style postgresql". Andreas
[HACKERS] coding style guidelines?
Is there any guidelines on the formatting of the C code in PG? As I was working on guc-file.l yesterday, I noticed some things with LONG lines (I broke some of them up). I was wondering if there were formal standards? Also, do we care about extraneous #include's? (src/backend/parser/scansup.c has #include which it doesn't need on closer inspection, for example). When I copied scansup.c into guc-file.l I added the #include , but it may not need it. Larry -- 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
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
On Thu, Nov 16, 2000 at 11:20:58AM -0500, Tom Lane wrote: > Marko Kreen <[EMAIL PROTECTED]> writes: > > This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'". > > Main difference is that the TYPE=0 means the old 'C' interface > > and TYPE=1 means 'newC' interface. Default is 1. > > This improves matters how, exactly? As far as I can see, this just > replaces a readable construct with magic numbers, for a net loss in > readability and no change in functionality. Hmm. I think I have to agree. The thing is I did all-powerful CREATE FUNCTION, then I noticed that the module-provided-info stuff is separate functionality and split them off into LOAD * functions. So I did not noticed that the remaining CREATE FUNCTION has not much point anymore... :) > I don't have any great love for the names 'C' and 'newC' either, but > unless we are willing to break backward-compatibility of function > declarations in 7.1, I think we are stuck with those names or ones > isomorphic to them. Ok. I only want to note that the "newC" interface is "good" in the sense that it probably stays around a long time. It would be nice if the name seems reasonable after a couple of years too. But I better shut up on this issue now. > In the long run, it seems that it'd be a good idea to embed function > declaration info straight into a loadable module, per Philip's idea > of a special function or your idea of a table. However that does not > change the issue of names for function-call conventions in the least, Yes. > it merely avoids the problem of keeping a script of SQL declarations > in sync with the library file. (One brain-dead-simple definition of > the info function or table is that it returns/contains a text string > that's exactly the SQL commands needed to create the function > definitions, except we could allow them to omit the pathname > of the library file. We can probably do better than that, but as > far as raw functionality goes, that will accomplish everything that > a fancier-looking API would do.) Embedded stuff makes the handling less error-prone and comfortable. Makefiles too dont bring any new functionality to the program being compiled... :) But I think that "LOAD MODULE" starts bringing new functionality but what exactly I do not know yet... -- marko
Re: [HACKERS] [rfc] new CREATE FUNCTION (and more)
> Marko Kreen <[EMAIL PROTECTED]> writes: > > This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'". > > Main difference is that the TYPE=0 means the old 'C' interface > > and TYPE=1 means 'newC' interface. Default is 1. > > This improves matters how, exactly? As far as I can see, this just > replaces a readable construct with magic numbers, for a net loss in > readability and no change in functionality. > > I don't have any great love for the names 'C' and 'newC' either, but > unless we are willing to break backward-compatibility of function > declarations in 7.1, I think we are stuck with those names or ones > isomorphic to them. I am recommending C70 for old functions, and C for current-style functions. That way, we can implement C71 if we want for backward compatibility. I think making everyone use newC for the current style is going to be confusing. -- 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: AW: [HACKERS] Coping with 'C' vs 'newC' function language namesh
> Actually my proposal would be to not advertise "newC" in 7.1 and do > some more research in that area until we have a solid and maybe compatible > interface that also makes the missing features possible > (multiple columns and rows for return, enter the function more than once > to retrieve only part of the result if it consists of many rows). My problem with newC is that I think it is going to cause confusing by people who create new-style functions and call the language "C". I recommend making our current code "C" style, and calling pre-7.1 functions "C70", that way, we can still enable old functions to work, they just have to use "C70" to make them work, and all our new code is the clean "C" type. Comments? -- 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? > > No. Ewe, so we have this 1/200 second delay for every transaction. Seems bad to me. -- 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] [rfc] new CREATE FUNCTION (and more)
Marko Kreen <[EMAIL PROTECTED]> writes: > This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'". > Main difference is that the TYPE=0 means the old 'C' interface > and TYPE=1 means 'newC' interface. Default is 1. This improves matters how, exactly? As far as I can see, this just replaces a readable construct with magic numbers, for a net loss in readability and no change in functionality. I don't have any great love for the names 'C' and 'newC' either, but unless we are willing to break backward-compatibility of function declarations in 7.1, I think we are stuck with those names or ones isomorphic to them. In the long run, it seems that it'd be a good idea to embed function declaration info straight into a loadable module, per Philip's idea of a special function or your idea of a table. However that does not change the issue of names for function-call conventions in the least, it merely avoids the problem of keeping a script of SQL declarations in sync with the library file. (One brain-dead-simple definition of the info function or table is that it returns/contains a text string that's exactly the SQL commands needed to create the function definitions, except we could allow them to omit the pathname of the library file. We can probably do better than that, but as far as raw functionality goes, that will accomplish everything that a fancier-looking API would do.) regards, tom lane
Re: [HACKERS] Coping with 'C' vs 'newC' function language namesh
On Thu, Nov 16, 2000 at 05:51:07PM +0200, 'Marko Kreen' wrote: > On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote: > > On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote: > > > Create Module foo_mod from library 'path-to-lib'; > > > > Phil - be careful with the nomenclature. We've got another naming collision, > > here. SQL9[29] talk about modules, which may or may not be related to what > > your suggesting here. > > Do you know any url's where the SQL* standards could be looked > up? > > Mark Hollomon's idea was to use 'package' not 'module', but > ofcourse it would be nice to be SQL* conforming. Well, the 1999 standards seem to live at: ftp://jerry.ece.umassd.edu/isowg3/x3h2/Standards/ Which is the working repository for the ANSI database committee (x3h2) Ross -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
Re: [HACKERS] Coping with 'C' vs 'newC' function language namesh
At 05:51 PM 11/16/00 +0200, 'Marko Kreen' wrote: >On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote: >> On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote: >> > Create Module foo_mod from library 'path-to-lib'; >> >> Phil - be careful with the nomenclature. We've got another naming collision, >> here. SQL9[29] talk about modules, which may or may not be related to what >> your suggesting here. > >Do you know any url's where the SQL* standards could be looked >up? I have a copy of the SQL92 draft (the one that's circulated among this group in the past) at dsl-dhogaza.pacifier.net. Just use anonymous ftp, it's in the pub directory with an obvious name (sql1992.txt???) - 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.
[HACKERS] [rfc] new CREATE FUNCTION (and more)
Situation:
7.1 has a new backend interface for loadable modules. (but it
supports old 7.0 interface too)
Now the problem:
How do you tell the backend with what interface to use for
particular function? At the moment 7.1-cvs uses 'newC' instead
of 'C' in the LANGUAGE part.
But this not good:
1) the 'newC' will be quite silly after couple of years, when it
will be the standard.
2) there is another change in the horizon, which would be the
automatic detection of function parameters, or rather the
shared object should provide info about it.
3) It has nothing to do with 'C'. The loadable modules can be
programmed in any language, as long it supports C calling
conventions.
4) And IMHO "LANGUAGE 'C'" is a hack, LANGUAGE construct should be
used only for actual definitions. Now should we extend one hack
with another hack?
Requirement:
7.1 should understand the 7.0 syntax, 7.2 should understand 7.1
and 7.0 syntax. That means the dump/restore should work
between versions. Whether 7.2 has the 'oldC' handler is another
matter, but it should not load it with wrong defaults.
I propose new command:
CREATE FUNCTION name
( [ftype [, ...] ] ) RETURNS rtype
FROM [ LIBRARY ] obj_file AS link_sym
[ WITH [ TYPE = ( 0 | 1 | ... ) ]
[[,] ATTRIBUTE = ( attr [, ...] ) ] ]
This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".
Main difference is that the TYPE=0 means the old 'C' interface
and TYPE=1 means 'newC' interface. Default is 1. (As said,
7.1 supports the old LANGUAGE 'C' variant, so I think it is
not needed the default to be 0.)
CREATE FUNCTION ... AS defn ... LANGUAGE 'C' ..
means 7.0 oldC/Informix interface. No new languages will
come in this way. (I mean those where the defn is actually
objname, symbol pair.)
This only is for compatibility. The ".. LANGUAGE .." should
be only used for the actual definitions.
Alternative:
newC will be created as:
CREATE FUNCTION .. LANGUAGE 'C' WITH (pg_params)
default is old_params, 7.1 pg_dump dumps newC with "(pg_params)".
But as I said this is a hack.
Now some future ideas. I really think that something like that
should come into PostgreSQL eventually.
LOAD MODULE name FROM [LIBRARY] foomodule.so
The lib has a struct (e.g.) pg_module__info which defines
init/remove functions, functions, operators and types. PostgreSQL
registers module somehow, and when the module gets DROPped then
PostgreSQL calls its remove funtions and removes all stuff it has
itself registered.
LOAD FUNCTION name FROM [LIBRARY] foo.so
This means that in the object file there is defined struct
(e.g.) pg_function__info. (Probably by help of macros).
{ I am not sure if the following is needed, better they go through
the LOAD MODULE? }
LOAD TYPE name FROM [LIBRARY] foo.so
Module has struct (e.g.) pg_type__info.
LOAD OPERATOR name FROM [LIBRARY] foo.so AS obj_name
Module has struct (e.g.) pg_operator__info
Random notes:
* why struct not some init funtion? ->
* it will be easier to function/module programmer.
* avoids duplicate code
* makes possible different interfaces.
* main backend can detect incompatible interface
* I am not knowledgeable in dump/restore problems. Someone
who is should comment on this what features are else needed.
* The *.so finding should accept some search paths (LD_LIBRARY_PATH?)
(Does it now?)
* In future maybe some currently 'core' parts can be separated into
'core modules' e.g. all geometric stuff. So they can be
loaded only as needed.
* There was a previous discussion on modules:
Mark Hollomon's idea:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-06/msg00959.html
Jan Wieck objections:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-06/msg00983.html
IMHO the objections are not very strong but sure the modules
interface needs lot of work.
--
marko
Re: [HACKERS] Coping with 'C' vs 'newC' function language namesh
On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote: > On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote: > > Create Module foo_mod from library 'path-to-lib'; > > Phil - be careful with the nomenclature. We've got another naming collision, > here. SQL9[29] talk about modules, which may or may not be related to what > your suggesting here. Do you know any url's where the SQL* standards could be looked up? Mark Hollomon's idea was to use 'package' not 'module', but ofcourse it would be nice to be SQL* conforming. -- marko
Re: [HACKERS] Coping with 'C' vs 'newC' function language namesh
On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote: > > 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. > Phil - be careful with the nomenclature. We've got another naming collision, here. SQL9[29] talk about modules, which may or may not be related to what your suggesting here. Ross -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
Re: AW: AW: AW: [HACKERS] Could turn on -O2 in AIX
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: >> I agree. When I was looking at this code this morning, I was wondering >> what INT_MIN was supposed to represent anyway, if NOSTART_ABSTIME is >> INT_MIN + 1. I think someone messed this up between 4.2 and Postgres95. > Has there been any consensus yet ? If yes, could you apply my patch please ? I have it on my to-do list, but I was waiting to see if Thomas had an objection (since he knows more about the datetime types than the rest of us). He's been at Comdex the last few days, which probably explains the delay. regards, tom lane
AW: AW: AW: [HACKERS] Could turn on -O2 in AIX
> > My solution would be to use INT_MIN for all ports, which has the advantage > > that the above problematic comparison can be converted to !=, > > since no integer will be smaller than INT_MIN. > > I agree. When I was looking at this code this morning, I was wondering > what INT_MIN was supposed to represent anyway, if NOSTART_ABSTIME is > INT_MIN + 1. I think someone messed this up between 4.2 and Postgres95. Has there been any consensus yet ? If yes, could you apply my patch please ? Or should I ask Bruce, for his "faster than his shadow" patch services ? Thanks Andreas
AW: [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?
Has anybody had time to look at how this is done in DB/2, Oracle ? Philip ?
In Informix there is an additional keyword "parameter style".
Thus you have:
create function foo (a int, b int) return{s|ing} int
external name '/path/libmod.so(symbol)' language C
[parameter style informix] [not variant];
We could have "parameter style postgresql" and map that to
some arbitrary string that would not be something the user sees.
As you see this is really very close to what we have or want
and I am really unhappy that there has been no effort at all
to look at what others do. Not that we want to copy some stupidity,
but if it is sane These are also the companies that
have the most influence on future ANSI specs, and thus if we keep
close we will have a better position to stay conformant.
Actually my proposal would be to not advertise "newC" in 7.1 and do
some more research in that area until we have a solid and maybe compatible
interface that also makes the missing features possible
(multiple columns and rows for return, enter the function more than once
to retrieve only part of the result if it consists of many rows).
Andreas
AW: [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. Should definitely make that tuneable (per installation is imho sufficient), no use in waiting if the dba knows there is only very little concurrency. IIRC DB/2 defaults to not using this "commit pooling". Andreas
