Re: [HACKERS] Limits of backwards compatibility for psql's \d commands
Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: ... So it's just 7.3 that's worth debating, I think. EOL is EOL, why is the question even being asked? Well, pg_dump still supports servers back to 7.0 (and yes I do test that now and again). psql probably doesn't need to support interactive query operations quite so far back, but I think the boundary of what's needed is pretty squishy. Hence my query about what people really want. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?
Tom Lane wrote: Currently, config.sgml still describes the new enum GUC variables as being of type string --- but pg_settings says they are enum. This is not very consistent, but I wonder whether changing the docs would be more confusing or less so. I note that section 18.1 doesn't mention the enum alternative either. From the perspective of the person setting it in the config, it still looks like a string, which is why I chose not to change it. I think it'd make things more confusing. 18.1 probably deserves a note about it though, I'll see if I can come up with something good there. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Limits of backwards compatibility for psql's \d commands
Tom Lane a écrit : I'm fooling around with Guillaume Lelarge's patch to make psql's \d commands work with older server versions. The patch as submitted works with servers back to 7.4 (modulo a small bug or two). I tried to see what it'd take to make it work with 7.3. I count about a dozen trivial diffs and about three nontrivial ones --- nontrivial meaning I didn't see a simple fix right away. This seems a bit more work than is justified for a server version that the community has officially dropped support for, but I wonder if anyone feels hot about it? I don't think we should add support for pre-7.4 releases. I even didn't try to look at 7.3 release because it's not maintained anymore. Anyways, if someone thinks it should be done, I can work on it. Pre-7.3 server versions seem entirely out of the realm of reason because they lack schema support, meaning all of those pg_catalog. prefixes break, not to mention the joins to pg_namespace and the schema output columns. So it's just 7.3 that's worth debating, I think. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Limits of backwards compatibility for psql's \d commands
At 2008-07-02 09:16:30 +0200, [EMAIL PROTECTED] wrote: I don't think we should add support for pre-7.4 releases. I agree. It's not worth the effort. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest status?
Tom Lane napsal(a): Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? There is Collation at database level patch. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php Please, put it on the list. I'm not able edit the wiki page now. :( Thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest status?
Zdenek Kotala napsal(a): Tom Lane napsal(a): Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? There is Collation at database level patch. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php Please, put it on the list. I'm not able edit the wiki page now. :( After short battle added. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Please claim review items for commit fest!
On 7/2/08, Josh Berkus [EMAIL PROTECTED] wrote: Just in case anyone was unclear, this is how we're trying things for this commitfest: 1) Starting RIGHT NOW, reviewers should claim review items they are interested in or specially qualified to review. 2) This weekend, I will check for all items which don't have one or more reviewers and parcel them out to the Round Robin Reviewers who don't already have patches to review. You do not have to be a committer to be a reviewer. Anyone who knows C code and is familiar with PostgreSQL can be a reviewer. Heck, even non-C coders can review proposed APIs. Each item can have several reviewers, and probably should. Oh, also reviewers -- please try to use constructive criticism! Some people are submitting their first patch, and we don't want them to leave the project forever. Thanks! I don't understand one aspect - if I'm unfamiliar with Postgres and cannot do full review or am familiar but cannot do full review due to time aspects but still want to throw some quick comments, should I register on wiki? And potentially make some actual reviewers to skip the patch? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Please claim review items for commit fest!
On Wed, Jul 2, 2008 at 11:37 AM, Marko Kreen [EMAIL PROTECTED] wrote: I don't understand one aspect - if I'm unfamiliar with Postgres and cannot do full review or am familiar but cannot do full review due to time aspects but still want to throw some quick comments, should I register on wiki? And potentially make some actual reviewers to skip the patch? In that situation, just add your comments to the wiki page using the appropriate template, but don't bother to list yourself as a reviewer (for the very reason you suggest). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Please claim review items for commit fest!
On 7/2/08, Dave Page [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 11:37 AM, Marko Kreen [EMAIL PROTECTED] wrote: I don't understand one aspect - if I'm unfamiliar with Postgres and cannot do full review or am familiar but cannot do full review due to time aspects but still want to throw some quick comments, should I register on wiki? And potentially make some actual reviewers to skip the patch? In that situation, just add your comments to the wiki page using the appropriate template, but don't bother to list yourself as a reviewer (for the very reason you suggest). The comments should go to wiki? Not mailing list? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Please claim review items for commit fest!
On Wed, Jul 2, 2008 at 11:44 AM, Marko Kreen [EMAIL PROTECTED] wrote: On 7/2/08, Dave Page [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 11:37 AM, Marko Kreen [EMAIL PROTECTED] wrote: I don't understand one aspect - if I'm unfamiliar with Postgres and cannot do full review or am familiar but cannot do full review due to time aspects but still want to throw some quick comments, should I register on wiki? And potentially make some actual reviewers to skip the patch? In that situation, just add your comments to the wiki page using the appropriate template, but don't bother to list yourself as a reviewer (for the very reason you suggest). The comments should go to wiki? Not mailing list? It's a fine line (and slightly bendy line) - but simple comments can go on the wiki, discussion should go to the list and be referenced from the wiki. For example, see the 'returned for feedback' section at the end of the last commit fest: http://wiki.postgresql.org/wiki/CommitFest:2008-05 -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [patch] plproxy v2
I took the libery and changed the status from WIP to Pending Review, because the pending cleanups do not affect reviewing nor committing. And anyway, because of the patch size I expect reviewers requesting furthers changes so I'd like to push the tiny stuff to final version of the patch. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] A Windows x64 port of MySQL
Hello everyone,
I don't really know much about contributing to projects, mailing
lists, or really anything that has to do with the UNIX culture (I am
not a UNIX fan). So forgive my ignorance of how this is supposed to
work.
Basically I am trying to compile postgres as a native x64 application.
I haven't gotten very far at all yet (I've fixed three very tiny
bugs) but I figured I'd try to get in touch with people on this list
before I do any more. Perhaps someone is already farther along than I
am, and if not, I can at least share my three tiny bug fixes with the
community and save you about 15-20 minutes :)
Basically the reason I started doing this was a misunderstanding; I
thought the ODBC driver (which is all I really need) always used libpq
to communicate with the server. As you may know, 32-bit and 64-bit
DLLs cannot load one another thus postgres being 32-bit forces
everything dependent on it to be 32-bit as well. While postgres works
fine in the SysWow64 environment on x64, there is no way to talk to it
from a 64-bit application because the ODBC driver is 32-bit. The
program I am writing is 64-bit only, thus I can't get database access.
Apparently from looking at the ODBC driver source code, it appears
that it is actually independent of postgres, does not explicitly on
depend on libpq, but uses sockets to directly communicate with the
server? Either way, I didn't know that so I started trying to build
an x64 version. I am aware that one of the contributers has created
an x64 driver here:
http://www.geocities.jp/inocchichichi/psqlodbc/index.html. It says
really experimental and I wonder what that means exactly, i.e., is
there work I should do to test it? There is nothing about it on the
main website (it was extremely hard to find that website).
Anywhere, here are the problems I found and the changes that a Windows
port maintainer might want to make:
To pg_config_os.h:
=
On line 7:
change
#define _WIN32_WINNT 0x0500
to
#ifdef _WIN64
#define _WIN32_WINNT 0x0501
#else
#define _WIN32_WINNT 0x0500
#endif
Why: The first value (0x0500) is for Windows 2000, the second value
(0x0501) is for Windows XP or Server 2003. AFAIK 2000 did not support
x64 anyway so there is no harm in doing this (if _WIN64 is defined,
you can be assured the platform is at least 5.01). If you do not do
it, the IPPROTO_IPV6 macro in w2defs.h will not be defined. The fact
that this did not cause problems before probably means that the nature
of the #ifdef is different in w2defs.h for the 32-bit version of the
Win32 API. Microsoft's x64 port of Win32 requires it to be 0x0501 in
the winsock headers or IPPROTO_IPV6 is not defined. If that happens,
there will be an error in pqcomm.c
To s_lock.h:
=
On line 809:
change
static __forceinline void
spin_delay(void)
{
/* see comment for gcc code. Same code, MASM syntax */
__asm rep npo;
}
to
#ifdef _WIN64
static __forceinline void
spin_delay(void)
{
__noop;
}
#else
static __forceinline void
spin_delay(void)
{
/* see comment for gcc code. Same code, MASM syntax */
__asm rep nop;
}
#endif
Why: None of Microsoft's x64 compilers (including 2008) support inline
assembly, so __asm is not recognized. This function implements a
delay for a spinlock by calling rep; nop; an instruction sequence
used by intel to delay and slow the processor speed down to the memory
bus speed. On AMD architectures it is the same as a regular nop. If
you can do rep; nop; this with the x64 compiler intrinsics (which
are in the compiler, unlike the ability the inline assembly), I
couldn't figure out how. I have an AMD processor anyway, so this is
the same as a regular nop for which there _is_ an intrinsic (__noop).
Note that as I type this, I realize that the #ifdef should not be
_WIN64 as this is not an inherent limitation of the architecture but
all current compilers. This should be conditioned on _MSVC_VER, the
compiler version number instead. I am not sure what the current
version is, however, so I'll just leave it like that.
To the postgres project:
=
-Remove /DEF:.\Release\postgres\postgres.def from the compiler
command line options.
Why: This is explained here: http://support.microsoft.com/kb/835326
Functions in the postgres project have a declspec(__dllexport)
declarator and the project uses a DEF file, but they shouldn't do
both. With the pre-x64 compilers, it is ok to define exports twice as
long as the definition is exactly the same. With the x64 compiler, it
is not ok (see link). Defining BUILDING_DLL will cause all exported
functions to have the declspec(__dllexport) declarator, so you can
either undefine BUILDING_DLL or remove the exporting option at the
project level. If you do not, first the linker will first produce
LNK4197 warnings, then lots of linker errors.
Other stuff:
The only remaining compile error issue has to do with the
_USE_32BIT_TIME_T workaround, which no longer works in x64
[HACKERS] pg_compresslog/pg_decompresslog
I found the discussion about log compressing here: http://archives.postgresql.org/pgsql-patches/2007-03/msg00502.php But I cannot find the scripts (pg_compresslog/pg_decompresslog), how can I get those? Will this work for 8.1 branch too? I want to use PITR, but archiving over one days will generate too much wal data, so this kind of compression would be quite helpful. Regards, Mario -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of PostgreSQL
Ken Camann napsal(a): Hello everyone, I don't really know much about contributing to projects, mailing lists, or really anything that has to do with the UNIX culture (I am not a UNIX fan). So forgive my ignorance of how this is supposed to work. I think you meant PostgreSQL not MySQL in the subject :-). Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
David E. Wheeler napsal(a): On Jul 1, 2008, at 07:38, Tom Lane wrote: However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. And even more of us have written queries using LOWER(col) = LOWER(?), which is just a PITA. OK. I'm going to review your patch. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fairly serious bug induced by latest guc enum changes
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Not having looked at md.c (I confess...) but don't we have a problem in case we have closed the file without fsyncing it, and then change the fsync parameter? Well, we don't promise to retroactively fsync stuff we didn't before; and I wouldn't expect that to happen if I were changing the setting. What I *would* expect is that the system immediately starts to act according to the new setting, and that's not true as the code stands. As you say, the whole thing is pretty dubious from a data safety standpoint anyway. What I am concerned about here is people trying to compare performance measurements under different settings, and not being aware that the system's behavior doesn't change when they tell it to. Well, if they're running a performance measure that generates 16Mb data, I don't think they'll get very usable numbers anyway... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Please claim review items for commit fest!
Dave Page [EMAIL PROTECTED] writes: On Wed, Jul 2, 2008 at 11:44 AM, Marko Kreen [EMAIL PROTECTED] wrote: The comments should go to wiki? Not mailing list? It's a fine line (and slightly bendy line) - but simple comments can go on the wiki, discussion should go to the list and be referenced from the wiki. For example, see the 'returned for feedback' section at the end of the last commit fest: http://wiki.postgresql.org/wiki/CommitFest:2008-05 It is a fine line, but I think anything about the substance of the patch really ought to go to the list so other people get a chance to respond. IMHO the wiki is best thought of as a kind of group todo list. Notes about the status of a patch and a bottom-line summary for future reference makes sense to keep there. Something like review found problems with memory management so we can reprioritize it without rereading the emails for every item. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of MySQL
--On Mittwoch, Juli 02, 2008 07:39:29 -0400 Ken Camann [EMAIL PROTECTED] wrote: I assume it would only really matter if you did this to a pointer, and perhaps that is happening somewhere (but I doubt it since postgres runs fine on 64-bit POSIX OSes). These would be easy to fix, but very annoying given the number of them. At least, every Datum depends on something like that, see src/include/postgres.h: sizeof(Datum) == sizeof(long) = sizeof(void *) = 4 -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Location for pgstat.stat
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Well, it doesn't :-) No database or table will be processed until stat entries are created, and then I think it will first wait until enough activity gathers to take any actions at all. That's not actualliy not affected, but it does seem like it wouldn't be a very big issue. If one table was just about to be vacuumed or analyzed, this would just push it up to twice the threshold, right? Except you could lather, rinse, repeat indefinitely. Yeha, but if you do that, you certainly have other problems as well The stats system started out with the idea that the stats were disposable, but I don't really think that's an acceptable behavior today. We don't even have stats_reset_on_server_start anymore. Good point. It doesn't seem to me that it'd be hard to support two locations for the stats file --- it'd just take another parameter to the read and write routines. pgstat.c already knows the difference between a normal write and a shutdown write ... Right. Should it be removed from the permanent location when the server starts? Otherwise, if it crashes, we'll pick up the old, stale, version of the file since it didn't have a chance to get saved away. Better to start from an empty file, or to start from one that has old data in it? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
Yay! Best, David Sent from my iPhone On Jul 2, 2008, at 5:03, Zdenek Kotala [EMAIL PROTECTED] wrote: David E. Wheeler napsal(a): On Jul 1, 2008, at 07:38, Tom Lane wrote: However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. And even more of us have written queries using LOWER(col) = LOWER (?), which is just a PITA. OK. I'm going to review your patch. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Location for pgstat.stat
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: It doesn't seem to me that it'd be hard to support two locations for the stats file --- it'd just take another parameter to the read and write routines. pgstat.c already knows the difference between a normal write and a shutdown write ... Right. Should it be removed from the permanent location when the server starts? Yes, I would say so. There are two possible exit paths: normal shutdown (where we'd write a new file) and crash. In a crash we'd wish to delete the file anyway for fear that it's corrupted. Startup: read permanent file, then delete it. Post-crash: remove any permanent file (same as now) Shutdown: write permanent file. Normal stats collector write: write temp file. Backend stats fetch: read temp file. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing
Tom Lane wrote: It would be simple enough to fix nodeSubplan.c to copy the data into an upper-level Slot rather than a bare tuple. But this makes me wonder how many other places are like this. In the past there wasn't that much benefit to pulling data from a Slot instead of a bare tuple, so I'm afraid we might have a number of similar gotchas we'd have to track down. I compare this to adding CHECK_FOR_INTERRUPTS(): let's declare that every usage of bare tuples is a not-very-serious bug, and we can fix them one by one as we come across them. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
Radek Strnad escribió: 2) What type should all names in CREATE and DROP statement in gram.y have? I've chosen qualified_name but I know it's not the best choice. I think it should be ColId. 3) All collations are created from existing collations. How do I ensure that the collation already exists? Is there any possibility to define it in gram.y? Certainly not -- shouldn't they come from a catalog? In that case, it must come in parse analysis (parser/analyze.c I guess) or perhaps later, when you actually execute the function to create the new collation. 5) Also can you look at the pg_catalog and tell me if anything is wrong with it? Why does a collation have a schema? What's the existing collation? It seems a bit silly to have enum for what are basically boolean variables. Why not just use true and false? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
David E. Wheeler napsal(a): Howdy, Howdy Please find attached a patch adding a locale-aware, case-insensitive text type, called citext, as a contrib module. A few notes: I went through your code and I have following comments/questions: 1) formating Please, do not type space before asterix: char * lcstr, * rcstr - char *lcstr, *rcstr and do not put extra space in a brackets citextcmp( left, right ) - citextcmp(left, right) Other seems to me OK (remove 8.2 version mention at the bottom) 2) citextcmp function returns int but citext_cmp returns int32. I think citextcmp should returns int32 as well. 3) citext_larger, citext_smaller function have memory leak. You don't call PG_FREE_IF_COPY on unused text. I'm not sure if return value in these function should be duplicated or not. 4) Operator = citext_eq is not correct. See comment http://doxygen.postgresql.org/varlena_8c.html#8621d064d14f259c594e4df3c1a64cac There must be difference between equality and collation for example in Czech language 'láska' and 'laská' are different word it means that 'láska' != 'laská'. But there is no difference in collation order. See Unicode Universal Collation Algorithm for detail. 5) There are several commented out lines in CREATE OPERATOR statement mostly related to NEGATOR. Is there some reason for that? Also OPERATOR || has probably wrong negator. 6) You use pgTAP for unit test. It is something what should be widely discussed. It is new approach and I'm not correct person to say if it good or not. I see there two problems: At first point there is not clear licensing (https://svn.kineticode.com/pgtap/trunk/README.pgtap). And, It should be implemented as a general framework by my opinion not only as a part of citext contrib module. Please, let me know when you will have updated code and I will start deep testing. With regards Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
Am Dienstag, 1. Juli 2008 schrieb Tom Lane: Zdenek Kotala [EMAIL PROTECTED] writes: However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. Indeed, but why isn't this code put there as well? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql 8.3 issue
Am Montag, 30. Juni 2008 schrieb Jamie Deppeler: I am trying to build a new installer application. I am in the process of upgrading postgresql 8.1 to 8.3.3 but i am having a issue which i can't seemed to resolve. Error output from rpmbuilder + su -c - user'$RPM_BUILD_ROOT/usr/local/app/pgsql/bin/postmaster -D $RPM_BUILD_ROOT/usr/local/app/pgsql/data -S ' /var/tmp/app-root/usr/local/app/pgsql/bin/postmaster: option requires an argument -- S Try postmaster --help for more information. error: Bad exit status from /var/tmp/rpm-tmp.12297 (%install) You are probably referring to the fact that some option names have changed. Please review the documentation to pick the right ones for you. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] pg crashing
[moving over to hackers] Tom Lane wrote: BTW, just looking at win32_shmem.c ... retptr = malloc(bufsize + 1 + 18);/* 1 NULL and 18 for * Global\PostgreSQL: */ if (retptr == NULL) elog(FATAL, could not allocate memory for shared memory name); strcpy(retptr, Global\\PostgreSQL:); r = GetFullPathName(DataDir, bufsize, retptr + 11, NULL); Surely that 11 ought to be 18. Also, since the loop immediately Yes. Very true. It still *works*, since it guts off on the proper side of the \, but it still makes sense. below this is going to convert \ to /, wouldn't it be clearer to describe the path prefix as Global/PostgreSQL: in the first place? Eh, that shows another bug I think. It should *not* convert the \ in Global\, because that one is is interpreted by the Win32 API call! I think it should be per this patch. Seems right? (BTW, as far as I can tell the +1 added to the malloc request is useless: bufsize includes the trailing null, and the code would not work if it did not.) Yeah, also true. //Magnus Index: win32_shmem.c === RCS file: /cvsroot/pgsql/src/backend/port/win32_shmem.c,v retrieving revision 1.4 diff -c -r1.4 win32_shmem.c *** win32_shmem.c 1 Jan 2008 19:45:51 - 1.4 --- win32_shmem.c 2 Jul 2008 16:44:40 - *** *** 47,64 elog(FATAL, could not get size for full pathname of datadir %s: %lu, DataDir, GetLastError()); ! retptr = malloc(bufsize + 1 + 18); /* 1 NULL and 18 for * Global\PostgreSQL: */ if (retptr == NULL) elog(FATAL, could not allocate memory for shared memory name); strcpy(retptr, Global\\PostgreSQL:); ! r = GetFullPathName(DataDir, bufsize, retptr + 11, NULL); if (r == 0 || r bufsize) elog(FATAL, could not generate full pathname for datadir %s: %lu, DataDir, GetLastError()); ! for (cp = retptr; *cp; cp++) if (*cp == '\\') *cp = '/'; --- 47,64 elog(FATAL, could not get size for full pathname of datadir %s: %lu, DataDir, GetLastError()); ! retptr = malloc(bufsize + 18); /* 1 NULL and 18 for * Global\PostgreSQL: */ if (retptr == NULL) elog(FATAL, could not allocate memory for shared memory name); strcpy(retptr, Global\\PostgreSQL:); ! r = GetFullPathName(DataDir, bufsize, retptr + 18, NULL); if (r == 0 || r bufsize) elog(FATAL, could not generate full pathname for datadir %s: %lu, DataDir, GetLastError()); ! for (cp = retptr + 18; *cp; cp++) if (*cp == '\\') *cp = '/'; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: It would be simple enough to fix nodeSubplan.c to copy the data into an upper-level Slot rather than a bare tuple. But this makes me wonder how many other places are like this. In the past there wasn't that much benefit to pulling data from a Slot instead of a bare tuple, so I'm afraid we might have a number of similar gotchas we'd have to track down. I compare this to adding CHECK_FOR_INTERRUPTS(): let's declare that every usage of bare tuples is a not-very-serious bug, and we can fix them one by one as we come across them. Unfortunately we can't usefully have such a rule --- consider sorting for example. We're not going to change over to using TupleTableSlots as the items being sorted. What I foresee if we go down this path is that there will be some places where we can fix toasting performance problems by inserting a Slot, and some where we can't. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
Alvaro Herrera [EMAIL PROTECTED] writes: Why does a collation have a schema? Because the SQL spec says so. Also, if we don't put them in schemas, we have no nice way to distinguish built-in and user-defined collations, which creates a problem for pg_dump. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
Tom Lane escribió: Alvaro Herrera [EMAIL PROTECTED] writes: Why does a collation have a schema? Because the SQL spec says so. Also, if we don't put them in schemas, we have no nice way to distinguish built-in and user-defined collations, which creates a problem for pg_dump. Oh, I see :-) In that case, qualified_name would seem the right symbol to use in the parser. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
Sync with current CVS HEAD and post in hackers- too because patches- close to the closing. http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
Tom Lane [EMAIL PROTECTED] writes: Alvaro Herrera [EMAIL PROTECTED] writes: Why does a collation have a schema? Because the SQL spec says so. Also, if we don't put them in schemas, we have no nice way to distinguish built-in and user-defined collations, which creates a problem for pg_dump. Out of curiosity, what is a user-defined collation? Are there SQL statements to go around declaring what order code points should be sorted in? That seems like it would be... quite tedious! -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
On Wed, Jul 02, 2008 at 07:22:10PM +0100, Gregory Stark wrote: Because the SQL spec says so. Also, if we don't put them in schemas, we have no nice way to distinguish built-in and user-defined collations, which creates a problem for pg_dump. Out of curiosity, what is a user-defined collation? Are there SQL statements to go around declaring what order code points should be sorted in? That seems like it would be... quite tedious! Not that we'll ever use it, but ICU for example allows users to say: use collation X but move this code point somewhere else, essentially allowing users tweak the collation on a small scale. In any case, whatever collation library is used, we're unlikely to predefine every possible collation in the system, there's too many (assuming they're denumerable). Have a niceday, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] PATCH: CITEXT 2.0
I went through your code and I have following comments/questions: one more comment: 7) Hash opclass is absent. Hash opclass framework is used for hash join. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
My patch should be sort of wrapper that will implement guts for further development (collation at column level) like catalogs, creating collations etc. When creating collation user will be able to choose which function to use (by statement STRCOLFN - not in SQL standard). In the first stage I'll implement function that will use system locales. Adding ICU or any other library won't be that big deal. Radek Strnad On Wed, Jul 2, 2008 at 8:22 PM, Gregory Stark [EMAIL PROTECTED] wrote: Tom Lane [EMAIL PROTECTED] writes: Alvaro Herrera [EMAIL PROTECTED] writes: Why does a collation have a schema? Because the SQL spec says so. Also, if we don't put them in schemas, we have no nice way to distinguish built-in and user-defined collations, which creates a problem for pg_dump. Out of curiosity, what is a user-defined collation? Are there SQL statements to go around declaring what order code points should be sorted in? That seems like it would be... quite tedious! -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!
Re: [HACKERS] A Windows x64 port of PostgreSQL
On Wed, Jul 2, 2008 at 9:09 AM, Bernd Helmle [EMAIL PROTECTED] wrote: --On Mittwoch, Juli 02, 2008 07:39:29 -0400 Ken Camann [EMAIL PROTECTED] wrote: I assume it would only really matter if you did this to a pointer, and perhaps that is happening somewhere (but I doubt it since postgres runs fine on 64-bit POSIX OSes). These would be easy to fix, but very annoying given the number of them. At least, every Datum depends on something like that, see src/include/postgres.h: sizeof(Datum) == sizeof(long) = sizeof(void *) = 4 Oh I see. Between this and looking again at the warning list, I see that it will probably take a lot more work than I thought. There are about 450 occurrences of the assumption that sizeof(size_t) == sizeof(int). Many of them come from string functions, but many are in important files like the tuplestore.c, bufpage.c, etc. I assume these these would need to be checked very carefully, and probably by someone who understands the internals better than I do. I'd really like to help out with this, but I'm not sure I can work on a patch even if I change these things for myself. Fixing this code would touch a lot of important internals in postgres (albeit in a small way), so my patch would probably not be accepted. I assume this kind of thing has to be done by someone a little closer to the project because it would modify so many things. On the other hand, if I just do this for myself and don't share it then I lose x64 support again when 8.4 comes out...and I really want the on-disk bitmap indices and better partitioning (if the latter ends up coming). So I'm not really sure what to do. I've never contributed to anything before, and I've actually never even used CVS. I will probably start making changes for myself, but before I do I'd like to know if I should bother doing it in such a way that might be useful to the community. Thanks, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Auto-explain patch
Its certainly not useful to *me* in its current form. It would produce way to much (usless) output. However if it were tied to log_min_duration_statement so I get auto explains for long running queries... That would be very useful indeed. Even if it has to explain everything just to toss out the explain if it did not meet log_min_duration_statement. Unless I missed something and thats exactly what it does? Thanks for the feedback. I agree, it does need a way to limit the output, and target just the slow-running queries. I also remember now the problem I had last time:- since this debug output is produced at a lower level than the other statement logging (so it can explain *all* SQL executed, not just top-level statements), it is difficult to control using the normal statement logging parameters. It would be easy to add another parameter, debug_explain_min_duration, specific to this option, to limit it to slow low-level queries. This would allow setting debug_explain_min_duration to be smaller than log_min_duration_statement, which makes sense, since the latter controls logging of top-level statements which may result in multiple low-level queries. Doing it this way would mean instrumenting all queries, but only explaining the slow ones, when debug_explain_plan is on. I'll have a play and see how it goes... Regards, Dean _ Live Search Charades - guess correctly and find hidden videos http://www.searchcharades.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest status?
On Tue, Jul 1, 2008 at 4:19 PM, Tom Lane [EMAIL PROTECTED] wrote: Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? we noticed the libpq events (hooks) patch was missing...so we duly added it :-). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of PostgreSQL
On Wed, Jul 2, 2008 at 8:32 PM, Ken Camann [EMAIL PROTECTED] wrote: I'd really like to help out with this, but I'm not sure I can work on a patch even if I change these things for myself. Fixing this code would touch a lot of important internals in postgres (albeit in a small way), so my patch would probably not be accepted. I assume this kind of thing has to be done by someone a little closer to the project because it would modify so many things. We don't work like that - anyone can have a patch accepted for any part of the code, no matter how much previous experience they have. One of the most complex patches we've ever dealt with (HOT) was largely written by a new contributor. So I'm not really sure what to do. I've never contributed to anything before, and I've actually never even used CVS. I will probably start making changes for myself, but before I do I'd like to know if I should bother doing it in such a way that might be useful to the community. You might prefer to learn git rather than CVS - it will probably make life easier to keep your work in sync with CVS head through the use of the git mirror. Contributing is simple though. First, read the FAQ (http://wiki.postgresql.org/wiki/Developer_FAQ). Then, tell us you're working on the project, and start coding. Try to break the work down into logical sections to aid reviewing and discussion. Post WIP patches for people to look over, and don't be afraid to ask if you're not sure about something. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest status?
On Tuesday 01 July 2008 17:38:28 Josh Berkus wrote:
On Tue, 01 Jul 2008 16:19:39 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Well, it's July 1, and time for another commit fest to begin.
Do we have all the submitted patches queued up at
http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
I think Bruce and I have added everything submitted to June 29. I've
been offline for 36 hours, though, so I'm scanning hackers and patches
now. Help welcomed -- I'm on dial-up and it's slow.
Time for people to start volunteering to review stuff! I'll start
round-robin after a few days. So put your names on the stuff you know
you can review now.
Note that Robert Lor has an updated patch for the dtrace probes that we have
seen over here @ omniti, but I don't think he has posted it yet, so it isn't
reflected in the wiki... Robert, care to post that?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Working on native Windows x64 version of PostgreSQL
Hi everyone. For those who have seen my other thread, I have decided to take the plunge: I am going to try to get PostgreSQL to compile as a native Windows x64 application (so that it will be able to interface with x64 DLLs) and I will contribute my changes to the community. As you know, many of the extra postgres features rely on external libraries available from gnuwin32, so these must also be converted to x64 DLLs or they won't work. I will be starting small, disabling all these extra features and only trying to build the core functionality. I plan to work on this in a few stages, submitted as work in progress patches, because I think this will require a lot of changes. The first stage is very simple though; I will be modifying the Perl scripts in the src/tools/msvc directory to support the x64 compiler. I am using Microsoft Visual C 2008, but I will try to ensure everything works with Visual C 2005 (no previous versions have an x64 compiler, so there are only 2 platforms to support). While this is the simplest change, it may need the most review. I am a good C programmer but I barely know Perl. That has its advantages; it will ensure I stick to the style currently used since I have no other habits. -Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Working on native Windows x64 version of PostgreSQL
On Wed, Jul 2, 2008 at 10:41 PM, Ken Camann [EMAIL PROTECTED] wrote: Hi everyone. For those who have seen my other thread, I have decided to take the plunge: I am going to try to get PostgreSQL to compile as a native Windows x64 application (so that it will be able to interface with x64 DLLs) and I will contribute my changes to the community. :-) As you know, many of the extra postgres features rely on external libraries available from gnuwin32, so these must also be converted to x64 DLLs or they won't work. I will be starting small, disabling all these extra features and only trying to build the core functionality. That's perfectly reasonable. I plan to work on this in a few stages, submitted as work in progress patches, because I think this will require a lot of changes. The first stage is very simple though; I will be modifying the Perl scripts in the src/tools/msvc directory to support the x64 compiler. I am using Microsoft Visual C 2008, but I will try to ensure everything works with Visual C 2005 (no previous versions have an x64 compiler, so there are only 2 platforms to support). I would suggest generating just VC2k5 project files, and then modifying the build scripts to upgrade them first if required. We do something similar with wxWidgets for pgAdmin's use - albeit converting VC++6 files to 2k5 - using the /upgrade option in vcbuild.exe. I assume something similar is feasible for 2k5 - 2k8. Regards, Dave -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] pg crashing
Magnus Hagander [EMAIL PROTECTED] writes: below this is going to convert \ to /, wouldn't it be clearer to describe the path prefix as Global/PostgreSQL: in the first place? Eh, that shows another bug I think. It should *not* convert the \ in Global\, because that one is is interpreted by the Win32 API call! I was wondering about that. What are the implications of that? I think it should be per this patch. Seems right? Pls fix the comment on the malloc, too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] WITH RECURSIVE updated to CVS TIP
Folks, Please find patch enclosed, including some documentation. Can we see about getting this in this commitfest? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate recursive_query-7.patch.bz2 Description: BZip2 compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] patch - Collation at database level
Gregory Stark [EMAIL PROTECTED] writes: Out of curiosity, what is a user-defined collation? Are there SQL statements to go around declaring what order code points should be sorted in? That seems like it would be... quite tedious! Hm, that's a good point. SQL99 has collation definition ::= CREATE COLLATION collation name FOR character set specification FROM existing collation name [ pad characteristic ] existing collation name ::= collation name pad characteristic ::= NO PAD | PAD SPACE which seems pretty stupid if you ask me --- all the mechanism required to manage a new object type, just to enable PAD SPACE or not? (Especially when PAD SPACE itself is an utterly broken, useless concept ... but I digress.) You might as well just provide all the standard collations in both variants and be done with it. The statement looks the same in last year's 200n draft, so it's not like they were just about to add some more capability. We might be best off to treat collations like index access methods, ie, they're theoretically add-able but there's no infrastructure for managing them, and what's expected is that all the ones you need are created by initdb. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Limits of backwards compatibility for psql's \d commands
On Jul 2, 2008, at 1:23 AM, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: ... So it's just 7.3 that's worth debating, I think. EOL is EOL, why is the question even being asked? Well, pg_dump still supports servers back to 7.0 (and yes I do test that now and again). psql probably doesn't need to support interactive query operations quite so far back, but I think the boundary of what's needed is pretty squishy. Hence my query about what people really want. Being able to get your data out of 7.3 is a lot more important than \d commands... :) -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Location for pgstat.stat
On Jul 1, 2008, at 3:02 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Well, it doesn't :-) No database or table will be processed until stat entries are created, and then I think it will first wait until enough activity gathers to take any actions at all. That's not actualliy not affected, but it does seem like it wouldn't be a very big issue. If one table was just about to be vacuumed or analyzed, this would just push it up to twice the threshold, right? Except you could lather, rinse, repeat indefinitely. The stats system started out with the idea that the stats were disposable, but I don't really think that's an acceptable behavior today. We don't even have stats_reset_on_server_start anymore. It doesn't seem to me that it'd be hard to support two locations for the stats file --- it'd just take another parameter to the read and write routines. pgstat.c already knows the difference between a normal write and a shutdown write ... Leaving the realm of an easy change, what about periodically (once a minute?) writing stats to a real table? That means we should never have to suffer corrupted or lost stats on a crash. Along the same lines, perhaps we can just keep updates in shared memory instead of in a file, since that's proven to cause issues for some people. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Limits of backwards compatibility for psql's \d commands
On Wed, 2008-07-02 at 18:39 -0500, Decibel! wrote: On Jul 2, 2008, at 1:23 AM, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: ... So it's just 7.3 that's worth debating, I think. EOL is EOL, why is the question even being asked? Well, pg_dump still supports servers back to 7.0 (and yes I do test that now and again). psql probably doesn't need to support interactive query operations quite so far back, but I think the boundary of what's needed is pretty squishy. Hence my query about what people really want. Being able to get your data out of 7.3 is a lot more important than \d commands... :) It may seem peculiar but I would consider adding support for \d commands to 8.4 for 7.3 a feature for 7.3 not 8.4. Let's stick with upgrade support on that one, not backward compatibility :) Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
Peter Eisentraut [EMAIL PROTECTED] writes: Am Dienstag, 1. Juli 2008 schrieb Tom Lane: Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. Indeed, but why isn't this code put there as well? Well, actually, that might be the best thing to do with it. But it would be sensible to give it a code review anyway, no? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of PostgreSQL
Ken Camann [EMAIL PROTECTED] writes: Oh I see. Between this and looking again at the warning list, I see that it will probably take a lot more work than I thought. There are about 450 occurrences of the assumption that sizeof(size_t) == sizeof(int). [ blink... ] There are *zero* occurrences of the assumption that sizeof(size_t) == sizeof(int), unless maybe in some of that grotty #ifdef WIN32 code. Postgres has run on 64-bit platforms for many years now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Location for pgstat.stat
Decibel! [EMAIL PROTECTED] writes: Leaving the realm of an easy change, what about periodically (once a minute?) writing stats to a real table? The ensuing vacuum overhead seems a sufficient reason why not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump lock timeout
Dave, Just a few comments regarding your pg_dump lock timeout patch (in general I like the concept and agree with adding it): - No validity checking that the argument passed in has anything to do with a number. The backend will do this, but it strikes me as a bit odd to not do any checking at argument processing time. - You call the argument 'wait time' in the documentation, but 'DELAY' in the command-line help. I'd recommend using one term and sticking to it. You're already two lines in the command-line help, you can spell it out as 'WAIT_TIME' or similar. - getTables() uses different variables for each query, and I'm inclined to agree with that approach to make following the code easier. I'd encourage you to add a new variable for the statement_timeout query rather than reusing the lockqry variable. You could even offset this by removing the unused delqry variable. Otherwise, looks good to me. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Git Repository for WITH RECURSIVE and others
Hi, From: David Fetter [EMAIL PROTECTED] Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others Date: Tue, 24 Jun 2008 07:47:13 -0700 With lots of help from Greg Sabino Mullane, I've set up a git repository for the WITH RECURSIVE patches on http://git.postgresql.org/. Thank you very much. I tried git-clone, but I could not access the repository. % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ fatal: The remote end hung up unexpectedly fetch-pack from 'git://git.postgresql.org/git/~davidfetter/postgresql/.git' failed. I ran git-update-server-info on the server, and it should work now. :) I cannot get yet... % cat ~/.gitconfig [user] name = Yoshiyuki Asaba email = [EMAIL PROTECTED] # WITH RECURSIVE repository % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ fatal: The remote end hung up unexpectedly fetch-pack from 'git://git.postgresql.org/git/~davidfetter/postgresql/.git' failed. # PostgreSQL repository % git clone git://git.postgresql.org/git/postgresql.git Initialized empty Git repository in /home/y-asaba/git/x/postgresql/.git/ fatal: The remote end hung up unexpectedly fetch-pack from 'git://git.postgresql.org/git/postgresql.git' failed. # another PostgreSQL repository (I can get.) git clone git://repo.or.cz/PostgreSQL.git Initialized empty Git repository in /home/y-asaba/git/x/PostgreSQL/.git/ remote: Counting objects: 323716, done. remote: Compressing objects: 100% (53329/53329), done. ... Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DTrace probes.
On Monday 19 May 2008 11:32:28 Theo Schlossnagle wrote:
Howdy,
I just saw Robert Lor's patch w.r.t. dtrace probes. It looks very
similar in what we've done. We run a nice set of probes in production
here that allow us to track the details of checkpointing and statement
execution. I've given a few presentations around these probes and
have had very positive feedback. They've been available for a while
now, but I never got around to sending them to the list:
https://labs.omniti.com/trac/project-dtrace/browser/trunk/postgresql/8.3.1.
patch?format=txt
Documentation is in wiki format, but I'd be happy to convert it to
something else:
https://labs.omniti.com/trac/project-dtrace/wiki/Applications#PostgreSQL
Attached is the patch combining Theo's patch from above into the original
patch from Robert Lor. It is supposed to build on OSX and Solaris. I'll be
updating the July commitfest entry to point to this patch, case anyone wants
to review it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: src/backend/access/transam/clog.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/clog.c,v
retrieving revision 1.46
diff -u -3 -p -r1.46 clog.c
--- src/backend/access/transam/clog.c 1 Jan 2008 19:45:46 - 1.46
+++ src/backend/access/transam/clog.c 26 Jun 2008 23:18:30 -
@@ -36,6 +36,7 @@
#include access/slru.h
#include access/transam.h
#include postmaster/bgwriter.h
+#include pg_trace.h
/*
* Defines for CLOG page sizes. A page is the same BLCKSZ as is used
@@ -323,7 +324,9 @@ void
CheckPointCLOG(void)
{
/* Flush dirty CLOG pages to disk */
+ TRACE_POSTGRESQL_CLOG_CHECKPOINT_START();
SimpleLruFlush(ClogCtl, true);
+ TRACE_POSTGRESQL_CLOG_CHECKPOINT_DONE();
}
Index: src/backend/access/transam/multixact.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/multixact.c,v
retrieving revision 1.27
diff -u -3 -p -r1.27 multixact.c
--- src/backend/access/transam/multixact.c 1 Jan 2008 19:45:46 - 1.27
+++ src/backend/access/transam/multixact.c 26 Jun 2008 23:18:31 -
@@ -57,6 +57,7 @@
#include storage/lmgr.h
#include utils/memutils.h
#include storage/procarray.h
+#include pg_trace.h
/*
@@ -1526,6 +1527,8 @@ MultiXactGetCheckptMulti(bool is_shutdow
void
CheckPointMultiXact(void)
{
+ TRACE_POSTGRESQL_MULTIXACT_CHECKPOINT_START();
+
/* Flush dirty MultiXact pages to disk */
SimpleLruFlush(MultiXactOffsetCtl, true);
SimpleLruFlush(MultiXactMemberCtl, true);
@@ -1540,6 +1543,8 @@ CheckPointMultiXact(void)
*/
if (!InRecovery)
TruncateMultiXact();
+
+ TRACE_POSTGRESQL_MULTIXACT_CHECKPOINT_DONE();
}
/*
Index: src/backend/access/transam/slru.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/slru.c,v
retrieving revision 1.44
diff -u -3 -p -r1.44 slru.c
--- src/backend/access/transam/slru.c 1 Jan 2008 19:45:48 - 1.44
+++ src/backend/access/transam/slru.c 26 Jun 2008 23:18:32 -
@@ -57,6 +57,7 @@
#include storage/fd.h
#include storage/shmem.h
#include miscadmin.h
+#include pg_trace.h
/*
@@ -372,6 +373,8 @@ SimpleLruReadPage(SlruCtl ctl, int pagen
{
SlruShared shared = ctl-shared;
+ TRACE_POSTGRESQL_SLRU_READPAGE_START((uintptr_t)ctl, pageno, write_ok, xid);
+
/* Outer loop handles restart if we must wait for someone else's I/O */
for (;;)
{
@@ -399,6 +402,7 @@ SimpleLruReadPage(SlruCtl ctl, int pagen
}
/* Otherwise, it's ready to use */
SlruRecentlyUsed(shared, slotno);
+ TRACE_POSTGRESQL_SLRU_READPAGE_DONE(slotno);
return slotno;
}
@@ -446,6 +450,7 @@ SimpleLruReadPage(SlruCtl ctl, int pagen
SlruReportIOError(ctl, pageno, xid);
SlruRecentlyUsed(shared, slotno);
+ TRACE_POSTGRESQL_SLRU_READPAGE_DONE(slotno);
return slotno;
}
}
@@ -470,6 +475,8 @@ SimpleLruReadPage_ReadOnly(SlruCtl ctl,
SlruShared shared = ctl-shared;
int slotno;
+ TRACE_POSTGRESQL_SLRU_READPAGE_READONLY((uintptr_t)ctl, pageno, xid);
+
/* Try to find the page while holding only shared lock */
LWLockAcquire(shared-ControlLock, LW_SHARED);
@@ -511,6 +518,8 @@ SimpleLruWritePage(SlruCtl ctl, int slot
int pageno = shared-page_number[slotno];
bool ok;
+ TRACE_POSTGRESQL_SLRU_WRITEPAGE_START((uintptr_t)ctl, pageno, slotno);
+
/* If a write is in progress, wait for it to finish */
while (shared-page_status[slotno] == SLRU_PAGE_WRITE_IN_PROGRESS
shared-page_number[slotno] == pageno)
@@ -525,7 +534,10 @@ SimpleLruWritePage(SlruCtl ctl, int slot
if (!shared-page_dirty[slotno] ||
shared-page_status[slotno] != SLRU_PAGE_VALID ||
shared-page_number[slotno] != pageno)
+ {
+ TRACE_POSTGRESQL_SLRU_WRITEPAGE_DONE();
return;
+ }
/*
* Mark the slot write-busy, and clear the dirtybit. After this point, a
@@ -569,6 +581,8
Re: [HACKERS] Git Repository for WITH RECURSIVE and others
On Thu, Jul 03, 2008 at 11:16:49AM +0900, Yoshiyuki Asaba wrote: Hi, From: David Fetter [EMAIL PROTECTED] Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others Date: Tue, 24 Jun 2008 07:47:13 -0700 With lots of help from Greg Sabino Mullane, I've set up a git repository for the WITH RECURSIVE patches on http://git.postgresql.org/. Thank you very much. I tried git-clone, but I could not access the repository. % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ fatal: The remote end hung up unexpectedly fetch-pack from 'git://git.postgresql.org/git/~davidfetter/postgresql/.git' failed. I ran git-update-server-info on the server, and it should work now. :) I cannot get yet... % cat ~/.gitconfig [user] name = Yoshiyuki Asaba email = [EMAIL PROTECTED] I don't have a ~/.gitconfig. Does it work when you don't use one? I've run git-update-server-info again, for what that's worth. Also, what version of git are you using? I'm using git 1.5.5 without trouble. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git Repository for WITH RECURSIVE and others
At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote: # WITH RECURSIVE repository % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ fatal: The remote end hung up unexpectedly Run git-clone http://git.postgresql.org/git/~davidfetter/postgresql/.git instead. git://... apparently doesn't work on that repository (I don't know why not). -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of PostgreSQL
On Wed, Jul 2, 2008 at 8:43 PM, Tom Lane [EMAIL PROTECTED] wrote: Ken Camann [EMAIL PROTECTED] writes: Oh I see. Between this and looking again at the warning list, I see that it will probably take a lot more work than I thought. There are about 450 occurrences of the assumption that sizeof(size_t) == sizeof(int). [ blink... ] There are *zero* occurrences of the assumption that sizeof(size_t) == sizeof(int), unless maybe in some of that grotty #ifdef WIN32 code. Postgres has run on 64-bit platforms for many years now. Hi Tom. I knew about the previous 64 bit platform support, which is why I was so surprised to see the problem. Unless I am missing an important #define that somehow makes this stuff go away (but I don't think so, given how much of it there is) it does happen to be in there. If I haven't done anything wrong, I would assume no one noticed because those architectures define sizeof(long) to be = sizeof(size_t). Well actually, let me be as strict as possible because I don't know the latest C standards very well (I am a C++ programmer). Am I correct that the standard says that sizeof(size_t) must be sizeof(void*), and that no compiler has ever said otherwise? I think so, given what size_t is supposed to mean. So I tend use sizeof(void*) and sizeof(size_t) interchangeably. Sorry for the confusion if that is less clear. According to postgres.h (not conditionally defined by anything) states that all the code assumes: sizeof(Datum) == sizeof(long) = sizeof(void *) = 4 where the first equation is reflexively true because Datum is a long typedef. EMT64/AMD64 is new compared to the older architectures, I would guess the older ones predate the time when it became a somewhat de facto standard to leave long int at 4 bytes, and make long long the new 64-bit type. In fact this definition is so common that it will soon be the de jour C++ standard definition. I assume ISO C still will not fix byte lengths to the declarators since they've fought it for so long. In any case, if sizeof(long) = 4 this fails to be true. This is more interesting still (in c.h) /* * Size * Size of any memory resident object, as returned by sizeof. */ typedef size_t Size; /* * Index * Index into any memory resident array. * * Note: * Indices are non negative. */ typedef unsigned int Index; /* * Offset * Offset into any memory resident array. * * Note: * This differs from an Index in that an Index is always * non negative, whereas Offset may be negative. */ typedef signed int Offset; There seems to be an interesting mix of size_t, long, and int in use for memory. No one has noticed possibly because the shared buffers per single user have never been bigger than 2GB for anyone. Postgres documentation recommends big numbers like 20 or 30 MB, and the default is much smaller. In order to have had problems with this, you'd probably need all the following to happen at once: 1.) a huge enterprise (with lots of money to buy memory but using postgres and not Oracle) doing data warehousing on enormous tables 2.) on a platform where sizeof(int) = sizeof(long) = 4 but sizeof(void*) = 8 3.) a DBA who wanted the shared buffers 2 GB 4.) An operating system supporting 2GB of memory 5.) An operating system willing to allocate continuous blocks 2 GB 6.) An cstdlib implementation of malloc willing to allocate continuous blocks 2 GB 7.) Exactly the right query to make it explode. I think it happens to work out that not all of those have happened simultaneously yet. Anyway, there are a lot of other sizeof(int) == sizeof(size_t) assumptions in totally unimportant places, here's one in bootstrap.c int len; len = strlen(str); //possible loss of data That kind is very common. -Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
On Jul 2, 2008, at 09:13, Zdenek Kotala wrote: I went through your code and I have following comments/questions: Thanks. I'm on a short family vacation, so it will probably be Monday before I can submit a new patch. I got a few replies below, though. 1) formating Please, do not type space before asterix: char * lcstr, * rcstr - char *lcstr, *rcstr and do not put extra space in a brackets citextcmp( left, right ) - citextcmp(left, right) Okay. Other seems to me OK (remove 8.2 version mention at the bottom) Um, are you referring to this (at the top): +// PostgreSQL 8.2 Magic. +#ifdef PG_MODULE_MAGIC +PG_MODULE_MAGIC; +#endif That's gotta be there (though I can of course remove the comment). 2) citextcmp function returns int but citext_cmp returns int32. I think citextcmp should returns int32 as well. Yeah, I'm a bit confused by this. I followed what's in varlena.c on this. The comparison functions are documented supposed to return 1, 0, or -1, which of course would be covered by int. But varstr_cmp(), which ultimately returns the value, returns all kinds of numbers. So, perhaps someone could say what it's *supposed* to be? 3) citext_larger, citext_smaller function have memory leak. You don't call PG_FREE_IF_COPY on unused text. I'm not sure if return value in these function should be duplicated or not. These I also duplicated from varlena.c, and I asked about a potential memory leak in a previous email. If there's a leak here, would there not also be a leak in varlena.c? 4) Operator = citext_eq is not correct. See comment http://doxygen.postgresql.org/varlena_8c.html#8621d064d14f259c594e4df3c1a64cac So should citextcmp() call strncmp() instead of varst_cmp()? The latter is what I saw in varlena.c. There must be difference between equality and collation for example in Czech language 'láska' and 'laská' are different word it means that 'láska' != 'laská'. But there is no difference in collation order. See Unicode Universal Collation Algorithm for detail. I'll leave the collation stuff to the functions I call (*far* from my specialty), but I'll add a test for this and make sure it works as expected. Um, although, with what collation should it be tested? The tests I wrote assume en_US.UTF-8. 5) There are several commented out lines in CREATE OPERATOR statement mostly related to NEGATOR. Is there some reason for that? I copied it from the original citext.sql. Not sure what effect it has. Also OPERATOR || has probably wrong negator. Right, good catch. 6) You use pgTAP for unit test. It is something what should be widely discussed. It is new approach and I'm not correct person to say if it good or not. Sure. I created a pgFoundry project for it here: http://pgtap.projects.postgresql.org/ I see there two problems: At first point there is not clear licensing (https://svn.kineticode.com/pgtap/trunk/README.pgtap ). That's a standard revised BSD license. And, It should be implemented as a general framework by my opinion not only as a part of citext contrib module. It is. I just put the file in citext so that the tests can use it. It's distributed on pgFoundry and maintained at the SVN URL quoted in the file. Please, let me know when you will have updated code and I will start deep testing. Will do. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of PostgreSQL
Ken Camann [EMAIL PROTECTED] writes: Well actually, let me be as strict as possible because I don't know the latest C standards very well (I am a C++ programmer). Am I correct that the standard says that sizeof(size_t) must be sizeof(void*), and that no compiler has ever said otherwise? I'm not sure that the spec actually requires that in so many words, but it's hard to imagine a sane implementation where it isn't true. (Now, I've worked on some less-than-sane hardware, but that stuff all died the real death in the eighties or so. Flat memory models have been the only kind anyone would tolerate for a long time now.) EMT64/AMD64 is new compared to the older architectures, I would guess the older ones predate the time when it became a somewhat de facto standard to leave long int at 4 bytes, and make long long the new 64-bit type. Apparently your definition of de facto standard is any idiotic decision Microsoft cares to make. AFAIK there is *no* system other than WIN64 where long is narrower than size_t; and I rather doubt that there ever will be any. long long is generally understood to mean a type that the hardware supports, but not very efficiently (ie, it's double the native word width) --- and one would hope that pointers are not in that category. On a 64-bit machine LL really ought to denote 128-bit arithmetic ... I wonder what curious syntax Microsoft will invent when they realize their compilers ought to support that? Anyway, back to the immediate problem. What would probably make sense to try as a first step is something like #ifndef WIN64 typedef unsigned long Datum;/* XXX sizeof(long) = sizeof(void *) */ #else typedef unsigned long long Datum; /* Microsoft's out in left field */ #endif and see how many warnings that eliminates ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
On Jul 2, 2008, at 09:39, Peter Eisentraut wrote: Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. Indeed, but why isn't this code put there as well? It could be, but this is *such* a common need (and few even know about pgFoundry), that I thought it'd be worthwhile to get it distributed as part of contrib. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
On Jul 2, 2008, at 12:18, Teodor Sigaev wrote: 7) Hash opclass is absent. Hash opclass framework is used for hash join. Thanks. I haven't seen docs on this. The original citext only supports btree, and I don't remember reading about creating a hash opclass in the Douglass book, though I probably missed it. Anyone got a link for me to read to make it happen? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
On Jul 2, 2008, at 17:21, Tom Lane wrote: Indeed, but why isn't this code put there as well? Well, actually, that might be the best thing to do with it. But it would be sensible to give it a code review anyway, no? Obviously, I would argue that contrib is a good place for it, hence the patch. I can say more on my reasoning if you'd like. But even if it doesn't end up in contrib, I'm extremely grateful for the code reviews. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git Repository for WITH RECURSIVE and others
Hi, From: Abhijit Menon-Sen [EMAIL PROTECTED] Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others Date: Thu, 3 Jul 2008 09:18:17 +0530 At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote: # WITH RECURSIVE repository % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ fatal: The remote end hung up unexpectedly Run git-clone http://git.postgresql.org/git/~davidfetter/postgresql/.git instead. git://... apparently doesn't work on that repository (I don't know why not). Thanks for the advice. I could get the repository via HTTP. Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: CITEXT 2.0
David E. Wheeler [EMAIL PROTECTED] writes: On Jul 2, 2008, at 09:13, Zdenek Kotala wrote: Please, do not type space before asterix: char * lcstr, * rcstr - char *lcstr, *rcstr and do not put extra space in a brackets citextcmp( left, right ) - citextcmp(left, right) Okay. Note that this sort of stuff will mostly be fixed by pg_indent, whether or not David does anything about it. But certainly conforming to the project style to begin with will cause less pain to reviewers' eyeballs. Um, are you referring to this (at the top): +// PostgreSQL 8.2 Magic. +#ifdef PG_MODULE_MAGIC +PG_MODULE_MAGIC; +#endif Here however is an outright bug: we do not allow // comments, because we still support ANSI-spec compilers that don't recognize them. Yeah, I'm a bit confused by this. I followed what's in varlena.c on this. The comparison functions are documented supposed to return 1, 0, or -1, which of course would be covered by int. But varstr_cmp(), which ultimately returns the value, returns all kinds of numbers. So, perhaps someone could say what it's *supposed* to be? btree cmp functions are allowed to return int32 negative, zero, or positive. There is *not* any requirement that negative or positive results be exactly -1 or +1. However, if you are comparing values that are int32 or wider then you can't just return their difference because it might overflow. 3) citext_larger, citext_smaller function have memory leak. You don't call PG_FREE_IF_COPY on unused text. These I also duplicated from varlena.c, and I asked about a potential memory leak in a previous email. If there's a leak here, would there not also be a leak in varlena.c? The leak is irrelevant for larger/smaller. The only place where it's actually useful to do PG_FREE_IF_COPY is in a btree or hash index support function. In other cases you can assume that you're being called in a memory context that's too short-lived for it to matter. 5) There are several commented out lines in CREATE OPERATOR statement mostly related to NEGATOR. Is there some reason for that? I copied it from the original citext.sql. Not sure what effect it has. http://developer.postgresql.org/pgdocs/postgres/xoper-optimization.html regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A Windows x64 port of PostgreSQL
On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane [EMAIL PROTECTED] wrote: Ken Camann [EMAIL PROTECTED] writes: EMT64/AMD64 is new compared to the older architectures, I would guess the older ones predate the time when it became a somewhat de facto standard to leave long int at 4 bytes, and make long long the new 64-bit type. Apparently your definition of de facto standard is any idiotic decision Microsoft cares to make. AFAIK there is *no* system other than WIN64 where long is narrower than size_t; and I rather doubt that there ever will be any. long long is generally understood to mean a type that the hardware supports, but not very efficiently (ie, it's double the native word width) --- and one would hope that pointers are not in that category. On a 64-bit machine LL really ought to denote 128-bit arithmetic ... I wonder what curious syntax Microsoft will invent when they realize their compilers ought to support that? Actually, it isn't my definition. I haven't really worked with enough compilers to make a claim like that, I got that impression (and the phrase de facto) from the proceedings of the C++0x standards committee where they finalized long long as being required to be 8 bytes. I think it ultimately does come from Microsoft/Intel, because they did follow the old width convention in the 16 bit days, that is sizeof(int) was 2 (word width) and sizeof(long) was 4. When 32-bit arrived (much too late, at Microsoft) most x86 compilers that had formerly used the segmented memory model made int 4 bytes like people felt it was supposed to be but left long at 4 the way it was so as not to bloat all the variables to double words on such a register-poor architecture as x86. I actually think of Borland Turbo C++ and Intel more than Microsoft when I think of this decision. For that reason, I would have thought you would see the same thing on all x86 systems...but now I realize that's stupid. Once you leave Windows its a gcc world, so it would be the way it always should have been, on every POSIX system. Even then though, if I were to use Linux on x64, wouldn't sizeof(int) be 4 and not 8? I bring this up for more reasons than spamming the list with trivia, it leads to a very important question: Anyway, back to the immediate problem. What would probably make sense to try as a first step is something like #ifndef WIN64 typedef unsigned long Datum;/* XXX sizeof(long) = sizeof(void *) */ #else typedef unsigned long long Datum; /* Microsoft's out in left field */ #endif and see how many warnings that eliminates ... It's a question about style. If Microsoft Visual C really is the only one like this, then I guess there is no harm in #ifdef _WIN64 instead of #ifdef (some other name that captures the peculiarity of what is happening but isn't MSFT dependent). win32.h (not written by me) already defines SIZEOF_SIZE_T and SIZEOF_LONG_INT (or something like that)...It might be a better idea to use those two. But the thing is, this isn't the only issue. There is the fact that int appears in c.h for memory offsets and not long. As long as I might have to change a whole lot of this stuff to make exceptions for windows, I was wondering what the community thinks of the way this is all currently handled and what advice they have might have for me when changing stuff. There seems to be two problems that affect 64-bit POSIX systems too: 1. An object in memory can have size Size (= size_t). So its big (maybe 8 bytes). 2. An index into the buffer containing that object has index Index (= int) So its smaller (maybe 4 bytes). Now you can't index your big object, unless sizeof(size_t) = sizeof(int). But sizeof(size_t) must be at least 8 bytes on just about any 64-bit system. And sizeof(int) is still 4 most of the time, right? But I am thinking that if I knew more about postgres, maybe I would realize something important, like the way that it works ensures that Offset is never greater than a certain amount, because (for example, I have no idea if this is true or not) maybe its only used to point inside a disk block or something. Who would know this? -Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
