Re: [PATCHES] hash index improving v3

Alex Hunsaker napsal(a): On Wed, Sep 10, 2008 at 10:27 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote: On Wed, Sep 10, 2008 at 8:47 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote: What locale did you use? It would be nice to have also comparing between C and any UTF8 locale. I think w

Re: [PATCHES] hash index improving v3

Alex Hunsaker napsal(a): wide: # NOTE not on the same machine as the "narrow" test was run! # spit out 2, 000, 000 random 100 length strings perl gen.pl > data.sql create table test_hash (wide text); copy test_hash from './data.sql'; create index test_hash_num_idx on test_hash using hash (wide

Re: [PATCHES] hash index improving v3

oduce new macros HashGetMetaPage and HashGetBitmap and of course, it break backward on disk format compatibility which we will break it anyway when Xiao's patch will be committed. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://

Re: [PATCHES] hash index improving v3

0; num 0 1805671691 3294821164 4294967297 set enable_bitmapscan to off; select * from test_hash where num = 0; num - 0 CVS HEAD, 8_3_STABLE obviously work if I force the index scan -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/

Re: [PATCHES] hash index improving v3

Alex Hunsaker napsal(a): On Thu, Sep 4, 2008 at 9:48 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote: Ok here are the results: (data generated from the c program before) select count(1) from test_hash; count --- 10011 create index test_hash_num_idx on test_hash using hash (num); CV

Re: [PATCHES] hash index improving v3

I performed code review and see my comments. pgsql/src/backend/access/hash/hashpage.c use sizeof() or something better the 4. pgsql/src/backend/access/hash/hashpage.c New empty line

Re: [PATCHES] page macros cleanup (ver 04)

's easily fixed. On balance it seems like hidden assumptions about alignment are a bigger risk than assumptions about that offset --- anyone want to argue the contrary? I think it is OK and I seen that you already applied a patch. Thanks Zdenek -- Zdenek Kotala S

Re: [PATCHES] page macros cleanup (ver 04)

Heikki Linnakangas napsal(a): Zdenek Kotala wrote: Pavan Deolasee napsal(a): There's another academical discrepancy between these two hunks: I admit I don't understand what that bitmap is, it looks like we're assuming it can take up all the space between page header a

Re: [PATCHES] page macros cleanup (ver 04)

Pavan, Heikki, Is it OK now or do you have any comments? Thanks Zdenek Zdenek Kotala napsal(a): Pavan Deolasee napsal(a): On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: No, there's a itemsz = MAXALIGN(itemsz) call before the ch

Re: [PATCHES] page macros cleanup (ver 04)

)) ) I did not replace PageGetPageSize(page), because other *MaxItemSize has same interface. Revised patch is attached. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql diff -cr pgsql.orig.da8c485e0e2a/src/backend/access

Re: [PATCHES] page macros cleanup

Heikki Linnakangas napsal(a): Zdenek Kotala wrote: By my opinion first place where tuple should be placed is: MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData)) Yeah, but we don't enforce that directly. We enforce it by MAXALIGNing size in PageAddItem, and with the rule that special

Re: [PATCHES] page macros cleanup

Pavan Deolasee napsal(a): On Fri, Jul 4, 2008 at 4:20 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote: By my opinion first place where tuple should be placed is: MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData)) Tuple actually starts from the other end of the block. Yes, but I meant

Re: [PATCHES] page macros cleanup

mSize in nbtree.h. Pavan's comments is correct. It should give same result as my implementation (because BLCKSZ is aligned), but it is better readable and consistent with other. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgres

Re: [PATCHES] page macros cleanup

Heikki Linnakangas napsal(a): Pavan Deolasee wrote: On Fri, Jul 4, 2008 at 1:01 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote: Good catch. I lost in basic arithmetic. What I see now that original definition count sizeof(ItemIdData) twice and on other side it does not take care about MA

Re: [PATCHES] page macros cleanup (ver 03)

Pavan Deolasee napsal(a): On Fri, Jul 4, 2008 at 2:08 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote: Patch modifies HashMaxItemSize. It should require reindex on all hash indexes. Should we bump catalog version? Do we really need that ? Even if the new HashMaxItemSize comes out to be

Re: [PATCHES] page macros cleanup

