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 we should see big
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);
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/postgresql
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://sun.com/postgresql
bÄžné podadresáÅe
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 Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-patches mailing list (pgsql
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Pavan Deolasee napsal(a):
There's another academical discrepancy between these two hunks:
snip
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 and the
special
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 quick review
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 Microsystems
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 lower than
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 MAXALING
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 first
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/gist/gistutil.c
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
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
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
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
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 occurrence. One
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
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
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 the lack
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 by some
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 by some
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/pginclude
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
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
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
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 runs
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 catalog header
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
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
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 big (I
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 !
Anybody
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
(depends on solaris
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 end
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
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
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 way 'cause I'm concerned
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 notational
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
*word*. So I think TMMonth should
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
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
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 the POSIX
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
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 like this
to configure.in:
if test
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:
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:
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 acts
that way
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
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 outright
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 following
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
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
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
performs
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 Studio's
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
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 attached. I
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 could be lurking
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
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
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
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
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
===
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
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
***
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
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
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 if
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 Solaris. We
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
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 cipher uses
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* collision
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
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)---
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
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
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
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
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
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 still same
Pavan Deolasee wrote:
On 1/28/07, *Tom Lane* [EMAIL PROTECTED] mailto:[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 suggestion.
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. However
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
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
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 of testing
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 my solution
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/msg00784.php
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-hackers
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 weird internal private library
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
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
Pavel Stehule napsal(a):
Hello,
This patch allow use TM prefix in to_char functions for czech environment.
Regards
Pavel Stehule
Snip
+
+ #: 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)
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
like that.
OK, The behavior of regproc type
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that
Zdenek Kotala wrote:
Alvaro Herrera wrote:
What's global? A maybe-useful flag would be telling that a table is
shared. Is that it? Mind you, it's not useful to me because I know
which tables are shared, but I guess for someone not so familiar with
the catalogs it could have some use
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is new version of catalogs overview patch. This version add only
one column into overview table which contains Oid/Filename for each
catalog table. Oid information is important if someone need make
relation with filename on disk
I updated FAQ_Solaris. I added new information related to Solaris 10,
rewrote optimalization hints and add information about dtrace. I talked
with Peter about Current maintainer role, and he said that this
information says anything and should be deleted.
Please, let me know your
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is this a good idea
Alvaro Herrera wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
I'm not able generate doc from sgml :( and verify if changes are ok :(.
1 - 100 of 116 matches
Mail list logo
