Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the first step is to install the zic binary along the rest of
the stuff, so that a user without the source tree can compile the tzdata
package. Unless the compiled representation is portable, which I kinda
doubt?
Actually, it
Magne Mæhre wrote:
I was playing with a Nevada server and noticed a rush on the FPU
(the Nevada has a single shared FPU for its 32 threads).
Probably you mean Niagara ;-).
Zdenek
---(end of broadcast)---
TIP 1: if
Martijn van Oosterhout wrote:
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right? (Do we really want to
be able to psql -f a_pipe?)
Sure, why
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory doesn't complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right?
Martijn van Oosterhout napsal(a):
On Wed, Nov 14, 2007 at 09:33:17PM +0100, Zdenek Kotala wrote:
Sure, why not. To be honest I think that psql shouldn't be ignoring the
EISDIR error the kernel is returning.
But it works when you open directory in read-only mode. See posix
definition:
[EISDIR
Function AllocSetStats uses fprintf instead of standard logging method.
Is there any reason for it? If not I will rewrite it to use
elog(NOTICE,..) instead.
Zdenek
---(end of broadcast)---
TIP 9: In versions below 8.0, the
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Mark Mielke [EMAIL PROTECTED] writes:
Tom Lane wrote:
My goodness that's a hardware-dependent proposal. Shall we discuss
how many CPUs there are where an integer division is *slower* than
a floating-point op?
Do you have one in mind,
Tt seems that GCC makes decision do not inline this function and then it
will keep as a standard function. It is not problem and this warning is
generated by -Winline. I don't have this problem with GCC 3.4.3
Zdenek
Thomas Güttler wrote:
Hi,
I get the following compile warnings:
Tom Lane napsal(a):
Comments, opinions?
Is it time to remove old communication protocol support and cleanup code in 8.4?
Zdenek
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gevik Babakhani wrote:
After reading the thread of 2004 regarding user quotas, I understand
why the discussion moved towards having a tablespace quota as a
solution.
My reason to start this discussion was due the need of controlling
database size. Having tablespace quotas could allow one to
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I would like to make following modification:
1) Add ReadBuffer_noerror (recommend me better name) function which will
accept damaged page without Error. This page will be marked as corrupted
and when ReadBuffer will touch this page
Regarding to Robert Mach's work during Google SOC on data integrity
check. I would like to improve storage module and implement some
Robert's code into the core.
I would like to make following modification:
1) Add ReadBuffer_noerror (recommend me better name) function which will
accept
Peter Eisentraut wrote:
What about a feature to set a default tablespace just for indexes? I have
been told that this was originally proposed when tablespaces where designed,
but did not end up being implemented. Does anyone recall the details? I
have had people ask me about this feature.
Simon Riggs wrote:
On Fri, 2008-01-25 at 17:56 +0100, Zdenek Kotala wrote:
Regarding to Robert Mach's work during Google SOC on data integrity
check. I would like to improve storage module and implement some
Robert's code into the core.
I would like to make following modification:
1) Add
Gregory Stark napsal(a):
Simon Riggs [EMAIL PROTECTED] writes:
I wonder how hard it would be to shove the clog into regular shared memory
pages and let the clock sweep take care of adjusting the percentage of shared
mem allocated to the clog versus data pages.
I tried to use memory mapped
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I tried to use memory mapped files (mmap) for clog and I think it should be also
possible way. I got about 2% better performance, but it needs more testing.
If you only got 2% out of it, it's not even worth thinking about how to
fix
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
If you only got 2% out of it, it's not even worth thinking about how to
fix the serious bugs that approach would create (primarily, lack of
control over when pages can get flushed to disk).
You can flush a pages by msync
Gregory Stark napsal(a):
Bruce Momjian [EMAIL PROTECTED] writes:
You can flush a pages by msync() function which writes dirty pages on
disk. I don't see any other problem.
Then you need to learn more. The side of the problem that is hard to
fix is that sometimes we need to prevent pages from
Peter Eisentraut napsal(a):
Paul van den Bogaard wrote:
The SunStudio compiler we are using fortunately has an option for
this. Unfortunately there are restrictions. One restriction I face is
its inability to deal with ld -rs. These are used in the build
environment to create all the
Please, can you provide a test case? Which command does fail?
Thanks Zdenek
Vladimir Kokovic wrote:
Hi all,
I am using version 8.3.0 of the source and compiled it with next options:
PostgreSQL config.status 8.3.0
configured by ./configure, generated by GNU Autoconf 2.59,
with
Christopher Browne wrote:
On Feb 7, 2008 9:42 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
Gregory Stark escribió:
For what it's worth I think GIT is a better fit for our needs.
Perhaps it would be, if it worked on Windows ... Not that I care, but I
bet Magnus would.
Magnus Hagander wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner escribió:
yeah - the test install is available on
http://reviewdemo.postgresql.org if people want to test judge for
themself - contact magnus or me if you need permissions to do/test
stuff there.
Thanks. I tried
Tom Lane napsal(a):
snip
pg_time_t: only one-second resolution. Also, since this is typedef'd
as int64, the field-width problem comes right back to haunt us on
machines where INT64_IS_BROKEN. On the other hand, it's not clear
that there are any such machines anymore, and furthermore such a
I'm not sure, but maybe linker also needs a switch to make 32bit output.
Zdenek
Doug Knight napsal(a):
All,
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32, and I run the configure and make/make
install as follows:
setarch
Joshua D. Drake napsal(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:22:42 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that
our global settings are in a file seems unusual
Joshua D. Drake napsal(a):
Zdenek Kotala wrote:
I like this idea. By my opinion only GUC variable with PGC_POSTMASTER
context must be in postgresql.conf. Most of them are related to memory
and networking configuration. Other can be only store in database. And
for startup, default value
I'm now looking into toast code and I found following code in
pglz_decompress:
00704 if (destsize != source-rawsize)
00705 elog(destsize source-rawsize ? FATAL : ERROR,
00706 compressed data is corrupt);
I'm surprise why we there panic? By my opinion is not too good
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
I'm now looking into toast code and I found following code in
pglz_decompress:
00704 if (destsize != source-rawsize)
00705 elog(destsize source-rawsize ? FATAL : ERROR,
00706 compressed data is corrupt);
I'm surprise
Tom Lane napsal(a):
Alvaro Herrera [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
I'm now looking into toast code and I found following code in
pglz_decompress:
00704 if (destsize != source-rawsize)
00705 elog(destsize source-rawsize ? FATAL : ERROR,
00706
chris.jurado napsal(a):
Sorry for sending this directly to the hackers mailing list. But, i think it
did not belong in any other as it involves internals about the files in the
data directory.
PostgreSQL version: 8.1.2
Operating system: Windows XP/2003
The PostgreSQL service is not
I'm working on implementing pg_check functions. Because I want to test
whole table I need catch a error and handle it myself. I use following
construct:
PG_TRY();
{
...
ereport(ERROR, (errmsg(Error test)));
...
}
PG_CATCH();
{
errcontext(Context error);
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
PG_TRY();
{
...
ereport(ERROR, (errmsg(Error test)));
...
}
PG_CATCH();
{
errcontext(Context error);
EmitErrorReport();
FlushErrorState();
}
PG_END_TRY();
At the end I got following message:
ERROR
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
At the end I got following message:
ERROR: Error test
CONTEXT: Context error
server sent data (D message) without prior row description (T message)
I don't see anything wrong
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
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
Regarding to discussion about large segment size of table files a test
pathconf function (see
http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html).
You can see output there:
_PC_FILESIZEBITS - 3rd column
_PC_LINK_MAX - 4th column
_PC_NAME_MAX - 5th column
_PC_PATH_MAX
Reini Urban napsal(a):
cygwin 1.5 on NTFS. But 1.7 will a have much larger _PC_PATH_MAX.
_PC_FILESIZEBITS undefined _PC_LINK_MAX = 8 _PC_NAME_MAX = 260 _PC_PATH_MAX =
257
So this is really bad.
Thanks for reporting. It seems not good because postgreSQL assumes that
_PC_PATH_MAX
is minimal
Tom Lane napsal(a):
Alvaro Herrera [EMAIL PROTECTED] writes:
Neil Conway wrote:
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
Hmm, I mean just switching the default value in configure.in ... is
there anything else that needs doing at this point?
Well, that's
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
The result will be two datatypes datetime and timestamp_int or timestamp_float.
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue. It seems fairly
clear
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue.
I understand your arguments, but it is important for in-place upgrade
Tom Lane napsal(a):
Magnus Hagander [EMAIL PROTECTED] writes:
Another option then might be to simply deprecate their use, and
eventually get rid of them, instead of renaming them?
I'd like to get rid of ipcclean immediately; it hasn't had any usefulness
in years.
+1
The issue is larger
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
There's an awful lot of names here that don't have any obvious
connection to Postgres ...
Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same
output like pg_controldata. I think we can merge these commands.
Now
Andrew Dunstan napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Why we have pg_dump and pg_dumpall? Or I think pg_resetxlog has same
output like pg_controldata. I think we can merge these commands.
Now we're into change for the sake of change
Marc G. Fournier napsal(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, March 26, 2008 12:58:41 +0100 Zdeněk Kotala
[EMAIL PROTECTED] wrote:
Minimal me :-) and Solaris Architect committee have complain. Question is
also how many users really use these commands. For
Alif Isophoqote napsal(a):
Hi,
I am developing a backend module for postgresql. For some queries,
postgresql crashes: segmentation fault (most probably due to my own code).
How to get the function name line number where it crashes?
At first it depends on your OS. On unixes you should get
Heikki Linnakangas napsal(a):
Pavan Deolasee wrote:
/*
* We don't need to lock the page, as we're only looking at a single
bit.
*/
result = (map[mapByte] (1 mapBit)) ? true : false;
Isn't this a dangerous assumption to make ? I am not so sure that even
a bit
can be read
Pavan Deolasee napsal(a):
On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
can access to the same memory address(es)* in same time*. The question is
how compiler compile C code to assembler
I attached patch which add capability to reserve space on page for future
upgrade. It is mandatory for future in-place upgrade implementation. This patch
contains basic infrastructure not preupgrade script itself. I'm going to send
WIP preupgrade script today in separate mail.
This patch
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I attached patch which add capability to reserve space on page for
future upgrade. It is mandatory for future in-place upgrade
implementation. This patch contains basic infrastructure not
preupgrade script itself. I'm going to send WIP
Following commit:
http://archives.postgresql.org/pgsql-committers/2008-12/msg00109.php
breaks several farms. Is it know issue? I run test manually and it works.
Zdenek
Details:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2008-12-14%2021:06:00
I attached contrib module which is base of preupgrade script. It should be part
of 8.4, but it will be required for 8.4-8.5 upgrade.
This part contains space reservation for heap/toast relations. The idea is that
relation is read and each block is checked if there is enough free space. Tuples
What's about add second bit which mark frozen page (all tuples have freeze XID)?
It should avoid full scan, but extend size of map.
Zdenek
Heikki Linnakangas napsal(a):
The way VACUUM works with the visibility map is that if any pages are
skipped, relfrozenxid can't
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
BTree space reservation is more complicated.
Do you need to pre-reserve the space for b-tree? I think you can just
split it at upgrade, in the new version. The problem with doing
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
BTree space reservation is more complicated.
Do you need to pre-reserve the space for b-tree? I think you can just
split it at upgrade, in the new version. The problem with doing that for
heaps is that to move a heap tuple you need
Alvaro Herrera napsal(a):
ALTER TABLE foo SET (toast.autovacuum_enabled = false);
+1
Do not forget on toast index as well.
ALTER TABLE foo SET (toast_idx.fillfactor = 50);
Another potential problem with toast setting is that reloption is toastable and
it could generates loops in
Tom Lane napsal(a):
Zdenek Kotala zdenek.kot...@sun.com writes:
Another potential problem with toast setting is that reloption is toastable and
it could generates loops in detoasting pg_class tuples. For example toast chunk
size cannot be implement like reloption (or pg_class should use every
Alvaro Herrera píše v st 31. 12. 2008 v 12:54 -0300:
Maybe we could have a separate function which returned the info in
various columns (OUT params). Maybe it would be useful to normalize the
info as reported the buildfarm, which right now is a bit ad-hoc.
+1 it sounds good.
Zdenek
Bruce Momjian píše v st 31. 12. 2008 v 11:22 -0500:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
Maybe we should separate all that, e.g.,
Robert Haas píše v út 06. 01. 2009 v 12:38 -0500:
- WIP: Page space reservation (pgupgrade) is an idea that was
rejected, IIRC. pg_upgrade project status is more of the same thing.
there are several more pg_upgrade related items on here as well, most
of which are probably unnecessary.
space
Severals animals complain about PL check. It seems that problem is in
new messages format introduced in latest update:
http://archives.postgresql.org/pgsql-committers/2009-01/msg00188.php
Datails:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-01-15%2021:06:00
URL Links to changed files diff are broken in the buildfarm report. See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-01-15%2021:06:00
Links points to the:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpython/nls.mk?rev=1.2
instead of
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Guillaume Smet wrote:
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the
de facto policy is that we try to keep them passing in locales that
are used by any of the regular developers. I think it
Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200:
The remaining 80 failures are more-or-less linguistic issues that belong to
the following 26 language/country combinations:
cs_CZ sorts ch separately; sorts st = s
s st
Zdenek
--
Sent via pgsql-hackers mailing list
I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation when
all parameters are same for all relation kinds.
Zdenek
diff -Nrc pgsql_spacereserve.4cf1ae611238/src/backend/access/common/reloptions.c
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
Zdenek Kotala wrote:
I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation when
all parameters are same for all relation kinds.
Do you have an example use
Alvaro Herrera píše v pá 23. 01. 2009 v 11:14 -0300:
Zdenek Kotala wrote:
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
Zdenek Kotala wrote:
I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation
Andrew Dunstan píše v pá 23. 01. 2009 v 23:57 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple change
Tom Lane píše v pá 23. 01. 2009 v 10:19 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
Do you have an example use case for this?
I use it in my space reservation patch. I going to send it soon.
Haven't we been over that ground
I attached second version of space reservation patch. You can see first
version here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
I thought about Heikki'es comments and I removed all catalog changes,
because there are not necessary to be in pg_class. Instead of
pg_preugrade
The current project is not in good shape. Feature freeze is coming and
nothing is committed. Currently there are three patches in the game:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
Bruce Momjian píše v po 26. 01. 2009 v 23:02 -0500:
OK, time for me to chime in.
I think the outstanding commit-fest items can be broken down into four
sections:
o Log streaming
o Hot standby
o SE-PostgreSQL
o Others
You omit pg_upgrade. Does it mean that
Alvaro Herrera píše v út 27. 01. 2009 v 11:47 -0300:
Zdenek Kotala wrote:
2) pg_upgrade.sh
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00248.php
Pg_upgrade.sh is shell script for catalog conversion. It works for
8.3-8.4 upgrade.
What's the reason this script uses
Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
On 1/27/09, Zdenek Kotala zdenek.kot...@sun.com wrote:
This patch is mandatory for page online conversion and MUST TO be part
of postgreSQL 8.4. if not ... then we will be at the beginning next
year.
Just to clarify, does that mean
Robert Haas píše v út 27. 01. 2009 v 09:45 -0500:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
This patch is mandatory for page online conversion and MUST TO be part
of
Magnus Hagander píše v út 27. 01. 2009 v 15:54 +0100:
I have a hard time thinking that we'll have wasted a lot of time on
first doing a perl implementation if we have to rewrite it in C later.
The other way around would be a waste though. The amount of time spent
on the perl implementation
Dave Page píše v út 27. 01. 2009 v 14:56 +:
On Tue, Jan 27, 2009 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Dave Page wrote:
On Tue, Jan 27, 2009 at 2:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it's fairly easy to install Perl on Windows
Heikki Linnakangas píše v út 27. 01. 2009 v 21:07 +0200:
Zdenek Kotala wrote:
Robert Haas píše v út 27. 01. 2009 v 09:45 -0500:
1) Space reservation
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php
Heikki Linnakangas píše v út 27. 01. 2009 v 21:13 +0200:
Zdenek Kotala wrote:
Magnus Hagander píše v út 27. 01. 2009 v 15:54 +0100:
I have a hard time thinking that we'll have wasted a lot of time on
first doing a perl implementation if we have to rewrite it in C later.
The other way
Tom Lane píše v út 27. 01. 2009 v 14:31 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
Merlin Moncure píše v út 27. 01. 2009 v 09:47 -0500:
Just to clarify, does that mean that your patch has to be in for there
to be any chance of in-place upgrade 8.4-8.5?
Ok, There two patch
Heikki Linnakangas píše v út 27. 01. 2009 v 21:37 +0200:
Zdenek Kotala wrote:
Set general value for heap or btree is possible but not optimal. For
example If you have 5TB table and page layout changes do not affected
this table but some small table needs perform a cleanup then 5TB
Dave Page píše v út 27. 01. 2009 v 19:36 +:
On Tue, Jan 27, 2009 at 7:04 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Dave Page píše v út 27. 01. 2009 v 14:56 +:
I'd rather it was written in an appropriate language before feature
freeze, not in a language that makes it easier
Dave Page píše v út 27. 01. 2009 v 20:36 +:
On Tue, Jan 27, 2009 at 8:31 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Neither of which are the correct place to submit work for inclusion in
PostgreSQL.
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00990.php
I sent
Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got.
And we won't ever have, because it's
Tom Lane píše v st 28. 01. 2009 v 14:06 -0500:
Trying to do catalog upgrade
in-place is going to be a complete mess. I'd be interested to know,
for example, how you imagine rearranging the contents of pg_class would
work. You don't get to modify pg_class if you can't even find it, which
Bruce Momjian píše v st 28. 01. 2009 v 23:19 -0500:
I am stumped as well. In the 12 years I have been involved, there are
perhaps five issues that the original pg_upgrade written in 1998 didn't
handle, and mostly handles now. Considering the number of catalog
changes since 1998, the ratio
Tom Lane píše v st 28. 01. 2009 v 18:05 -0500:
Robert Haas robertmh...@gmail.com writes:
I really like this idea, assuming I understand it. Basically, I think
you're proposing that we move the old system catalogs out of the way,
bootstrap a new catalog, and then using SQL (running inside
Stefan Kaltenbrunner píše v čt 29. 01. 2009 v 18:29 +0100:
Peter Eisentraut wrote:
On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote:
well from a quick glance there is the bugzilla demo install as well as
pieces of reviewboard and patchwork on the trackerdemo jail.
So
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
The patch has two space reservations, one per page, another per tuple.
Now, thinking back, what types of changes have we made that increase
storage size. The one that I can think of
Andrew Dunstan píše v so 31. 01. 2009 v 17:08 -0500:
Zdenek Kotala wrote:
PL-check gives the diff below on PLTCL tests under en_US locale. I guess
the simplest answer is to add an alternative result file.
Yes, I thought about add locale suffix for alternative result file
Gregory Stark píše v pá 30. 01. 2009 v 16:56 +:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Zdenek Kotala wrote:
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Well, I was thinking the new pg_class column would allow the upgrade to
verify the pre-upgrade
Heikki Linnakangas píše v so 31. 01. 2009 v 21:56 +0200:
Robert Haas wrote:
Ofcourse, the simplest way to me for handling type changes seems to be
to keep the old type OID reserved and have the new version of the type
with a new OID. Then the entire problem vanishes. But it was decided a
Tested and it looks good.
See
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=gothic_mothbr=HEAD
thanks Zdenek
Andrew Dunstan píše v po 02. 02. 2009 v 11:34 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is problem
with other locales
The main speed improvement is for varchar datatype. I think It should be
mention here as well. IIRC, times are similar with B-Tree for integer
datatype.
Zdenek
Kenneth Marshall píše v st 04. 02. 2009 v 13:57 -0600:
I had submitted the documentation change as part of my
hash function
When we have now collation per database I think following comment is
useless:
* (2) this code is executed in the postmaster, so the setlocale() will
* propagate to forked backends, which aren't going to read this file for
* themselves. (These locale settings are considered critical
*
Tom Lane píše v ne 08. 02. 2009 v 11:51 -0500:
Now, if you want to argue that we should get rid of SET WITHOUT OIDS
altogether, I'm not sure I could dispute it. But if we have the
ability to do that ISTM we should offer the reverse too.
By my opinion TABLES with OIDs is obsolete feature. It
Peter Eisentraut píše v čt 12. 02. 2009 v 15:30 +0200:
I am not aware of any server changes needed for 8.3-8.4 migration.
OK, Zdenek, any concerns, or can we consider this chapter closed?
I think, that it is closed now. Space reservation will be backported if
we need it for 8.4-8.5. And
Tom Lane píše v pá 13. 02. 2009 v 16:54 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
I attached fix for regression tests and Czech locale. It is not complete
yet, because I fighting with foreign_data test. But it fix three other
tests.
As per buildfarm member gothic_moth
I try to fix foreign_data regression test for Czech locale (HEAD). For
example I replaced
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3,
4;
with following statement:
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2,
3::name, 4;
which should use C
501 - 600 of 699 matches
Mail list logo
