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: 0
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
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 o
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 transacti
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 identifi
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 upo
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 NUMBER
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 has
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.
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
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
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 wor
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 T
"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 n
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
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
> conse
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
> >>
> >> http://archives.postgre
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
> (theoreticall
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
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 functionality
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
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 TOD
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
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 alre
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 ex
"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 w
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 si
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
+ I
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
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?
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 pos
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 po
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
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 it
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, Enrico
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 re
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
i
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 all)
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
50 matches
Mail list logo