also in nbtree and hash. I attached updated patch version which also contains fix for Pavan's observation. Patch modifies HashMaxItemSize. It should require reindex on all hash indexes. Should we bump catalog version? thanks Zdenek -- Zdenek Kotala Sun Mi

Re: [PATCHES] page macros cleanup

Pavan Deolasee napsal(a): On Fri, Jun 13, 2008 at 9:38 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote: I attached code cleanup which is related to in-place upgrade. I replace direct access to PageHeader structure with already existing macros and I removed also unnecessary retyping. A

[PATCHES] page macros cleanup

I attached code cleanup which is related to in-place upgrade. I replace direct access to PageHeader structure with already existing macros and I removed also unnecessary retyping. There still lot of places which directly access to PageHeader structure which require new macros/fuction in page API

Re: [PATCHES] partial header cleanup

Alvaro Herrera napsal(a): Zdenek Kotala wrote: This replace xlog.h with xlogdefs.h in bufpage.h. All other changes are forgotten include somewhere. It reduce e.g. bloat to half in itup.h. But, There are still unresolved problems. htup should include bufpage.h, because it needs PageHeader

[PATCHES] partial header cleanup

This replace xlog.h with xlogdefs.h in bufpage.h. All other changes are forgotten include somewhere. It reduce e.g. bloat to half in itup.h. But, There are still unresolved problems. htup should include bufpage.h, because it needs PageHeader size, but there is still unnecessary bufmgr.h include

Re: [PATCHES] pg_lzcompress patch for 8.3, 8.2 branch

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane napsal(a): On the other hand, I remain unconvinced that this problem is severe enough to justify much backporting work. AFAIK we've only seen one occurence of a problem to date. I know about two occurren

Re: [PATCHES] pg_lzcompress patch for 8.3, 8.2 branch

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attached backported pg_lzcompress patch which is already in head for version 8.2 and 8.3. Version 8.1 and prior contains more changes in decompress code and they does not contain any check. Shell I backported it as well

[PATCHES] pg_lzcompress patch for 8.3, 8.2 branch

I attached backported pg_lzcompress patch which is already in head for version 8.2 and 8.3. Version 8.1 and prior contains more changes in decompress code and they does not contain any check. Shell I backported it as well or it will be better to keep it untouched? Zdenek ***

[PATCHES] Removing NONSEG mode

I attach patch which remove nonsegment mode support. It was discussed during last commit fest. Nonsegment mode is possible uses only on couple of FS (ZFS, XFS) and it is not safe on any OS because each OS support more filesystems. I added RELSEG option to the configure script to allow easily comp

Re: [PATCHES] Remove FATAL from pg_lzdecompress

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attach patch which adds boundaries check and memory overwriting protection when compressed data are corrupted. Good point. Is there plan to applied also on other branch? I wasn't planning to back-patch it. Given

Re: [PATCHES] Headers dependencies cleanup

Alvaro Herrera napsal(a): Zdenek Kotala wrote: PS: Is there any reason to do not start to use inline functions instead of macros in some cases? Not all compilers like (== support) inline macros apparently. Is it your assumption or do you mean some specific compiler? IIRC, inline is

Re: [PATCHES] Headers dependencies cleanup

Tom Lane napsal(a): Bruce Momjian <[EMAIL PROTECTED]> writes: Zdenek Kotala wrote: bufpage.h includes bufmgr.h, but bufpage.h does not require any definition from bufmgr.h. I think this dependency is there for long time. My scripts should have found this issue, see src/tools/pgi

Re: [PATCHES] Headers dependencies cleanup

Bruce Momjian napsal(a): Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included b

Re: [PATCHES] Headers dependencies cleanup

Bruce Momjian napsal(a): Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included b

Re: [PATCHES] Headers dependencies cleanup

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file. Bruce periodically

Re: [PATCHES] Headers dependencies cleanup

Tom Lane napsal(a): Alvaro Herrera <[EMAIL PROTECTED]> writes: Zdenek Kotala wrote: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file.

Re: [PATCHES] Headers dependencies cleanup

Alvaro Herrera napsal(a): Zdenek Kotala wrote: During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file. This patch fixes these dependencies around

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Thank your for Your and Alvaro's comments. I attached updated patch version only with YYSTYPE definition. Applied with minor revisions. I fixed pg_conversion.h as well; the only remaining special inclusions in the cat

Re: [PATCHES] actualised execute using patch

