Hi,
how long is PG7.1 already in beta testing? can it be released before Christmas day?
can PG7.1 will recover database from system crash?
Thanks,
XuYifeng
I don't believe it's a performance issue, I believe it's that
writes to
blocks greater than 8k cannot be guaranteed 'atomic' by the operating
system. Hence, 32k blocks would break the transactions system. (Or
something like that - am I correct?)
First, 8k are not atomic eighter. Second,
8k is the standard Unix file system disk transfer size.
Are you sure ? I thought it was 4k on AIX and 2k on Sun.
Andreas
b) Check out MSSQL 7's capabilities and weep.
BTW, have you studied MSSQL enough to tell me if it has a
separate/standalone
(as a process) fti engine or just another index type.
It is standalone - separate process, data is stored in separate files (not
in db).
In SQL Server 7.0, you
The pg_options.sample that is included in 7.0.x cannot actually be used
because of bugs in the routine that reads it. First, it reads only 4095
bytes and second it does not cope with white space within lines. The
attached patch cures the problem.
It seems to be relevant only to 7.0.x because
Thomas Lockhart [EMAIL PROTECTED] writes:
select ('today', interval '1 day') OVERLAPS ('yesterday', interval '18
hours');
(the second one fails). Now that I look, this breakage was introduced in
March when "we" expunged operators allowed as identifiers (Tom Lane and
I have blood on our
At 04:17 PM 11/28/00 +0800, xuyifeng wrote:
Hi,
how long is PG7.1 already in beta testing? can it be released before Christmas day?
can PG7.1 will recover database from system crash?
This guy's a troll from the PHP Builder's site (at least, Tim Perdue and I suspect this
due to some posts
At 09:59 AM 11/28/00 +, Pete Forman wrote:
Mario Weilguni writes:
This gets really bad when the actual data is coming from a
webinterface, I've to handle 2 different queries for the case empty
string and non-empty string.
In their documentation both Oracle 7 and 8 state:
Oracle
At 02:18 PM 11/28/00 +0800, Christopher Kings-Lynne wrote:
As for the treading-on-user-namespace issue, we already do that for all
implicitly created indexes (see UNIQUE, PRIMARY KEY, etc). I'd prefer
to treat named constraints consistently with that long-established
practice until we have a
no doubt, I have touched some problems PG has, right? if PG is so good,
is there any necessary for the team to improve PG again?
Regards,
XuYifeng
- Original Message -
From: Don Baccus [EMAIL PROTECTED]
To: xuyifeng [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, November 28,
Browsing through backend/commands/command.c I noticed the following code:
if (indexStruct-indisunique)
{
List *attrl;
/* go through the fkconstraint-pk_attrs list */
foreach(attrl, fkconstraint-pk_attrs)
{
Ident *attr=lfirst(attrl);
This is a summary of replies.
1. Calculated fields in table definitions . eg.
Create table test (
A Integer,
B integer,
the_sum As (A+B),
);
This functionality can be achieved through the use of views.
Using a view for this
I guess it depends on what you're using it for -- disk space is cheap and
abundant anymore, I can see some advantages of having it computed only once
rather than X times, where X is the number of SELECTs as that could get
costly on really high traffic servers.. Costly not so much for simple
On Tue, 28 Nov 2000, xuyifeng wrote:
you are complete wrong, if I don't like PG, I'll never go here or talk
anything about PG, I don't care it. I just want PG can be improved
quickly, for me crash recover is very urgent problem, otherewise PG is
forced to stay on my desktop machine, We'll
On Tue, 28 Nov 2000, Hannu Krosing wrote:
xuyifeng wrote:
I just noticed this conversation so I have not followed all of it,
but you seem to have strange priorities
I just want PG can be improved quickly, for me crash recover is very urgent
problem,
Crash avoidance is usually
So, having _both_ is the best thing.
Absolutely, that's always what I meant -- we already have views and views
can do this type of stuff at SELECT time can't they? So it's not a change,
just an addition
-Mitch
This is one of the not-so-stomped boxes running PostgreSQL -- I've never
restarted PostgreSQL on it since it was installed.
12:03pm up 122 days, 7:54, 1 user, load average: 0.08, 0.11, 0.09
I had some index corruption problems in 6.5.3 but since 7.0.X I haven't
heard so much as a peep from
Tom Lane writes:
template1=# select ('today', interval '1 day') OVERLAPS ('yesterday', interval
'18 hours');
ERROR: parser: parse error at or near "overlaps"
I don't understand why we're getting a parse error here ...
The OVERLAPS special SQL-construct is converted into the 'select
To fix this you simply need to double-quote "overlaps" when it's used as a
straight function call. See how substring does it in pg_proc.h.
Hmm. Why was this required for the substring() example? afaik all of
this should be handled (correctly) in the grammar...
- Thomas
On Tue, Nov 28, 2000 at 12:38:37AM -0500, Tom Lane wrote:
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
I don't believe it's a performance issue, I believe it's that writes to
blocks greater than 8k cannot be guaranteed 'atomic' by the operating
system. Hence, 32k blocks would break
On Tue, Nov 28, 2000 at 04:24:34PM -0500, Tom Lane wrote:
Nathan Myers [EMAIL PROTECTED] writes:
In the event of a power outage, the drive will stop writing in
mid-sector.
Really? Any competent drive firmware designer would've made sure that
can't happen. The drive has to detect power
On 25 Nov 2000, at 17:35, Tom Lane wrote:
So, I began restarting pgsql w/a line like
rm -f /tmp/.PGSQL.* postmaster -i log 2log
Which works great. Except that I *kept* using this for two weeks
after the view problem (damn that bash up-arrow laziness!), and
yesterday, used it
BTW, it compiles fine on UnixWare 7.1.1
* Larry Rosenman [EMAIL PROTECTED] [001128 19:36]:
The last batch of commits break on FreeBSD 4.2-STABLE.
$ uname -a
FreeBSD lerbsd.lerctr.org 4.2-STABLE FreeBSD 4.2-STABLE #90: Tue Nov
28 04:07:50 CST 2000
[EMAIL
NO, I just tested how solid PgSQL is, I run a program busy inserting record into PG
table, when I
suddenly pulled out power from my machine and restarted PG, I can not insert any
record into database
table, all backends are dead without any respone (not core dump), note that I am
using
Tom Samplonius wrote:
On Tue, 28 Nov 2000, mlw wrote:
Tom Samplonius wrote:
On Mon, 27 Nov 2000, mlw wrote:
This is just a curiosity.
Why is the default postgres block size 8192? These days, with caching
file systems, high speed DMA disks, hundreds of megabytes of
Assuming the silence is agreement, does this look like the right solution
(I assume looping through the index is the only way to count the segments):
if (indexStruct-indisunique)
{
List *attrl;
/* go through the fkconstraint-pk_attrs list */
foreach(attrl,
On Mon, Nov 27, 2000 at 04:09:46PM -0500, Tom Lane wrote:
Cyril VELTER [EMAIL PROTECTED] writes:
Unfortunatly, there is no hard link on beos :=(. link and unlink are
there, but link always return "No such file or directory".
Somewhere right around here is where I am going to ask why
Larry Rosenman [EMAIL PROTECTED] writes:
The last batch of commits break on FreeBSD 4.2-STABLE.
/usr/include/machine/lock.h:148: conflicting types for `s_lock'
../../../src/include/storage/s_lock.h:402: previous declaration of `s_lock'
That's odd. s_lock has been declared the same way right
* Tom Lane [EMAIL PROTECTED] [001128 22:31]:
Larry Rosenman [EMAIL PROTECTED] writes:
The last batch of commits break on FreeBSD 4.2-STABLE.
/usr/include/machine/lock.h:148: conflicting types for `s_lock'
../../../src/include/storage/s_lock.h:402: previous declaration of `s_lock'
* Larry Rosenman [EMAIL PROTECTED] [001128 22:33]:
* Tom Lane [EMAIL PROTECTED] [001128 22:31]:
Larry Rosenman [EMAIL PROTECTED] writes:
The last batch of commits break on FreeBSD 4.2-STABLE.
/usr/include/machine/lock.h:148: conflicting types for `s_lock'
* Tom Lane [EMAIL PROTECTED] [001128 22:31]:
Larry Rosenman [EMAIL PROTECTED] writes:
The last batch of commits break on FreeBSD 4.2-STABLE.
/usr/include/machine/lock.h:148: conflicting types for `s_lock'
../../../src/include/storage/s_lock.h:402: previous declaration of `s_lock'
Adam Haberlach [EMAIL PROTECTED] writes:
On Mon, Nov 27, 2000 at 04:09:46PM -0500, Tom Lane wrote:
Somewhere right around here is where I am going to ask why we are
entertaining the idea of a BeOS port in the first place... it's
evidently not Unix or even trying hard to be close to Unix.
My offer stands for you as well, if you'd like an account
on this P-III 600E, you are welcome to one...
LER
* Alfred Perlstein [EMAIL PROTECTED] [001128 22:46]:
* Larry Rosenman [EMAIL PROTECTED] [001128 20:44] wrote:
* Tom Lane [EMAIL PROTECTED] [001128 22:31]:
Larry Rosenman [EMAIL
* Larry Rosenman [EMAIL PROTECTED] [001128 20:52] wrote:
My offer stands for you as well, if you'd like an account
on this P-III 600E, you are welcome to one...
I just remebered my laptop in the other room, it's a pretty recent 4.2.
I'll give it shot.
Yes, it's possible to forget about a
* Tom Lane [EMAIL PROTECTED] [001128 22:55]:
Larry Rosenman [EMAIL PROTECTED] writes:
Here is the "Current" /usr/include/machine/lock.h:
...
void s_lock __P((struct simplelock *));
...
Ick. Seems like the relevant question is not so much "why did it break"
as
Larry Rosenman [EMAIL PROTECTED] writes:
We've called that routine s_lock for a *long* time, so it seems
like there must be some factor involved that I don't see just yet...
Didn't your commit message say something about the TAS and NON-TAS
paths being the same now?
Yeah, but don't tell me
* Tom Lane [EMAIL PROTECTED] [001128 23:03]:
Larry Rosenman [EMAIL PROTECTED] writes:
We've called that routine s_lock for a *long* time, so it seems
like there must be some factor involved that I don't see just yet...
Didn't your commit message say something about the TAS and NON-TAS
"He weiping" [EMAIL PROTECTED] writes:
but it seems the "lpad", "rpad" don't work,
when I type:
select lpad('laser', 4, 'a');
in psql, the result is still=20
'laser', the same with 'rpad',
Is it a bug or I'm mis-understaning the lpad and/or rpad functions?
lpad and rpad never truncate,
lpad and rpad never truncate, they only pad.
Perhaps they *should* truncate if the specified length is less than
the original string length. Does Oracle do that?
Yes, it truncates, same as Informix.
Andreas
I'm using cvs-current, and testing those
build-in function
according to the docs.
but it seems the lpad,
rpad don't work,
when I type:
select lpad('laser', 4, 'a');
in psql, the result is still
'laser', the same with 'rpad',
Is it a bug or I'm mis-understaning the lpad and/or rpad
40 matches
Mail list logo
