Kevin Grittner wrote:
How exactly do you expect the software to get from a .0 to a .1 release,
or to have addressed the bugs that might bite you when it does get to .1,
if you aren't helping to test it?
In most environments I've seen, developer and QA systems don't hesitate
to move to .0
On Mon, Oct 15, 2007 at 07:17:12PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Looks like dict-xsyn needs some windows install help for the rules file.
Ah, I was afraid of that :-(. The bespoke rule for installing that file
looked like trouble but I forgot about it
If I run the database under non-archiving mode, and execute the following
command:
alter table t set tablespace tblspc1;
Isn't it possible that the new t cann't be recovered?
---(end of broadcast)---
TIP 4: Have you searched our list
Jacky Leng wrote:
If I run the database under non-archiving mode, and execute the following
command:
alter table t set tablespace tblspc1;
Isn't it possible that the new t cann't be recovered?
No. At the end of copy_relation_data we call smgrimmedsync, which fsyncs
the new relation
On Mon, Oct 15, 2007 at 07:44:00PM +0200, Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. If it doesn't need a special case, then we still lack an
explanation for the aforementioned bug report.
From what I can tell that report
at the moment i am working on an application which is supposed to run
extremely large transactions (a lot of server side stored procedure
stuff which can hardly be split into small transactions for
visibility reasons).
so, from time to time it happens that i exceed my CommandCounter (
Hans-Juergen Schoenig wrote:
at the moment i am working on an application which is supposed to run
extremely large transactions (a lot of server side stored procedure
stuff which can hardly be split into small transactions for visibility
reasons).
so, from time to time it happens that i
Hans-Juergen Schoenig wrote:
at the moment i am working on an application which is supposed to run
extremely large transactions (a lot of server side stored procedure
stuff which can hardly be split into small transactions for visibility
reasons).
so, from time to time it happens that i
Heikki Linnakangas írta:
Hans-Juergen Schoenig wrote:
at the moment i am working on an application which is supposed to run
extremely large transactions (a lot of server side stored procedure
stuff which can hardly be split into small transactions for visibility
reasons).
so, from time to
AFAICS, maximum number of command ids is actually 2^32-1, or over 4
billion. Are you sure you bumped into that limit and not something
else?
What's the error message you're getting?
What version of Postgres is this? PG 8.3 will have another related
limit
on the number of combocids you can
Magnus Hagander [EMAIL PROTECTED] writes:
Do we expect there might be more like this? We could easily add a rule
to Install.pm to know about DICTFILES rules in addition to DATA
rules..
Yeah, after sleeping on it I think we need a general-purpose solution.
There are likely to be more not fewer
Although the new txid functions are very clean 1:1 interface
to the internal MVCC info and they don't need much docs
in that respect, their killer usage comes from the
possibility to query txids committed between 2 snapshots.
But how to do that (efficiently) is far from obvious when
just looking
There are a lot of incoming DST or TZ changes (Venezuela, Brazil,
Indiana...). Most hot is Indiana which will happen at 4th Nov.
http://www.worldtimezone.com/dst_news/dst_news_usa02.html
Is there any schedule to release new minor versions? It seems that new
Olson database is in CVS repository
On Tue, Oct 16, 2007 at 10:05:27AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Do we expect there might be more like this? We could easily add a rule
to Install.pm to know about DICTFILES rules in addition to DATA
rules..
Yeah, after sleeping on it I think we need a
Zdenek Kotala wrote:
There are a lot of incoming DST or TZ changes (Venezuela, Brazil,
Indiana...). Most hot is Indiana which will happen at 4th Nov.
http://www.worldtimezone.com/dst_news/dst_news_usa02.html
Is there any schedule to release new minor versions? It seems that new
Olson
Zdenek Kotala [EMAIL PROTECTED] writes:
There are a lot of incoming DST or TZ changes (Venezuela, Brazil, Indiana...).
Most hot is Indiana which will happen at 4th Nov.
Indiana is moving a few counties from one side of the line to another. The
rules for the zones themselves aren't changing, so
Magnus Hagander [EMAIL PROTECTED] writes:
DATA_TSEARCH seems better, it indicates where the files are going even
clearer.
Done.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian wrote:
Zdenek Kotala wrote:
There are a lot of incoming DST or TZ changes (Venezuela, Brazil,
Indiana...). Most hot is Indiana which will happen at 4th Nov.
http://www.worldtimezone.com/dst_news/dst_news_usa02.html
Is there any schedule to release new minor versions? It seems
Gregory Stark [EMAIL PROTECTED] writes:
Does the database acquire new timezones for these counties with the rule for
when they changed?
Historically that's been what the zic folks did anytime a region that
had been all one timezone rule diverged. I can't see any indication
in the current
[EMAIL PROTECTED] (Magnus Hagander) writes:
Re-allow UTF8 encodings on win32. Since UTF8 is converted to
UTF16 before being used, all (valid) locales will work for this.
So where do we stand on the Windows locale/encoding business --- are
we happy with the behavior now, or does it still need
Tom Lane wrote:
[EMAIL PROTECTED] (Magnus Hagander) writes:
Re-allow UTF8 encodings on win32. Since UTF8 is converted to
UTF16 before being used, all (valid) locales will work for this.
So where do we stand on the Windows locale/encoding business --- are
we happy with the behavior now, or
Hi.
Um, It seems that it only passed the strict check of chklocale.c. Probably, It may
enable mistaken selection...However, I will clarify a problem by the test.
Regards,
Hiroshi Saito
From: Magnus Hagander [EMAIL PROTECTED]
Tom Lane wrote:
[EMAIL PROTECTED] (Magnus Hagander) writes:
2007/10/16, Magnus Hagander [EMAIL PROTECTED]:
Tom Lane wrote:
[EMAIL PROTECTED] (Magnus Hagander) writes:
Re-allow UTF8 encodings on win32. Since UTF8 is converted to
UTF16 before being used, all (valid) locales will work for this.
So where do we stand on the Windows locale/encoding
Hi.
I can test it with czech locale. Can I download binaries anywhere?
http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs.tgz
It is a thing after regression test.(MinGW+gcc)
Regards,
Hiroshi Saito
---(end of broadcast)---
TIP 2: Don't 'kill -9'
Hi.
Um, It seems that it only passed the strict check of chklocale.c. Probably, It may
enable mistaken selection...However, I will clarify a problem by the test.
First, it is one problem
http://winpg.jp/~saito/pg83/pg83b1-err.txt
And a test continues
---(end
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS
locale)
And a test continues
Regards,
Hiroshi Saito
---(end of
Hello,
this proposal change older unaccepted proposal
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01157.php .
Changes:
* based on prepared statements
* syntax and behave is near to Oracle
* usable as protection from SQL injection
New syntax:
a) EXECUTE stringexpr
[INTO
Hiroshi Saito wrote:
Hi.
Um, It seems that it only passed the strict check of chklocale.c.
Probably, It may enable mistaken selection...However, I will clarify a
problem by the test.
First, it is one problem
http://winpg.jp/~saito/pg83/pg83b1-err.txt
And a test continues
But
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
And a test continues
What text search config would you expect?
Hi.
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
And a test continues
What text search config would you expect?
This
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
And a test continues
The changes that were made were only to re-enable
On 10/16/07, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello,
this proposal change older unaccepted proposal
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01157.php .
Compliance with PL/SQL
* You can use numeric, character, and string literals as bind arguments
* You cannot use
2007/10/16, Merlin Moncure [EMAIL PROTECTED]:
On 10/16/07, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello,
this proposal change older unaccepted proposal
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01157.php .
Compliance with PL/SQL
* You can use numeric, character, and
From: Dave Page [EMAIL PROTECTED]
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
And a test continues
The changes that
Hiroshi Saito wrote:
From: Dave Page [EMAIL PROTECTED]
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
And a test
Dave Page wrote:
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
And a test continues
The changes that were made were
Dave Page wrote:
Hiroshi Saito wrote:
From: Dave Page [EMAIL PROTECTED]
Hiroshi Saito wrote:
Hi.
Second, it is big problem
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
It is text serch config error.
However, It passes initdb.(locale=Japanese_Japan.932 ... This is
ShiftJIS locale)
Hi.
From: Dave Page [EMAIL PROTECTED]
Yes, Please see,
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
Is that initdb is successful a problem as for this?
Oh, sorry - misread that. I chatted with Magnus about that. It is
correct, but misleading. pg_control will say Japanese_Japan.932 as well
Magnus Hagander wrote:
Not so. The locale is Japanese_Japan, really. That's the only part
that's relevant for UTF16 encodings, which is what we use to do UTF8. We
specifically *don't* try to use Japanese_Japan.65001.
Thats not what I mean. From a *usability* perspective, Hiroshi should
see
Hiroshi Saito wrote:
Hi.
From: Dave Page [EMAIL PROTECTED]
Yes, Please see,
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
Is that initdb is successful a problem as for this?
Oh, sorry - misread that. I chatted with Magnus about that. It is
correct, but misleading. pg_control will say
But, Please see.
http://winpg.jp/~saito/pg83/pg83b1-err3.txt
Japanese_Japan.65001 is error...
Japanese_Japan is true.
However, The test of this state is continued.
But but but, Sorry, I face to a bed...
Regards,
Hiroshi Saito
---(end of
Dave Page wrote:
Magnus Hagander wrote:
Not so. The locale is Japanese_Japan, really. That's the only part
that's relevant for UTF16 encodings, which is what we use to do UTF8. We
specifically *don't* try to use Japanese_Japan.65001.
Thats not what I mean. From a *usability* perspective,
Hiroshi Saito wrote:
Hi.
From: Dave Page [EMAIL PROTECTED]
Yes, Please see,
http://winpg.jp/~saito/pg83/pg83b1-err2.txt
Is that initdb is successful a problem as for this?
Oh, sorry - misread that. I chatted with Magnus about that. It is
correct, but misleading. pg_control will say
Magnus Hagander wrote:
Dave Page wrote:
Magnus Hagander wrote:
Not so. The locale is Japanese_Japan, really. That's the only part
that's relevant for UTF16 encodings, which is what we use to do UTF8. We
specifically *don't* try to use Japanese_Japan.65001.
Thats not what I mean. From a
2007/10/16, Hiroshi Saito [EMAIL PROTECTED]:
Hi.
I can test it with czech locale. Can I download binaries anywhere?
http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs.tgz
It is a thing after regression test.(MinGW+gcc)
I have problem, there isn't libintl-2.dll
Pavel
Magnus Hagander [EMAIL PROTECTED] writes:
Dave Page wrote:
SJIS wasn't ever supported as a server encoding
(http://www.postgresql.org/docs/8.2/interactive/multibyte.html). The
fact that initdb continues if you use Japanese_Japan.932 is an
inconsistency I reported previously but has yet to be
On 10/17/07, Pavel Stehule [EMAIL PROTECTED] wrote:
New syntax:
a) EXECUTE stringexpr
[INTO [STRICT] varlist
[USING exprlist]
b) FOR varlist IN EXECUTE stringexpr USING exprlist LOOP
Just chiming in with a +1. I would find this feature very useful.
Substitution of
Hi.
From: Pavel Stehule [EMAIL PROTECTED]
I can test it with czech locale. Can I download binaries anywhere?
http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs.tgz
It is a thing after regression test.(MinGW+gcc)
I have problem, there isn't libintl-2.dll
Ooops, sorry, it is full-build.
Hi.
From: Magnus Hagander [EMAIL PROTECTED]
But, Please see.
http://winpg.jp/~saito/pg83/pg83b1-err3.txt
Japanese_Japan.65001 is error...
Japanese_Japan is true.
Yes, that is expected. If you explicitly ask for the .65001 locale it
will try the one that doesn't have the proper NLS files, and
49 matches
Mail list logo