you have extra space onPavel Stehule napsal(a): Hello http://archives.postgresql.org/pgsql-patches/2007-10/msg00161.php I actualized this patch for current CVS Hi Pavel, I tested your patch and it works regarding to proposal. However I have some small comments: 1) you have extra space in ./

Re: [PATCHES] script binaries renaming

Tom Lane napsal(a): Bruce Momjian <[EMAIL PROTECTED]> writes: Where are we on this? Tom thinks we don't want this. TODO has: * Prefix command-line utilities like createuser with 'pg_' http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php I think we need to make

Re: [PATCHES] [HACKERS] [0/4] Proposal of SE-PostgreSQL patches

Kohei KaiGai napsal(a): > It seems to me some of SE-PostgreSQL patches are not delivered yet, > although [3/4] and [4/4] were already done. > > Does anti-spam system caught my previous three messages? > If necessary, I will send them again. There is a file size limitation. If your patch is too bi

Re: [PATCHES] Remove FATAL from pg_lzdecompress

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attach patch which adds boundaries check and memory overwriting protection when compressed data are corrupted. Applied with revisions --- it appeared to me that it got the corner case wrong where we find a tag just at the

Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane napsal(a): These examples suggest that maybe what we want is not so much a "no segments ever" mode as a segment size larger than 1GB. PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit (de

Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)

Tom Lane napsal(a): "Zeugswetter Andreas OSB SD" <[EMAIL PROTECTED]> writes: Exactly, e.g. AIX is one of those. jfs (not the newer jfs2) has an option to enable large files, which is not the default and cannot be changed post crfs. And even if it is enabled, jfs has a 64 Gb filesize limit ! Anyb

Re: [PATCHES] Sun Studio on Linux spinlock patch

Tom Lane napsal(a): But I guess the *real* question is why anyone would care ... what benefit is there to using Sun's compiler on Linux? There are severals benefits: 1) Sun Studio is not only compiler. It has a lot of tools like performance analyzer/profiler, memory checker ... There are gr

[PATCHES] Remove FATAL from pg_lzdecompress

I attach patch which adds boundaries check and memory overwriting protection when compressed data are corrupted. Current behavior let code overwrite a memory and after that check if unpacked size is same as expected value. In this case elog execution fails (at least on Solaris - malloc has c

Re: [PATCHES] lc_time and localized dates

Euler Taveira de Oliveira napsal(a): Zdenek Kotala wrote: Yes it is. Only if it is a first word in a sentence or name you should use "Ú". Also name of day is 'pondělí' (Monday) with small p But we're not talking about *sentence*, we need to consider just the *

Re: [PATCHES] Fix pgstatindex using for large indexes

Tom Lane napsal(a): "Florian G. Pflug" <[EMAIL PROTECTED]> writes: Maybe we should just bite the bullet, and implement int64 emulation for platforms that don't provide one? Why? Workarounds such as "use double where needed" have served us perfectly fine so far, with far less effort and notati

Re: [PATCHES] lc_time and localized dates

Euler Taveira de Oliveira napsal(a): Zdenek Kotala wrote: Please, Day names does not have capitalized first letter in Czech language. We have "pondeli" as a Monday. If locale does not do that it is probably intention :-). Hmmm... I don't know about that. I do it that

Re: [PATCHES] lc_time and localized dates

Euler Taveira de Oliveira napsal(a): Hi, Hi Some issues: (i) some locales don't capitalize the first letter. I'm using pg_toupper() to do the job but I'm afraid it's not appropriated. I'm using it 'cause i'm too lazy to move localized_str_toupper(). Any suggestions? Please, Day names doe

Re: [PATCHES] Fix pgstatindex using for large indexes

Tom Lane napsal(a): Tatsuhito Kasahara <[EMAIL PROTECTED]> writes: In pgstatindex.c and pgstattuple.sql, some variables are defined with int type. So when we try to get informations about a large index by using pgstatindex, we get strange value of size and density. Because the values exceed int-

Re: [PATCHES] fix in --help output

Ups. Patch attached Zdenek Zdenek Kotala napsal(a): Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attached patch which replaces any "--..." occurrence with "-c..." on command line. Please see whether forcibly using src/port/getopt

Re: [PATCHES] fix in --help output

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attached patch which replaces any "--..." occurrence with "-c..." on command line. Please see whether forcibly using src/port/getopt.c fixes this, instead. A saner patch would probably add something

