Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Does anyone actually read these?
LOG: database system was shut down at 2007-05-30 17:54:39 CEST
LOG: checkpoint record is at 0/42C4FC
LOG: redo record is at 0/42C4FC; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID:
On Wed, 2007-05-30 at 12:27 -0400, Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It'd be relatively painless to make that happen as part of the
deadlock-check timeout function, but that's typically only a one-second
delay not a few seconds.
On Tue, 2007-05-29 at 13:44 -0400, Bruce Momjian wrote:
We currently have processed 15 of the 40 patches in the patch queue
during our two months in feature freeze. Based on that progress, I
estimate we will enter beta in September.
Based upon that, do we think 8.4 feature freeze will be on
On Fri, 2007-06-01 at 10:33 +0200, Peter Eisentraut wrote:
Am Freitag, 1. Juni 2007 10:06 schrieb Simon Riggs:
Recovery considerations mean there can be more than one copy of a
database and it is important to be able to tell which one was just
started. The time a database was shutdown
On Wed, 2007-05-30 at 17:57 +0200, Peter Eisentraut wrote:
Does anyone actually read these?
LOG: database system was shut down at 2007-05-30 17:54:39 CEST
LOG: checkpoint record is at 0/42C4FC
LOG: redo record is at 0/42C4FC; undo record is at 0/0; shutdown TRUE
LOG: next transaction
Am Freitag, 1. Juni 2007 10:06 schrieb Simon Riggs:
Recovery considerations mean there can be more than one copy of a
database and it is important to be able to tell which one was just
started. The time a database was shutdown defines which copy we are
looking at.
No, the database identifier
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Our documentation says
| analyze threshold = analyze base threshold
| + analyze scale factor * number of tuples
| is compared to the total number of tuples inserted, updated, or deleted
| since the last ANALYZE.
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-05-29 at 13:44 -0400, Bruce Momjian wrote:
We currently have processed 15 of the 40 patches in the patch queue
during our two months in feature freeze. Based on that progress, I
estimate we will enter beta in September.
Based upon that, do
Dear All,
I am explaining here how i have defined the operators NEAR and NOT NEAR in my
research paper. I want critics/comments from all of you on the operators.
These operators belong to the category of “Fuzzy Operators” proposed in the
paper for ANSI SQL.
NEAR
It deals with the
Gregory Stark [EMAIL PROTECTED] writes:
hashany of a 4-byte value degenerates to pretty much just a call to mix().
Perhaps we should just expose a hash12() that takes three integers and calls
mix() on them like hash_any does.
I don't see any use for that, but probably there is a use in
On Mon, 2007-05-28 at 19:56 -0400, Bruce Momjian wrote:
Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php
I'm sorry guys but I don't agree this is a TODO item.
IMHO
Matthew T. O'Connor wrote:
Tom Lane wrote:
Yeah, I was concerned about that when I was making the patch, but didn't
see any simple fix. A large number of DELETEs (without any inserts or
updates) would trigger a VACUUM but not an ANALYZE, which in the worst
case would be bad because the
Gregory Stark wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
shared_buffers again was 32MB so all the data was in memory.
The case where all the data is in memory is simply not interesting. The cost
of TOAST is the random access seeks it
Zeugswetter Andreas ADI SD wrote:
It is good. It shows, that we even see a small advantage in the
everything cached case.
What we don't have yet is numbers for whether EXTERN_TUPLES_PER_PAGE=1
substantially increases the toast table size for real life scenarios,
what happens in the worst
Simon Riggs wrote:
On Mon, 2007-05-28 at 19:56 -0400, Bruce Momjian wrote:
Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php
I'm sorry guys but I don't agree this is a
Simon Riggs [EMAIL PROTECTED] writes:
I'm sorry guys but I don't agree this is a TODO item.
...
Also, methinks we should have agreed behaviour before we make something
a TODO item.
There is a whole *lot* of stuff in the TODO list that does not have a
consensus solution yet. You should not
Peter Eisentraut wrote:
The messages output by the scripts always seemed unnecessary to me, e.g.,
$ createdb foo
CREATE DATABASE
A Unix program (hi Magnus) shouldn't need to say anything if the requested
action succeeded.
I believe the history of this output is actually that these
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm sorry guys but I don't agree this is a TODO item.
...
Also, methinks we should have agreed behaviour before we make something
a TODO item.
There is a whole *lot* of stuff in the TODO list that does not have a
consensus solution
On Fri, 2007-06-01 at 20:06 +0200, Florian G. Pflug wrote:
Simon Riggs wrote:
On Mon, 2007-05-28 at 19:56 -0400, Bruce Momjian wrote:
Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
Mike Rylander wrote:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable
(or, in fact, unwilling) to upgrade to 8.3 for quite some time.
Because this patch is completely backward compatible it can
(theoretically)
Peter Eisentraut wrote:
The messages output by the scripts always seemed unnecessary to me, e.g.,
$ createdb foo
CREATE DATABASE
A Unix program (hi Magnus) shouldn't need to say anything if the requested
action succeeded.
I believe the history of this output is actually that these scripts
Peter Eisentraut wrote:
Mike Rylander wrote:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable
(or, in fact, unwilling) to upgrade to 8.3 for quite some time.
?Because this patch is completely backward
On 6/1/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Mike Rylander wrote:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable
(or, in fact, unwilling) to upgrade to 8.3 for quite some time.
Because this patch is
XML is now more stabilized in the backend than when the patch appeared,
and it doesn't make sense to add features to a /contrib interface that
is to be used only for backward compatability.
Patch rejected. You can put the patch on pgfoundry if you are worried
others might need this
Josh Berkus [EMAIL PROTECTED] writes:
Even if we had a semaphore of the sort you suggest, I doubt people would
want DROP DATABASE to wait indefinitely. The real question here is how
long is it reasonable for DROP DATABASE to wait before failing ...
10 to 15 seconds, I'd say. Is that going
On Fri, 2007-06-01 at 14:12 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm sorry guys but I don't agree this is a TODO item.
...
Also, methinks we should have agreed behaviour before we make something
a TODO item.
There is a whole *lot* of stuff in the TODO list that
Zdenek Kotala wrote:
And what about replace all scripts by one command e.g pg_cmd with
following interface:
pg_cmd create database ...
create role ...
drop database ...
list database
...
It solves potential name collision (for example createuser should
collide
Hello,
Assume the following:
index on: (id, adate)
constraint CHECK(adate '01-01-2007' AND adate '04-01-2007');
The planner will not use the index listed above. It does work if we have
an index on just timehit in addition to the above. (of course)
Is this expected?
Joshua D. Drake
P.S.
Joshua D. Drake [EMAIL PROTECTED] writes:
Assume the following:
index on: (id, adate)
constraint CHECK(adate '01-01-2007' AND adate '04-01-2007');
The planner will not use the index listed above.
For what?
regards, tom lane
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
And what about replace all scripts by one command e.g pg_cmd with
following interface:
pg_cmd create database ...
And we'll break a million applications that rely on the command names.
If you want that, it already exists:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Assume the following:
index on: (id, adate)
constraint CHECK(adate '01-01-2007' AND adate '04-01-2007');
The planner will not use the index listed above.
For what?
select adate from parent where adate = '01-25-2007'
For
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Assume the following:
index on: (id, adate)
constraint CHECK(adate '01-01-2007' AND adate '04-01-2007');
The planner will not use the index listed above.
For what?
select adate from
I have been looking at the syslogger code in connection with the CSV log
output proposal, and I'm quite concerned about the way it translates
every \n into \r\n for Windows output. This has several problems, not
least of which is that we can by no means assume that every \n has no
semantic
FYI, I am attending events in Italy, California, Pennsylvania, Finland,
and Russia in the next few months:
http://momjian.us/main/events.html
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been looking at the syslogger code in connection with the CSV log
output proposal, and I'm quite concerned about the way it translates
every \n into \r\n for Windows output.
...
My second thought is that we should quite possibly abandon this
Andrew Dunstan wrote:
I have been looking at the syslogger code in connection with the CSV log
output proposal, and I'm quite concerned about the way it translates
every \n into \r\n for Windows output. This has several problems, not
least of which is that we can by no means assume that
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Assume the following:
index on: (id, adate)
constraint CHECK(adate '01-01-2007' AND adate '04-01-2007');
The planner will not use the index listed above.
For what?
select
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been looking at the syslogger code in connection with the CSV log
output proposal, and I'm quite concerned about the way it translates
every \n into \r\n for Windows output.
...
My second thought is that we should quite
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
And what about replace all scripts by one command e.g pg_cmd with
following interface:
pg_cmd create database ...
And we'll break a million applications that rely on the command names.
Compatibility is
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on that. The problem of ensuring atomic output remains though
(see nearby complaints from George Pavlov and others).
Is that the one you suggested trying to fix by calling write() instead
of fprintf()? If so, I can't think of any
I wrote:
Kurt Harriman [EMAIL PROTECTED] writes:
Just noticed buffile.c:292 doesn't look quite right where
BufFileDumpBuffer calls FileWrite:
bytestowrite = FileWrite(thisfile, file-buffer, bytestowrite);
It looks as though it would write the same data each time the
loop is iterated. Would
Dropping -hackers; that list is for development of the database
engine itself.
The problem is that rules will happen before triggers, so what you're
trying to do will never work. Instead, just have the trigger insert
the data into the appropriate table.
On May 30, 2007, at 9:55 AM,
On Jun 1, 2007, at 1:58 AM, Michael Paesold wrote:
In case of recovery, I think one should still get the full output, no?
+1
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On May 31, 2007, at 1:32 AM, Zeugswetter Andreas ADI SD wrote:
However, it suddenly struck me that we could
probably make most of the problem go away if we put that same wait
into
DROP DATABASE itself --- that is, if we see other backends in the
target DB, sleep for a second or two and then
On Jun 1, 2007, at 8:24 AM, Tasneem Memon wrote:
NEAR
It deals with the NUMBER and DATE datatypes simulating the human
behavior and processing the
Why just number and date?
information contained in NEAR in the same way as we humans take it.
This is a binary operator with the syntax:
op1
Tom Lane wrote:
The other little problem (which is the reason we like the stderr
approach in the first place) is that not all the stderr output we want
to capture comes from code under our control. This may not be a huge
problem in production situations, since the main issue in my experience
Zdenek Kotala wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
And what about replace all scripts by one command e.g pg_cmd with
following interface:
pg_cmd create database ...
And we'll break a million applications that rely on the command names.
Sorry for my ignorance, but I haven't been able to keep up lately --
what is the difference between pg_detoast_datum_packed and
pg_detoast_datum, and how do I know when to use each? E.g. I notice that
the related macro PG_GETARG_TEXT_PP is used in place of PG_GETARG_TEXT_P
in many (but not
Jim Nasby [EMAIL PROTECTED] writes:
How about starting with 5 seconds and seeing if that takes care of
most situations?
Yeah, I came to that same conclusion ...
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00029.php
regards, tom lane
Andrew Dunstan [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
And what about replace all scripts by one command e.g pg_cmd with
following interface:
Well, I don't think rolling up the miscellaneous commands into a single
binary with behaviour dependent on arg[0] is a bad idea.
I don't
50 matches
Mail list logo
