Hi,
I am unable to restart the PostgreSQL. I am using redhat Linux 9
with postgresql 7.4.5. Unexpectedly due to ups problem my server was
shutdown once. After that i am unable to restart the server. How to
stop and start.
Present status is running. If i tried to start i am getting as
1) bash-
Tom Lane wrote:
Looking at the code, it appears that the java call handler *has* been
called once,
indeed. Obviously I didn't pay too much attention to the trace.
and what it returned was a tuple that didn't carry any
type identification. This is probably because you didn't call
BlessTupleDesc. n
Hi,
I hope its not off topic.
I have an algorithm to implement where it needs
to hold the tuples (complete tuples - all columns)
either in a b+tree or a hashtable.
I am concerned about the space such an index will require.
What is the difference in percentages from the size of all
the data not inde
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. I think this is not your bug. Is the call coming from
>> evaluate_function in clauses.c? We need to either prevent that from
>> pre-evaluating a function returning RECORD, or fix it so it can pass
>> the expected tuple descrip
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:
> Well, I've re-run the checks several times after a clean make and it
> does not crash anymore. So the patch seems to help !
Thought it might ;-)
> Please consider applying it.
Done.
regards, tom lane
---
Le 12 avr. 05, à 08:23, Rémi Zara a écrit :
Hi,
With the following patch, the crash still occurs in the same way. But
it does seem, reading the code, that it still may be necessary.
Well, I've re-run the checks several times after a clean make and it
does not crash anymore. So the patch seems to
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So there's no comments saying "here's a useful function written using this
> > function" or "watch out for this common bug" or "if what you want to do is
> > this you might want to check out this other function" or any of the
> > thousands
> > of sim
On Thu, Apr 14, 2005 at 03:01:10PM -0400, Greg Stark wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > On Thu, Apr 14, 2005 at 01:39:11PM -0400, Greg Stark wrote:
> >
> > > I think the idea of moderating the comments is inherently flawed. You can
> > > either have the deliberate, planned
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Apr 14, 2005 at 01:39:11PM -0400, Greg Stark wrote:
>
> > I think the idea of moderating the comments is inherently flawed. You can
> > either have the deliberate, planned documentation without the comments, or
> > you
> > can have the wild-we
The comments in the PHP docs, while they contain a lot of garbage also contain
a lot of helpful tips and warnings. There's hardly any in the Postgres docs.
If it were I, we would start a wiki that was linked from the docs but
not have the docs
themselves have the comments.
I think the idea of
On Thu, Apr 14, 2005 at 01:39:11PM -0400, Greg Stark wrote:
> I think the idea of moderating the comments is inherently flawed. You can
> either have the deliberate, planned documentation without the comments, or you
> can have the wild-west style comments system, but trying to have it both ways
>
"Dave Page" writes:
> We can get from 2 - 10 a day I would guess. They get mailed to a closed
> list for moderation.
Uhm, then where are they?
The comments in the PHP docs, while they contain a lot of garbage also contain
a lot of helpful tips and warnings. There's hardly any in the Postgres do
On Thu, 2005-04-14 at 12:10 -0400, Tom Lane wrote:
> The first of these should of course force a btree split on the first
> page each time it splits, while the second will involve the
> probabilistic moveright on each split. But the files will be exactly
> the same size.
>
> [EMAIL PROTECTED] ~]$
I wrote:
> So the theory does work, at least for small index entries. Currently
> repeating with wider ones ...
I tried the same test with the row width extended to 100 characters and
then 500 characters. The runtime and number of _bt_compare calls is
still about the same for the all-different-k
On Thu, Apr 14, 2005 at 11:54:56AM -0400, Robert Treat wrote:
> On the PostgreSQL front, Tom has in the past gone through comments
> around release time and integrated in the relevant changes; I've also
> submitted a patch or two based on suggestions that have come across
> since we got the new sy
Just to check if I was nuts or not, I made up a test case:
create table foo (f1 text);
create index fooi on foo(f1);
then
truncate foo;
copy foo from stdin;
99
98
97
... one million rows ...
02
01
00
\.
versus
truncate foo;
copy foo from stdin;
x
On Thu, 2005-04-14 at 03:56, Dave Page wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Greg Stark
> > Sent: 14 April 2005 04:54
> > To: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Interactive docs idea
> >
> > Alvaro
On Thu, 2005-04-14 at 11:15 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > The move right only occurs when the page is full, so the chance of
> > moving right is not 0.99^250, but 0.99, since the previous 249 inserts
> > would not cause a page split.
>
> Sure, but given that
Simon Riggs <[EMAIL PROTECTED]> writes:
> The move right only occurs when the page is full, so the chance of
> moving right is not 0.99^250, but 0.99, since the previous 249 inserts
> would not cause a page split.
Sure, but given that we have a full page, the probability that 250
successive insert
On Thu, 2005-04-14 at 10:35 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Recent discussions on PERFORM have made me look into some aspects of
> > B-tree index code, especially with regard to bulk loading high volumes
> > of data.
>
> Have you read the archived discussions
Simon Riggs <[EMAIL PROTECTED]> writes:
> Recent discussions on PERFORM have made me look into some aspects of
> B-tree index code, especially with regard to bulk loading high volumes
> of data.
Have you read the archived discussions that led up to the current
algorithm? I don't think it's nearl
Recent discussions on PERFORM have made me look into some aspects of
B-tree index code, especially with regard to bulk loading high volumes
of data.
I now have cause for concern about the way that Btree index code
currently works when inserting large volumes of data into a table with
non-unique i
Christopher Kings-Lynne wrote:
It seems that's not much of a danger -- the interactive Postgres
documentation
hardly gets any comments at all in the first place. It would be a big
improvement if there were some way to encourage many more comments.
Only link to the version with comments.
No than
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Greg Stark
> Sent: 14 April 2005 04:54
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Interactive docs idea
>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > I think it's an interes
24 matches
Mail list logo