Re: [PATCHES] fix in --help output

Peter Eisentraut napsal(a): Am Freitag, 22. Februar 2008 schrieb Zdenek Kotala: Peter Eisentraut napsal(a): Zdenek Kotala wrote: However, I get following error on Solaris: bash-3.2$ /usr/postgres/8.2/bin/postgres -D /tmp/db --share_buffers=16000 /usr/postgres/8.2/bin/postgres: illegal option

Re: [PATCHES] fix in --help output

Alvaro Herrera napsal(a): Zdenek Kotala wrote: If I looked correctly there is no getopt_long. There is only getopt with - as a option. See PostmasterMain: while ((opt = getopt(argc, argv, "A:B:c:D:d:EeFf:h:ijk:lN:nOo:Pp:r:S:sTt:W:-:")) != -1) If I understand correctly

Re: [PATCHES] fix in --help output

Peter Eisentraut napsal(a): Zdenek Kotala wrote: However, I get following error on Solaris: bash-3.2$ /usr/postgres/8.2/bin/postgres -D /tmp/db --share_buffers=16000 /usr/postgres/8.2/bin/postgres: illegal option -- share_buffers=16000 Try "postgres --help" for more information. but

Re: [PATCHES] fix in --help output

Andrew Dunstan napsal(a): Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attach fix for --help output. I replaced --NAME... with -NAME and add some example. getopt parse -- as a end of options and rest of line is not parsed. Surely this is ou

Re: [PATCHES] fix in --help output

Alvaro Herrera napsal(a): Zdenek Kotala wrote: It maybe work on linux but I think it is not portable solution. What we should do is avoid using Solaris' getopt_long and instead use the copy we have in src/port/. If I looked correctly there is no getopt_long. There is only getopt

Re: [PATCHES] fix in --help output

Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: I attach fix for --help output. I replaced --NAME... with -NAME and add some example. getopt parse -- as a end of options and rest of line is not parsed. Surely this is outright wrong. Or if you do have a getopt that act

[PATCHES] --describe-config crashes

Function printMixedStruct calls printf with NULL argument. It causes segmentation fault. Please, apply it for 8.3 - 8.1 too. thanks Zdenek Index: src/backend/utils/misc/help_config.c === RCS file: /zfs_data/c

[PATCHES] fix in --help output

I attach fix for --help output. I replaced --NAME... with -NAME and add some example. getopt parse -- as a end of options and rest of line is not parsed. This should be backported for 8.3 and 8.2 as well. PG8.1 does not have this options. Thanks Zdenek Index: src/backend/main/m

Re: [PATCHES] DOC: Wal update

Bruce Momjian wrote: Zdenek Kotala wrote: I add few sentences how to write cache works on Solaris platform. I have updated our documentation with the attached patch. I was able to verify all the information in this change. Thanks. I changed your original wording because the statement

[PATCHES] DOC: Wal update

I add few sentences how to write cache works on Solaris platform. Zdenek Index: doc/src/sgml/wal.sgml === RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/doc/src/sgml/wal.sgml,v retrieving revision 1.49 diff -c -r1.49 wa

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Tom Lane napsal(a): (a) it wasn't "to build at all", it was to allow "inline" to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. I don't think that you have right. inline is just optimizer hint and Sun Studio perfor

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. (a) it wasn't "to build at all", it was to allow "inline" to be enabled on Sun Studi

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Zdenek Kotala wrote: What do you mean "not very portable"? What could be problem there? I'm not sure. My point is that it seems your parse.h requires TYPE_IS_DECLARED, but mine doesn't. What else coul

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Alvaro Herrera wrote: Zdenek Kotala wrote: Alvaro Herrera wrote: 3) Put following fake into keyword.c before include "parse.h" line. It is easiest way. #define TYPE_IS_DECLARED 1 #define YYLTYPE_IS_DECLARED 1 #define YYLTYPE void* #define YYSTYPE void* New version of patch is a

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Alvaro Herrera wrote: Zdenek Kotala wrote: Zdenek Kotala wrote: Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php I found two problems there. One is

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php I found two problems there. One is that I forgot postgres.h include in common.c. it is easy to fix

Re: [PATCHES] Fix pg_dump dependency on postgres.h

Alvaro Herrera wrote: Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php This fix contains several steps: 1) I removed sugar word from postgres.h and

