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 segmented
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 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
---(e
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&
] 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
the solution.
The solution usually to have a dir. Like
#include
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
---(end of broa
x, or apply my patch to 7.0.3. And you 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
--
---
t a
> long time for a hit, so it shouldn't affect most of them.
>
> However if long 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).
-
received an error stating that vacuum cannot be run in a
> > transaction.
> > Any ideas?
Can confirm 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
---
ambitious than a
> multi-column primary key.
>
> The platform is x86 Red Hat Linux 6.2. Curiously enough, on one of our
> testing boxes and on my development box we have never seen this, but we
> have seen it several times on our other test box and at least one
n.
>
> Running the sample lo program in C works, so I suppose 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
-
w on machine with database 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 PRO
> a backend receives a special signal, it dumps a file in /tmp with some
> backend status. It would be done similar to how we handle Cancel
> signals.
Small question... Will it work in console? Or it will be X only?
--
Sincerely Yours,
Denis Perchine
--
E-M
>
> real 0m3.753s
> user 0m0.010s
> sys 0m0.300s
>
>
> Starting to look like we should just use ODSYNC where available, and
> forget about dumping more per write ...
>
> regards, tom lane
>
> ---(end of broadcast)
separate unique index violations 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/
d a system catalog chart 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/
0
Indices: ix_users_account_name,
ix_users_blocked,
users_id_key
Do you need 2 other indices?
> Also, when these copies were made - before/after unsuccessful vacuum+lazy?
Surely before. :-))) Otherwise they would be almost useless for you.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
ual vacuum. 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
--
on-overwriting storage manager but uses
> rollback segments 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
---
> 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
SCAN |IX_ISO_VI | 6 | 42 | 3 | |
|
I think this question already was raised here, but... Why PostgreSQL does not
do this? What are the pros, and contros?
--
to force them to be done in
> a transaction block. If you're not clear 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
--
TX.
At least this will prevent other backends from reading partially imported
BLOBs...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
re careful. */
if (cap_t(p->cap_effective) & 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
--
Linux kernel code? I think all is
clear there.
--
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?
&
up the SIGDANGER behavior.
That's not the case for sure. There are 512Mb on the machine, 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
--
ed. With gz it is 8Mb.
Maybe it will be smaller with bz2.
> Keep in mind that the
> spinlock could have been left locked by any backend, not only the one
> that complained about it.
Actually you can have a look on the logs yourself. Remember I gave you a
password from postgres user. This i
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... Jus
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
--
Tuple(s) 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
--
ease send it me.
Another small comment. I did not made 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
--
terested with original table.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
Hello,
Another question about vacuum. Will vacuum/drop/create deadlocks be fixed in
7.0.x branch? That's really annoying. I cannot run vacuum automatically due
to this. Just a patch will be really great. Is it so hard to fix?
--
Sincerely Yours,
Denis Per
.0.0.1:5432 (CLOSE_WAIT)
And again. There is no any corresponding postmaster process. Does anyone has
such expirience before? And what can be the reason of such strange things.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perch
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
> make: *** [all] Error 2
>
>
>
> Philip Warner| __---_
> Albatross Consulting Pty. Ltd. |/ - \
> (A.B.N. 75 008 659 498) | /(@) __---
> 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
incerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
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.perchi
7;s really bad...
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
anity and sanity_check are now failing.
This was due to change 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:
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
TOC Entries:
;
2338; 15 OPERATOR = postgres
> produce?
>
> Have you done anything nasty to template1?
Just initdb.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
=" 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
--
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
--
lects
>
> Added to TODO:
>
> Allow ORDER BY...LIMIT in INSERT INTO ... SELECT
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
r this is a bug? 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
--
52 matches
Mail list logo
