On Thursday 26 September 2002 21:52, Shridhar Daithankar wrote:
I might have found the bottleneck, although by accident. Mysql was running
out of space while creating index. So my friend shut down mysql and tried
to move things by hand to create links. He noticed that even things like cp
Hi,
I was interested in this:
Firebird's indexes are very dense because they compress both the prefix and
the suffix of each key. Suffix compression is simply the elimination of
trailing blanks or zeros, depending on the data type. Suffix compression is
performed on each segment of a
On Monday 15 April 2002 03:53, Christopher Kings-Lynne wrote:
BTW, instead of:
CREATE UNIQUE INDEX bigone_pkey ON bigone (rec_no);
do:
ALTER TABLE bigone ADD PRIMARY KEY(rec_no);
I am sorry, could you please elaborate more on the difference?
--
Denis
---(end of
On Monday 15 April 2002 05:15, Christopher Kings-Lynne wrote:
On Monday 15 April 2002 03:53, Christopher Kings-Lynne wrote:
BTW, instead of:
CREATE UNIQUE INDEX bigone_pkey ON bigone (rec_no);
do:
ALTER TABLE bigone ADD PRIMARY KEY(rec_no);
I am sorry, could you please
On Thursday 06 September 2001 20:49, Tom Lane wrote:
Denis Perchine [EMAIL PROTECTED] writes:
Okay. As a temporary recovery measure, I'd suggest reducing that
particular elog from STOP to DEBUG level. That will let you start up
and run the database. You'll need to look through your
] DEBUG: database system shutdown was
interrupted at 2001-09-05 08:42:30 EDT
Sep 5 08:44:42 mx postgres[5441]: [2] DEBUG: CheckPoint record at (23, 2431142676)
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com
. Like
#include pgsql/config.h
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
---(end of broadcast
will have no such
problems at all. :-))
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
---(end of broadcast
running transactions are to be aborted automatically, it
could possibly cause problems with some apps out there.
Worse if long running transactions are _disconnected_ (not just aborted).
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage
this. This is also the case on my systems. I already told about
this some time ago. There was no reply...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
r test box and at least one customer
site, so there is some possibility it's related to dodgy hardware. The
customer box with the problem is a multi-processor box, all the other
boxes we've tested on are single-processor.
TIA for any help,
Tim
--
Sincerely Yours,
Denis Perchine
-
server... At least if it is not for play,
but production one...
Also there should be a possibility of remote monitoring of the database. But
that's just dream... :-)))
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http
the problem
must come from the bytes I'm sending. Any ideas what could cause this?
PostgreSQL 7.0.3 on sparc-sun-solaris2.5.1, compiled by gcc 2.95.2
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2
from other errors. This often needed when
you want just do insert, and leave all constraint checking to database...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
in the presentation.
Wow! That's cool.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
Hello,
I just saw (or better to say waspointed to) the following bug in Bug tracking
tool submitted yesterday: pgsql 7.0.2 cursor bug.
I have exactly the same trouble... Until I free cursor daemon grows...
I have this in plain 7.0.3. Any comments?
--
Sincerely Yours,
Denis Perchine
Store all large objects in a single table (Denis Perchine, Tom)
Hmmm... If you would point me to the document where changes should be done, I
will do them.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp
. I have sent an original version of a table from the backup
to Vadim, but did not get any response. Just for your info.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
| 3 | |
|
I think this question already was raised here, but... Why PostgreSQL does not
do this? What are the pros, and contros?
--
Sincerely Yours,
Denis Perchine
Denis Perchine [EMAIL PROTECTED] writes:
I think this question already was raised here, but... Why PostgreSQL
does not do this? What are the pros, and contros?
The reason you have to visit the main table is that tuple validity
status is only stored in the main table, not in each index
to maintain MVCC. Rollback segments are used
to restore valid version of entire index/table page.
Are there any plans to have something like this? I mean overwriting storage
manager.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http
they
are not inside TX themselves.
I am not sure, maybe Tom is right, and we should fix be-fsstubs.c instead.
But I do not see any reasons why we not put lo_import, and lo_export in TX.
At least this will prevent other backends from reading partially imported
BLOBs...
--
Sincerely Yours,
Denis
about this, perhaps you need
to review the difference between transactions and transaction blocks.
Hmmm... Where can I read about it? At least which source/header?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp
) CAP_TO_MASK(CAP_SYS_RAWIO)) {
force_sig(SIGTERM, p);
} else {
force_sig(SIGKILL, p);
}
You will get SIGKILL in most cases.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
a look on the logs yourself. Remember I gave you a
password from postgres user. This is the same postgres. Logs are in
/var/log/postgres. You will need postgres.log.1.gz.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http
, and when I had
this problem it was compltely unloaded (300Mb in caches).
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
On Monday 08 January 2001 23:21, Tom Lane wrote:
Denis Perchine [EMAIL PROTECTED] writes:
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
Actually you can have a look on the logs yourself.
Well, I found a smoking gun:
Jan 7 04
processes...
Server processes were terminated at Sun Jan 7 04:29:07 2001
Reinitializing shared memory and semaphores
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
On Monday 08 January 2001 00:08, Tom Lane wrote:
Denis Perchine [EMAIL PROTECTED] writes:
Does anyone seen this on PostgreSQL 7.0.3?
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
No... Just clean log (I redirect log from stderr
) moved: 0. CPU
0.00s/0.01u sec.
VACUUM
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
table.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
initdb. And did not made dump/restore.
Maybe this is a problem. I just installed a patch.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
Hello,
what this can be?
FATAL: s_lock(40015071) at spin.c:127, stuck spinlock. Aborting.
From other sources I can find out that there was real memory starvation. All
swap was eated out (that's not PostgreSQL problem).
--
Sincerely Yours,
Denis Perchine
--
E
- \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___ |
Http://www.rhyme.com.au |/ \|
|----
PGP key avai
Denis Perchine [EMAIL PROTECTED] writes:
Small technical question: what exactly CommandCounterIncrement do?
It increments the command counter ;-)
And what exactly it should be used for?
You need it if, within a chunk of backend code, you want subsequent
queries to see the results
, and if not it will issue a notice.
The question is how correctly check that I am in transaction.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
Hello,
there's really wierd trouble.
When I run 2 vacuum's in parallel they hangs. Both.
I use PostgreSQL from 7.0.x CVS (almost 7.0.3).
Any ideas? Tom?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp
...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
in template1.
Here is regression.diff attached.
And also there's test.patch attached which will fix this.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
t; already defined
'.
Another funny thing is that dump of empty database occupies 657614 bytes.
It is quite much...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
te1?
Just initdb.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
BTW, also, if it is possible it is a good idea to remove the following
warning if there are no BLOBs in the archive: Archiver: WARNING - skipping
BLOB restoration
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com
will wait until it becames stable. If it my bug, how can I catch it?
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
in INSERT INTO ... SELECT
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
? If it is a bug...
How to fix it (patch, workaround...)
Thanks in advance.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
45 matches
Mail list logo