[PATCHES] Fix pg_dump dependency on postgres.h

Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php This fix contains several steps: 1) I removed sugar word from postgres.h and put them closer to consumer :-). I created incl

[PATCHES] compiler warning fix

Sun studio reports following warnings during src/interfaces/ecpg/ecpglib/prepare.c compilation: "prepare.c", line 34: warning: storage class after type is obsolescent "prepare.c", line 35: warning: storage class after type is obsolescent Attached patch fixes a problem. Zdenek

[PATCHES] fix ZIC dependency on postgres.h

I attached patch which removes dependency on postgres.h during ZIC compilation. It was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php Zdenek Index: src/include/pgtime.h === RCS

[PATCHES] Fix ecpg dependency on postgres.h

I attached the patch which fix ecpg dependency on postgresql.h. This was discussed on hackers: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php Directory pgsql/src/interfaces/ecpg/preproc/parser should be removed and there is new file pgsql/src/interfaces/ecpg/preproc/parser.c

[PATCHES] Headers dependencies cleanup

During my work I found some header files, which include useless headers and on other way there are some headers which silently assume that requested header will be included by some other headers file. This patch fixes these dependencies around bufpage.h, bufmgr.h Zdene

[PATCHES] two new chklocale aliases

I add two encoding aliases used in Solaris. Zdenek Index: src/port/chklocale.c === RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/src/port/chklocale.c,v retrieving revision 1.6 diff -c -r1.6 chklocale.c *** src/port/chk

Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03

Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with

Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03

Tom Lane wrote: "Marko Kreen" <[EMAIL PROTECTED]> writes: solaris openssl refuses to handle keys longer than 128bits. ... So something like the current patch should be still applied as a near-term fix. Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or i

Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03

Marko Kreen wrote: solaris openssl refuses to handle keys longer than 128bits. * aes will crash on longer keys * blowfish will silently cut the key which can result data corruption to fix it: - test errors from AES functions - bf errors cannot be tested, do test encryption - change aes compa

Re: [PATCHES] Using system time zone database

Peter Eisentraut wrote: Because there seems to be an increasing trend among packagers to drop the PostgreSQL-supplied time zone data and use the operating system's instead, Because it seems government in many countries make a decision to make live harder. :( I figured it would be good to def

Re: [PATCHES] pgcrypto (v02)

There is updated version of patch. See comments bellow: Marko Kreen wrote: On 7/27/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote: I attach pgcrypto patch which fix two problems on system without strong crypto support (e.g. default Solaris 10 installation): 1) postgres crashes when AES

[PATCHES] pgcrypto

I attach pgcrypto patch which fix two problems on system without strong crypto support (e.g. default Solaris 10 installation): 1) postgres crashes when AES cipher uses long key 2) Blowfish silently cut longer keys. It could bring problem when crypted data are transfered from one server to anoth

Re: [PATCHES] script binaries renaming

Jaime Casanova wrote: what makes me wonder why doesn't exist "pg_ctl init" I suggested it in previous discussion on hackers. See http://archives.postgresql.org/pgsql-hackers/2007-06/msg00142.php Zdenek ---(end of broadcast)--

Re: [PATCHES] script binaries renaming

Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Dave Page wrote: This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. But

Re: [PATCHES] script binaries renaming

Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: There is group of people who has different opinion. The main reasons for this patch are 1) names could collide with system tools That argument is purely theoretical, though, since no one has complained to us of an *actual* col

Re: [PATCHES] script binaries renaming

Joshua D. Drake wrote: Michael Glaesemann wrote: On Jul 6, 2007, at 5:53 , Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser

Re: [PATCHES] script binaries renaming

Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I

Re: [PATCHES] script binaries renaming

Magnus Hagander wrote: Zdenek Kotala wrote: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb to pg_createdb pg_createlang pg_createuser pg_dropdb pg_droplang pg_dropuser pg_clusterdb pg_vacuumdb

[PATCHES] script binaries renaming

I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb to pg_createdb pg_createlang pg_createuser pg_dropdb pg_droplang pg_dropuser pg_clusterdb pg_vacuumdb pg_reindexdb Symlinks (or copy on win32) are c

[PATCHES] New Zealand - TZ change

I would like to inform, that New Zealand changed DST rules and new timezone files are available. See http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended Patch for head attached. I kept zic.c untouched, but I think it would be nice to update it

[PATCHES] WIP: script binaries renaming

