Ühel kenal päeval, R, 2007-10-19 kell 15:29, kirjutas Magnus Hagander:
On Thu, Oct 18, 2007 at 10:48:02AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
db=# alter table isi.items_stat drop constraint items_stat_item_id_fkey;
ERROR: items_pkey is an index
Pedro Belmino wrote:
4. Tried to attach the id of the process to the debugger and gave the error:
Unable to open socket file: target process not responding or HotSpot VM not
loaded
You're trying to use a Java debugger to attach to a non-Java program
(Postgres). That's not going to work. Use a
On Sat, Oct 20, 2007 at 09:24:07AM +0530, Gokulakannan Somasundaram wrote:
Hi,
I think i have a initial Implementation. It has some bugs and i am working
on fixing it. But to show the advantages, I want to show the number of
Logical I/Os on the screen. In order to show that, i tried enabling
Hi Hannu,
On 10/14/07 12:58 AM, Hannu Krosing [EMAIL PROTECTED] wrote:
What has happened in reality, is that the speed difference between CPU,
RAM and disk speeds has _increased_ tremendously
Yes.
which makes it even
more important to _decrease_ the size of stored data if you want good
On 10/2/06, Tom Lane [EMAIL PROTECTED] wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
However, the test right above that means that we'll fail if the user
tries something like row_variable := NULL;:
The patch you seem to have in mind would allow
row_variable := int_variable;
to
regression=# SELECT plainto_tsquery('the any');
NOTICE: query contains only stopword(s) or doesn't contain lexeme(s), ignored
plainto_tsquery
-
(1 row)
regression=# select ''::tsquery;
NOTICE: tsearch query doesn't contain lexeme(s):
tsquery
-
(1 row)
IMHO,
Those who have been with the community from long ago might remember
discussion about implementing a undo log. The big advantage of this is
that it allows UPDATE to _replace_ rows and limits the amount of cleanup
required for UPDATEs.
I am hoping that with HOT we will no longer have any need to
We have had very few beta1 issues. I am thinking we should release
beta2 next week and perhaps accelerate beta and consider a final release
in November rather than December. Because of the length of our feature
freeze it is possible we are not going to have as many beta bugs.
--
Bruce
Many community members were disappointed that feature freeze took so
long, but based on the number of features added to 8.3 our feature
freeze duration was similar to previous releases.
I think our only big mistake was setting expectation that this would be
a short feature freeze. We can be
A Diumenge 21 Octubre 2007, Bruce Momjian va escriure:
We have had very few beta1 issues. I am thinking we should release
beta2 next week and perhaps accelerate beta and consider a final release
in November rather than December. Because of the length of our feature
freeze it is possible we
Patch applied. Thanks.
---
Henry B. Hotz wrote:
I know I haven't been very active for a while here, but I just got to
testing the October 3 version a bit prior to getting back to the Java
GSS client stuff I
Bruce Momjian [EMAIL PROTECTED] writes:
We have had very few beta1 issues. I am thinking we should release
beta2 next week and perhaps accelerate beta and consider a final release
in November rather than December. Because of the length of our feature
freeze it is possible we are not going to
12 matches
Mail list logo
