Hi,
7.4beta4 is still mentioned in INSTALL.
Tommi
Am Mittwoch, 22. Oktober 2003 16:21 schrieb Marc G. Fournier:
> 'K, I packaged it up last night so that the ftp mirrors could get up to
> date on it ... I'm going to put out an announce to -general and -announce
> on this later this evening, but
Hi,
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
"postmaster successfully started", after a fatal error, which looks very
confusing. When I use -l for specifying a logfile, I don't even see th
On Wednesday 22 October 2003 20:12, scott.marlowe wrote:
> On Wed, 22 Oct 2003, Tom Lane wrote:
> > It would probably be a good idea to allow the function's search path to
> > be explicitly specified as a clause of CREATE FUNCTION (otherwise it
> > will be a headache for pg_dump). So we could allo
>
> On Wednesday 22 October 2003 07:37, Neil Conway wrote:
> > The second audience is the people who are really interested in exactly
> > what has changed between the new release of PostgreSQL and the previous
> > release series. It is important that we make it easy for an admin
> > planning a Pos
On Friday 24 October 2003 00:01, Christoph Haller wrote:
>
> A pg_compat_chk utility sounds great.
> No idea, if this is practical, but it's desirable - at least to me.
Well, I'm confident the first 90% is practical just by running some regexps
against a pg_dumped schema. It doesn't need to guara
Rod Taylor wrote:
On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:
There is always the biggest evil of all... Putting SHOW / DESCRIBE /
HELP commands into the backend itself. I'm sure the pgAdmin group likes
that idea (they're probably tired of maintaining 4 different versions of
que
On Wed, 22 Oct 2003, Christopher Browne wrote:
> No, "tables" wouldn't be the right way to do it.
>
> But it's going to be troubled, in any case, because of the
> every-popular mixtures of:
>
> a) Often weird declarations of what character sets are in use;
I gotta admit that I haven't spend too mu
> -Original Message-
> From: Bruce Momjian
...
> The big question is whether the current release notes hit he right
> balanced. Do they for you?
The last time I read the notes was when we upgraded to 7.3.4.
I'll pick up couple entries from Release Notes and the HISTORY file
(which we alw
On Thu, 23 Oct 2003, Christopher Kings-Lynne wrote:
> 4. Extend the contrib/ltree gist-based tree indexing scheme to work on
> xml and hence the operations in no.3 above are really fast...
but then, the plain xml data is still stored in a database colum, if I
understand correctly?
--
Gregor Zeitl
On Wed, 22 Oct 2003, Josh Berkus wrote:
> Reinvent the wheel? Well, yes.
>
> The first thing ... the VERY first thing, abosolutely ... that you need to do
> is invent a theory of XML databases.
Well, I have. It doen't cover all parts in detail yet, because I've
started with a simple IO layer (simp
Storing the XML text has problems - you have to parse it every time you
want something - that has to cause a huge performance hit.
I use XML a lot for all sorts of purposes, but it is appropriate for
data transfer rather than data storage, IMNSHO.
cheers
andrew
Christopher Kings-Lynne wrote:
On Thu, 23 Oct 2003, Andrew Dunstan wrote:
> Storing the XML text has problems - you have to parse it every time you
> want something - that has to cause a huge performance hit.
You couldn't have said better what I meant.
I store the xml already parsed. You can navigate right along. To the
parent,
> >Nay... I would expect a PostgreSQL specific information_schema to get
> >just as much mucking around as the system tables, which means you are
> >still maintaining a set of queries per release.
> >
> >
> The problem about information_schema is that it's restricted to show
> objects of the own
4. Extend the contrib/ltree gist-based tree indexing scheme to work on
xml and hence the operations in no.3 above are really fast...
but then, the plain xml data is still stored in a database colum, if I
understand correctly?
Yep - which to me seems to be the most useful way to store it :)
Chris
You couldn't have said better what I meant.
I store the xml already parsed. You can navigate right along. To the
parent, the previous, the next elemnt or the first or last child.
Which is the whole point of indexing it...
I use XML a lot for all sorts of purposes, but it is appropriate for
data tr
> *nod* I have tried this several times - it just doesn't work well,
> because the maps are too different.
>
> You could do something like this:
>. a table for each element type, fields being the attributes, plus
> the node id.
>. a table to tie everything together (parent_id, child_id,
Tommi Maekitalo <[EMAIL PROTECTED]> writes:
> I installed 7.4beta5, created a data-dir and tried to start postgresql with
> pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
> "postmaster successfully started", after a fatal error, which looks very
> confusing. When I use -
On Thu, 23 Oct 2003, Christopher Kings-Lynne wrote:
> > You couldn't have said better what I meant.
> > I store the xml already parsed. You can navigate right along. To the
> > parent, the previous, the next elemnt or the first or last child.
>
> Which is the whole point of indexing it...
not quite
Gregor,
> Well, I have. It doen't cover all parts in detail yet, because I've
> started with a simple IO layer (simple page locking, no concurrent
> transactions) and worked on the page layout and parsing algorithms from
> there on. Querying on that format will follow thereafter. And concurrency
>
If you don't use -w, then pg_ctl doesn't wait around to see whether the
postmaster started or not. It'd probably be a good idea for it to issue
a less positive message in this case, maybe only "postmaster launched".
I also wonder why -w isn't the default.
I've also noticed that on our production 7
Tom Lane wrote:
Tommi Maekitalo <[EMAIL PROTECTED]> writes:
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
"postmaster successfully started", after a fatal error, which looks very
confusing.
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I've also noticed that on our production 7.3.4 server logging to syslog,
> that if I change the postgresql.conf to enable log_statement, and then
> do pg_ctl reload, it works, but then when I disable it again, pg_ctl
> reload does not cause p
On Thu, 23 Oct 2003, Josh Berkus wrote:
> Um, I/O and Page layout are not theory. They are implementation issues.
yes or no, depending on your point of view.
> Theory would answer things like "What are the mathematical operations I can
> use to define compliance or non-compliance with the DTD fo
By "disable" do you mean "turn off", or "comment out again"? The latter
is not going to affect the state of the postmaster ...
The latter...why won't it affect the postmaster state?
Chris
---(end of broadcast)---
TIP 6: Have you searched our list
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> By "disable" do you mean "turn off", or "comment out again"? The latter
>> is not going to affect the state of the postmaster ...
> The latter...why won't it affect the postmaster state?
Because it's a *comment*.
reg
The latter...why won't it affect the postmaster state?
Because it's a *comment*.
Shouldn't it revert to the default value?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Michael Brusser wrote:
> > -Original Message-
> > From: Bruce Momjian
> ...
> > The big question is whether the current release notes hit he right
> > balanced. Do they for you?
>
> The last time I read the notes was when we upgraded to 7.3.4.
> I'll pick up couple entries from Release N
Tommi Maekitalo wrote:
> Hi,
>
> 7.4beta4 is still mentioned in INSTALL.
Oh, I didn't realize the beta number was in the install. I just updated
it, and we will have the right numbers in the for final.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >Tommi Maekitalo <[EMAIL PROTECTED]> writes:
> >
> >
> >>I installed 7.4beta5, created a data-dir and tried to start postgresql with
> >>pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
> >>"postmaster successfully started", af
Tom Lane wrote:
> Tommi Maekitalo <[EMAIL PROTECTED]> writes:
> > I installed 7.4beta5, created a data-dir and tried to start postgresql with
> > pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
> > "postmaster successfully started", after a fatal error, which looks very
>
Bruce Momjian wrote:
OK, I updated the Win32 web page to mention we need a C version of
pg_ctl. I don't think we will need pg_config once we have initdb in C,
and I don't think it is worth doing initlocation because we need
tablespaces.
I will put it on my todo list (should be simpler than initdb
"Bob Badour" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> All physical structures will bias performance for some operations and
> against others.
This strikes me as a succinct statement of the value of
data independence. One has the option (but not the
requirement) to adjust the
"Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Anthony W. Youngman wrote:
>
> >In article <[EMAIL PROTECTED]>, Lauri Pietarinen
> ><[EMAIL PROTECTED]> writes
> >
> >
> >>Anthony W. Youngman wrote:
> >>
> >>
> >>
> >>>Fine. But MV *doesn't* *need* much of a cache.
"Anthony W. Youngman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> As soon as a requirement for a database specifies extraction of the
> maximum power from the box,
I don't for a second believe that this is your only requirement,
or that this is even an actual requirement. If it
"Anthony W. Youngman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Just like the academics were
> brainwashed into thinking that microkernels were the be-all and end-all
> - until Linus showed them by practical example that they were all idiots
"The academics" (presumably you mean
Anthony W. Youngman wrote:
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
<[EMAIL PROTECTED]> writes
Anthony W. Youngman wrote:
Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
MV have the same amount of RAM to cache in - i.e. *not* *much*. I did
say the spec sai
"Marshall Spight" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Bob Badour" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >
> > All physical structures will bias performance for some operations and
> > against others.
>
> This strikes me as a succinct statement of t
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
<[EMAIL PROTECTED]> writes
>Anthony W. Youngman wrote:
>
>>
>>Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
>>MV have the same amount of RAM to cache in - i.e. *not* *much*. I did
>>say the spec said "extract maximum perfor
Hi!
I'm doing a select (from an OACS page or from psql) and I get:
ERROR: Failed to create temporary file pgsql_tmp/pgsql_tmp27212.775
The same select work ok a different database (which is on a different
machine)
the select is :
select a.attribute_id, a.pretty_name,
a.ancestor_type,
Sounds like your drives are full.
On Thu, 23 Oct 2003, Yuval Lieberman wrote:
> Hi!
>
> I'm doing a select (from an OACS page or from psql) and I get:
> ERROR: Failed to create temporary file pgsql_tmp/pgsql_tmp27212.775
>
> The same select work ok a different database (which is on a different
Marshall Spight kirjutas N, 23.10.2003 kell 11:01:
> "Anthony W. Youngman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> > Just like the academics were
> > brainwashed into thinking that microkernels were the be-all and end-all
> > - until Linus showed them by practical example that
I'm seeing on the log file:
LOG: duration: 0.024814 select now();
Am I wrong or we agree to have:
LOG: duration: 24.81 ms select now();
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 6: Have you searched our list archives?
ht
Gaetano Mendola wrote:
> I'm seeing on the log file:
>
> LOG: duration: 0.024814 select now();
>
> Am I wrong or we agree to have:
>
> LOG: duration: 24.81 ms select now();
I think you are pointing to the wrong version --- I see:
LOG: duration: 0.998 ms statement: select 1;
--
Bruce Momjian wrote:
I think you are pointing to the wrong version --- I see:
LOG: duration: 0.998 ms statement: select 1;
I'm a dummy, I forgot to do gmake install
after have compiled the last beta :-(
yes you're right.
Regards
Gaetano Mendola
---(end of broadcast
Hello
This is my first time to
post.
I
have several questions.
Currently,
there is Postgresql for ia64.
I
was wondering, previous version was optimized for ia64 or just
converted.
Now
I am looking for some way to optimize postgresql especially for ia64
machine.
(thinking
about mod
Satoshi, can you get this ready for inclusion in 7.5? We need a formal
proposal of how it will work from the user's perspective (new
commands?), and how it will internally work. It seem Heikki Linnakangas
has also started working on this and perhaps he can help.
Ideally, we should have this pro
Bruce,
Ok, I will write my proposal.
BTW, my 2PC work is now suspended because of my master thesis.
My master thesis will (must) be finished in next few months.
To finish 2PC work, I feel 2 or 3 months are needed after that.
Bruce Momjian wrote:
> Satoshi, can you get this ready for inclusion i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Michael Brusser wrote:
>
> > Optimizer improvements
> > => this tells me nothing. I suppose this could be a minor internal code
> > tweak, which does not affect me. On the other hand this could be a major
> > breakthrough, so now I can run some stupid q
I am not sure we should add something to the SET CONSTRAINT page on
this. Our current behavior is clearly a bug, and for that reason
belongs more on the TODO list, where it already is:
* Have AFTER triggers execute after the appropriate SQL statement in a
function, not
Satoshi Nagayasu wrote:
> Bruce,
>
> Ok, I will write my proposal.
>
> BTW, my 2PC work is now suspended because of my master thesis.
> My master thesis will (must) be finished in next few months.
>
> To finish 2PC work, I feel 2 or 3 months are needed after that.
Oh, OK, that is helpful. Perh
Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Michael Brusser wrote:
> >
> > > Optimizer improvements
> > > => this tells me nothing. I suppose this could be a minor internal code
> > > tweak, which does not affect me. On the other hand this could be a major
> > > breakthrou
I can confirm this bug in CVS.
---
Rod Taylor wrote:
-- Start of PGP signed section.
> May have posted this earlier...
>
> It would seem that caching the plans for foreign keys has some unwanted
> side effects.
>
>
> tes
On Fri, 24 Oct 2003, Bruce Momjian wrote:
> I am not sure we should add something to the SET CONSTRAINT page on
> this. Our current behavior is clearly a bug, and for that reason
> belongs more on the TODO list, where it already is:
Had it been on the SET CONSTRAINT page, it would have saved me
hi:in allpath.c ,the
set_plan_rel_pathlist() function has a parameter of RangeTblEntry type.what
does we use this varaible to do ?i doesn't see any code in this function
using it .In optimizer module, it look like that we can get
most information from Query . Is it right ?so , what time us
Curt Sampson wrote:
> On Fri, 24 Oct 2003, Bruce Momjian wrote:
>
> > I am not sure we should add something to the SET CONSTRAINT page on
> > this. Our current behavior is clearly a bug, and for that reason
> > belongs more on the TODO list, where it already is:
>
> Had it been on the SET CONSTR
On Fri, 24 Oct 2003, Bruce Momjian wrote:
> Does it belong on the SET CONSTRAINT page, the CREATE TABLE page, or the
> CREATE FUNCTION page?
Hard to say. Possibly all three. I'd defer to your judgement on
this. I'd say I have a slight preference for putting it on the SET
CONSTRAINT and CREATE FUN
56 matches
Mail list logo