I attach patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb to pg_createdb pg_createlang pg_createuser pg_dropdb pg_droplang pg_dropuser pg_clusterdb pg_vacuumdb pg_reindexdb Symlinks (or copy on win32) are created f

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

Pavan Deolasee napsal(a): On 5/29/07, *Zdenek Kotala* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: I'm looking on your patch. I have one comment: If you have old tid and new tid you can easy compare if new tid points to different page? And if page is

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

Pavan Deolasee wrote: On 1/28/07, *Tom Lane* <[EMAIL PROTECTED] > wrote: OTOH it might be cleaner to refactor things that way, if we were going to apply this. Here is a revised patch which includes refactoring of heap_get_latest_tid(), as per Tom's suggesti

Re: [PATCHES] Fix for large file support (nonsegment mode support)

Tom Lane wrote: [ redirecting to -hackers for wider comment ] Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane wrote: LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I fixed. It is size of offset. I went thru the code and did not see any other problem there. H

Re: [PATCHES] Fix for large file support

Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Andrew Dunstan wrote: Indeed, but that would be far more effectively addressed by fixing the *other* code path that doesn't segment at all (the LET_OS_MANAGE_FILESIZE option, which is most likely broken these days for lack

Re: [PATCHES] Fix for large file support

Andrew Dunstan wrote: Does it mean the maximum field size will grow beyond 1Gb? No. Because it is limited by varlena size. See http://www.postgresql.org/docs/8.2/interactive/storage-toast.html Or give better performance? Yes. List of chunks is stored as linked list and for some operati

[PATCHES] Fix for large file support

Current version of postgres support only 1GB chunks. This limit is defined in the pg_config_manual.h header file. However this setting allows to have maximal 2GB chunks. Main problem is that md storage manager and buffile use "long" data type (32bits) for offset instead "off_t" defined in . o

Re: [PATCHES] OS timezone files support

Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane wrote: I certainly don't see the point of the implementation as you have it --- it adds a great deal of unnecessary infrastructure compared to just installing a symlink at share/postgresql/timezone. The point of

Re: [PATCHES] OS timezone files support

Magnus Hagander wrote: Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: This patch brings possibility to switch from default build-in timezone to another timezone source - typically to OS timezone location. It was discussed few weeks ago: http://archives.postgresql.org/pgsql-h

Re: [PATCHES] OS timezone files support

Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: This patch brings possibility to switch from default build-in timezone to another timezone source - typically to OS timezone location. It was discussed few weeks ago: http://archives.postgresql.org/pgsql-hackers/2007-03/msg007

[PATCHES] OS timezone files support

This patch brings possibility to switch from default build-in timezone to another timezone source - typically to OS timezone location. This enhancement helps to packagers easy solve integration problem with systems Timezones. If --with-tzdir=/usr/share/zoneinfo is specified as ./configure p

Re: [PATCHES] [BUGS] BUG #2969: Inaccuracies in Solaris FAQ

Peter Eisentraut wrote: Zdenek Kotala wrote: There is Solaris FAQ update. Please, look on it and let me know any comments. The actual answer to the question "Can I compile PostgreSQL with Kerberos v5 support?" is "Yes, why not?". I don't think "Can I use this

Re: [PATCHES] [BUGS] BUG #2969: Inaccuracies in Solaris FAQ

There is Solaris FAQ update. Please, look on it and let me know any comments. Thanks Zdenek Rich Teer wrote: The following bug has been logged online: Bug reference: 2969 Logged by: Rich Teer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.2 Operating s

Re: [HACKERS] [PATCHES] Dynamic Tracing docs

Simon Riggs napsal(a): On Sat, 2006-12-02 at 09:43 +0100, Peter Eisentraut wrote: Simon Riggs wrote: Enclose new trace.sgml file as discussed on -docs. I have a question here, regarding this: To include DTrace support in a 64-bit binary, specify --enable-dtrace and DTRACEFLAGS="-64" to

Re: [PATCHES] small patch with czech translations for names of months

Pavel Stehule napsal(a): Hello, This patch allow use TM prefix in to_char functions for czech environment. Regards Pavel Stehule + + #: utils/adt/formatting.c:3009 + msgid "Wed" + msgstr "©tø" + Pavel, great job. I have only two comments: 1) There is typo. Correct is msgstr "Stø". 2)

  1   2   >