Well, I tried the patch and the newly produced dump was identical to the bad
dump from before, so the patch had no affect. I will try to trim it down to
a reasonably small file and email it to you.
--Rainer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
On Fri, Feb 23, 2001 at 01:09:37PM +0200, Hannu Krosing wrote:
Dmitry Morozovsky wrote:
DM I just done the experiment with increasing HZ to 1000 on my own machine
DM (PII 374). Your test program reports 2 ms instead of 20. The other side
DM of increasing HZ is surely more overhead to
Appears that permissions applied to a table using the SERIAL element
aren't carried over to the sequence itself.
Create table with SERIAL, set-up permissions so table is accessible,
attempt to use inserts. No permission to sequence :(
Guess I won't be using this shortcut, between this and them
Bruce Momjian [EMAIL PROTECTED] writes:
Can someone explain why LockMethodCtl is in shared memory while
LockMethodTable is in postmaster memory context?
I realize LockMethodCtl has a spinlock, so it has to be in shared
memory, but couldn't it all be put in shared memory?
I think the original
Vadim Mikheev wrote:
Should this kind of usage be replaced in the future by
having backend id as a key and then doing delete by that
key in the end ?
Isn't it what we have right now?
I meant doing it at the application level, not what backend does internally.
Like we are supposed to
Hi,
my customers have his local m$ access db's locally then export them on
.txt with tab or | separated, then put on my server trought ftp.
and is working ok except that the customers are on spanish databases then
a data like:
--DATE-NAME-LANG--
1/6/2000|Ferran Adri|Castellano|
Looking at the XLOG stuff, I notice that we already have a field
(logRec) in the per-backend PROC structures that shows whether a
transaction is currently in progress with at least one change made
(ie at least one XLOG entry written).
It would be very easy to extend the existing code so that the
I seem to be having some problems w/ the psql jdbc
driver. I'm able to load the driver, but as soon as I try to connect w/
the database. here's my code:
import java.sql.*;
public class dataBase {
public static void main(String
[] args){
try
{
Hannu Krosing [EMAIL PROTECTED] writes:
Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
connecting each client to its own database, so that locking and such
does not shade the possible benefits (was it about 15% ?) of delay1
I didn't much like that approach to altering the
I didn't much like that approach to altering the test, since it also
means that all the clients are working with separate tables and hence
not able to share read I/O; that doesn't seem like it's the same
benchmark at all. What would make more sense to me is to increase the
number of rows in
... in the sense that they are reduced to constants instantly, rather
than being preserved as function calls. For example:
regression=# create table foo (f1 time default current_time);
CREATE
regression=# insert into foo default values;
INSERT 618879 1
wait a few seconds
regression=# insert
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, what about the names? There is LOCKMETHODCTL, LOCKMETHODTABLE,
and LOCKMODES. How about LOCKSTYLESHARED, LOCKSTYLE, and leave
LOCKMODES unchanged?
I think both of those names are worse (less descriptive) than what
we have ...
Bruce Momjian [EMAIL PROTECTED] writes:
Why not just set a flag in there when someone nears commit and clear
when they are about to commit?
Define "nearing commit", in such a way that you can specify where you
plan to set that flag.
Is there significant time between entry of
Hi all!
IRCCS E. Medea is an Italian no-profit scientific and clinical research institute. It
spreads over 5 different geographical locations connected through a private data
network.
We are using PostgreSQL as DBMS because its object-oriented features qualify it for
managing biomedical
Looking at the XLOG stuff, I notice that we already have a field
(logRec) in the per-backend PROC structures that shows whether a
transaction is currently in progress with at least one change made
(ie at least one XLOG entry written).
It would be very easy to extend the existing code so
Hi,
in my java code I am creating 3 temporary tables, then calling a stored
procedure which calls another stored procedure.
then I drop the temporary tables.
the first time around , eveything is OK , then when repeating the action I
get
"ExecOpenScanR: failed to open relation 2808495 "
could
... if anyone wants to take a quick gander at it while I wait to announce
its availability ... let me know if therea re any obvious problems iwht it
...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED]
We have three choices:
1. Change these pg_proc entries. This does not force an initdb,
exactly, but it won't take effect without one either.
2. Change the function calls emitted by the parser for
CURRENT_DATE/TIME. This doesn't force an initdb either, but it's a
workaround whereas #1
Bruce Momjian [EMAIL PROTECTED] writes:
Is there one LOCKMETHODCTL for every backend? I thought there was only
one of them.
You're right, that line is erroneous; it should read
size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
Not a significant error but it should
Linux 2.2.14
Postgres 7.0.3
DBI 1.14
I am working on Freeside and need to have above 31 character column
names. I need postgresql to stop auto-truncating when a create command is
executed.
I have tried editing /src/include/postgres_ext.h and set the NAMEDATELEN
to 64 and it still gives me a
Is there one LOCKMETHODCTL for every backend? I thought there was only
one of them.
You're right, that line is erroneous; it should read
size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
Not a significant error but it should be changed for clarity ...
I assume the fix
Bruce Momjian [EMAIL PROTECTED] writes:
Why not just set a flag in there when someone nears commit and clear
when they are about to commit?
Define "nearing commit", in such a way that you can specify where you
plan to set that flag.
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] writes:
Is there one LOCKMETHODCTL for every backend? I thought there was only
one of them.
You're right, that line is erroneous; it should read
size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
Not a significant error but it should be changed
Bruce Momjian [EMAIL PROTECTED] writes:
Is there significant time between entry of CommitTransaction() and the
fsync()? Maybe not.
I doubt it. No I/O anymore, anyway, unless the commit record happens to
overrun an xlog block boundary.
That's what I was afraid of. Since we don't write
I just talked to Tom Lane, and have added the following to the TODO
list:
* Merge LockMethodCtl and LockMethodTable into one shared structure
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard
Bruce Momjian [EMAIL PROTECTED] writes:
Is there one LOCKMETHODCTL for every backend? I thought there was only
one of them.
You're right, that line is erroneous; it should read
size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
Not a significant error but it should
Sorry to have been too brief:
* Merge LockMethodCtl and LockMethodTable into one shared structure (Bruce)
Basically, lock methods are now stored in structures, one in shared
memory with a spinlock, and another in normal memory created by the
postmaster. The goal for 7.2 is to merge these
The Hermit Hacker wrote:
... if anyone wants to take a quick gander at it while I wait to announce
its availability ... let me know if therea re any obvious problems iwht it
...
Quick note: it will be Sunday at the earliest before I can build RPM's
of beta5. If the package release is after
... if anyone wants to take a quick gander at it while I wait to announce
its availability ... let me know if therea re any obvious problems iwht it
...
I was wondering what open items are left? Are we ready to start the
release process with a docs freeze?
--
Bruce Momjian
Pam Withnall [EMAIL PROTECTED] writes:
in my java code I am creating 3 temporary tables, then calling a stored
procedure which calls another stored procedure.
then I drop the temporary tables.
the first time around , eveything is OK , then when repeating the action I
get
"ExecOpenScanR:
I have added this to /contrib. It meets the needs of several posters.
I had a need to read such things as the backend locale and the catalog
version number from the current database, and couldn't find any existing
program to do that.
The attached utility produces this output:
linda:~$
Ok, what am I missing? Don't bother trying to run it, it's not hooked
up :)
Yes there are some extra linuxes, if noone comes up with another distro
I'll lop the extras off. BTW, is VA Linux a distribution or just a tool
company??
http://hub.org/~vev/regress.php
Vince.
--
Bruce Momjian [EMAIL PROTECTED] writes:
I was wondering what open items are left? Are we ready to start the
release process with a docs freeze?
I need some feedback on my commitdelay proposal first. If we add a
runtime parameter to control that, it had better be documented.
I have a couple
On Fri, Feb 23, 2001 at 03:53:14PM -0500, Vince Vielhaber wrote:
Yes there are some extra linuxes, if noone comes up with another distro
I'll lop the extras off. BTW, is VA Linux a distribution or just a tool
company??
Debian is a pretty important Linux distibution, probably second only
to
To clarify further, I am using the RPMs from the postgresql.org
website. I installed the SRPM, changed the /src/include/postgres_ext.h,
retar-balled the postgres-7.0.3 dir, and reinstalled the rpms (rpm -e,
rpm -Uvh).
I don't know if this helps or if there is something I need to do further
Bruce Momjian writes:
I was wondering what open items are left? Are we ready to start the
release process with a docs freeze?
I still have the JDBC docs to finish and someone was going to send some
PL/pgSQL stuff, but I guess I'll have to remind him again. What exactly
is the goal
On Fri, Feb 23, 2001 at 11:32:21AM -0500, Tom Lane wrote:
A further refinement, still quite cheap to implement since the info is
in the PROC struct, would be to not count backends that are blocked
waiting for locks. These guys are less likely to be ready to commit
in the next few
Bruce Momjian [EMAIL PROTECTED] writes:
I was wondering what open items are left? Are we ready to start the
release process with a docs freeze?
I need some feedback on my commitdelay proposal first. If we add a
runtime parameter to control that, it had better be documented.
I think we
Bruce Momjian [EMAIL PROTECTED] writes:
I think we need to give up on the delay for 7.1.X. I don't see any
good/easy solutions.
I take it you think my idea is not even worth trying. Why not?
regards, tom lane
Bruce Momjian writes:
I was wondering what open items are left? Are we ready to start the
release process with a docs freeze?
I still have the JDBC docs to finish and someone was going to send some
PL/pgSQL stuff, but I guess I'll have to remind him again. What exactly
is the goal of a docs
Thomas Lockhart [EMAIL PROTECTED] writes:
(Just a follow up...)
I haven't had time to review the spec on this, but my recollection is
that the entire SQL language can be described using the SQL_ASCII
character set. I would assume that this might include unquoted
identifiers.
The keywords
Thomas Lockhart [EMAIL PROTECTED] writes:
This problem is in the current CVS tree also. A workaround of removing
the reltime==int assumed compatibility could be applied to 7.1 (I
haven't thought of what that would affect) or we can build some explicit
operators to make sure that the
Date calculation produces wrong output with 7.02
cascade= select date(CURRENT_DATE + ('30 days'::reltime));
date
--
9097-10-20
It's quite likely my "date math" syntax is wrong, but it seems
that Postgres should either return the right result, or let me
know something is
Anyway, your proposal is just fine since we haven't decoupled these
things farther back in the server. But eventually we should hope to have
SQL_ASCII and other character sets enforced in context.
Now I'm confused. Are you saying that we *should* treat identifier case
under ASCII rules
Bruce Momjian [EMAIL PROTECTED] writes:
I think we need to give up on the delay for 7.1.X. I don't see any
good/easy solutions.
I take it you think my idea is not even worth trying. Why not?
You are suggesting looking at the "I have modified something" bit in
Proc, and using that to
Bruce Momjian [EMAIL PROTECTED] writes:
So, the change would have to show that doing the delay when some other
backend has dirtied a buffer is _better_ than doing no delay.
Agreed. However, we have as yet no data that proves nonzero commit
delay is bad in the presence of multiple active
On Fri, Feb 23, 2001 at 11:32:21AM -0500, Tom Lane wrote:
A further refinement, still quite cheap to implement since the info is
in the PROC struct, would be to not count backends that are blocked
waiting for locks. These guys are less likely to be ready to commit
in the next few
Hmm. A further refinement would be to add a waiting-for-client-input
bit to PROC, although if you have a fast-responding client, ignoring
such backends wouldn't necessarily be a good thing. Notice that the
pgbench transaction involves multiple client requests ...
Let's keep talking. I
[EMAIL PROTECTED] (Nathan Myers) writes:
Comments? What should the threshold N be ... or do we need to make
that a tunable parameter?
Once you make it tuneable, you're stuck with it. You can always add
a knob later, after somebody discovers a real need.
If we had a good idea what the
[EMAIL PROTECTED] (Nathan Myers) writes:
Comments? What should the threshold N be ... or do we need to make
that a tunable parameter?
Once you make it tuneable, you're stuck with it. You can always add
a knob later, after somebody discovers a real need.
If we had a good idea what
On Fri, 23 Feb 2001, Nathan Myers wrote:
On Fri, Feb 23, 2001 at 03:53:14PM -0500, Vince Vielhaber wrote:
Yes there are some extra linuxes, if noone comes up with another distro
I'll lop the extras off. BTW, is VA Linux a distribution or just a tool
company??
Debian is a pretty
And if they have, should we be more
likely to fsync() in the future?
I meant more likely to sleep().
You mean less likely. My thought for a self-adjusting delay was to
ratchet the delay up a little every time it succeeds in avoiding an
fsync, and down a little every time it fails to do
Bruce Momjian [EMAIL PROTECTED] writes:
A self-adjusting delay might well be a great idea, BTW, but I'm trying
to be conservative about how much complexity we should add right now.
OH, so you are saying N backends should have dirtied buffers before
doing the delay? Hmm, that seems almost
Bruce Momjian [EMAIL PROTECTED] writes:
It could be tough. Imagine the delay increasing to 3 seconds? Seems
there has to be an upper bound on the sleep. The more you delay, the
more likely you will be to find someone to fsync you.
Good point, and an excellent illustration of the fact that
On Fri, Feb 23, 2001 at 05:18:19PM -0500, Tom Lane wrote:
[EMAIL PROTECTED] (Nathan Myers) writes:
Comments? What should the threshold N be ... or do we need to make
that a tunable parameter?
Once you make it tuneable, you're stuck with it. You can always add
a knob later, after
When thinking about tuning N, I like to consider what are the interesting
possible values for N:
0: Ignore any other potential committers.
1: The minimum possible responsiveness to other committers.
5: Tom's guess for what might be a good choice.
10: Harry's guess.
~0: Always
-Original Message-
From: Tom Lane
Hannu Krosing [EMAIL PROTECTED] writes:
Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
connecting each client to its own database, so that locking and such
does not shade the possible benefits (was it about 15% ?) of delay1
Bruce Momjian [EMAIL PROTECTED] writes:
It could be tough. Imagine the delay increasing to 3 seconds? Seems
there has to be an upper bound on the sleep. The more you delay, the
more likely you will be to find someone to fsync you.
Good point, and an excellent illustration of the fact
Bruce Momjian [EMAIL PROTECTED] writes:
Can we put the backends to sleep waiting for a lock, and have them wake
up later?
Locks don't have timeouts. There is no existing mechanism that will
serve this purpose; we'll have to create a new one.
regards, tom lane
On Fri, Feb 23, 2001 at 06:37:06PM -0500, Bruce Momjian wrote:
When thinking about tuning N, I like to consider what are the interesting
possible values for N:
0: Ignore any other potential committers.
1: The minimum possible responsiveness to other committers.
5: Tom's guess
It seems to me that comparing various choices (and other, more
interesting, algorithms) to the N=1 case would be more productive
than comparing them to the N=0 case, so releasing at N=1 would yield
better statistics for actually tuning in 7.2.
We don't release code because it has
Bruce Momjian [EMAIL PROTECTED] writes:
Can we put the backends to sleep waiting for a lock, and have them wake
up later?
Locks don't have timeouts. There is no existing mechanism that will
serve this purpose; we'll have to create a new one.
That is what I suspected.
Having thought
With current sources:
DEBUG: copy: line 629980, XLogWrite: new log file created - try to increase WAL_FILES
DEBUG: copy: line 694890, XLogWrite: new log file created - try to increase WAL_FILES
FATAL 2: copy: line 759383, ZeroFill(logfile 0 seg 13) failed: No space left on device
Server
It may be that WAL has changed the rollback
time-characteristics to worse than pre-wal ?
Nothing changed ... yet. And in future rollbacks
of read-only transactions will be as fast as now,
anyway.
What about rollbacks of a bunch uf inserts/updates/deletes?
I remember a scenario
Tom Lane wrote:
Sezai YILMAZ [EMAIL PROTECTED] writes:
With Turkish locale it is not possible to write SQL queries in
CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first
are downgraded to "nsert" and "unon". Then "nsert" and "unon"
does not match as SQL identifier.
Justin Clift wrote:
Tom Lane wrote:
Sezai YILMAZ [EMAIL PROTECTED] writes:
With Turkish locale it is not possible to write SQL queries in
CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first
are downgraded to "nsert" and Then "nsert" and "unon"
does not match as
Hello:
I have problems with a LOCK sentence and ECPG.
Could anybody tell me if I can execute some sentences simila to:
EXEC SQL LOCK TABLE users IN SHARE ROW EXCLUSIVE MODE;
Where is my error?
Thanks
Jhon Orellana
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Hi,
Can some one tell me what am I missing?
$ make intrasend
gcc -o /c/inetpub/wwwroot/cgi-bin/intrasend.exe intrasend.c
intrautils.c -I/usr/
local/pgsql/include -L/usr/local/pgsql/lib
intrautils.c:7: warning: initialization makes integer from pointer without a
cas
t
It may be that WAL has changed the rollback
time-characteristics to worse than pre-wal ?
Nothing changed ... yet. And in future rollbacks
of read-only transactions will be as fast as now,
anyway.
So my guess is that the 7.1 updates (with default
fsync) are significantly slower than 7.0.3
At 21:31 23/02/01 -0500, Bruce Momjian wrote:
Now, I know many will complain that we are returning commit while not
having the stuff on the platter.
You're definitely right there.
Maybe they do, but it seems
the benefit of grouped fsyncs() is large enough that many will say they
would rather
At 21:31 23/02/01 -0500, Bruce Momjian wrote:
Now, I know many will complain that we are returning commit while not
having the stuff on the platter.
You're definitely right there.
Maybe they do, but it seems
the benefit of grouped fsyncs() is large enough that many will say they
would
Matthew writes:
I think UP or SMP should be an option to check, perhaps just a box for the
number of processors. Also something to capture the compile flags. I have
a dual Ppro, and it compiles fine unless I use the -j3 or -j4 commands,
then I get an error.
Which error?
Parallel make
At 11:32 23/02/01 -0500, Tom Lane wrote:
Looking at the XLOG stuff, I notice that we already have a field
(logRec) in the per-backend PROC structures that shows whether a
transaction is currently in progress with at least one change made
(ie at least one XLOG entry written).
Would it be worth
Here's my dillema:
We are currently building a site with multiple machines to run our website
and client sites as well. I would like to run the postgres binary on 2
machines concurrently to assist in load balancing. $PGDATA will be kept on
a RAID 1+0.I need to know where postgres does
On Fri, 23 Feb 2001, Andy Engdahl wrote:
I seem to be having some problems w/ the psql jdbc driver. I'm able to load the
driver, but as soon as I try to connect w/ the database. here's my code:
import java.sql.*;
public class dataBase {
public static void main(String [] args){
At 23:14 23/02/01 -0500, Bruce Momjian wrote:
There is one more thing. Even though the kernel says the data is on the
platter, it still may not be there.
This is true, but it does not mean we should say 'the disk is slightly
unreliable, so we can be too'. Also, IIRC, the last time this was
Thanks ! I'm using JDBC to insert into the tables.
Would it throw an SQLException in such a situation ?
Rini
--- "Diehl, Jeffrey" [EMAIL PROTECTED] wrote:
I happen to know this very well... It handles
things very gracefully as far
as I can tell. I complains that it can't extend the
table
Hi,
Does anyone know how postgres/ postmaster handles the
situation where the physical hard disk space is full ?
Does it crash / corrupt the database, or does it
cleanly exit with appopriate message so that relevant
tables can be pruned (by the user) to free up disk
space and get it working
Hi,
I happenned to come across the following in the
documentation on WAL implementation in v7.1 -
*
Before WAL, any crash during writing could result in:
1.index tuples pointing to non-existent table rows
2.index tuples lost in
On Fri, Feb 23, 2001 at 09:05:20PM -0500, Bruce Momjian wrote:
It seems to me that comparing various choices (and other, more
interesting, algorithms) to the N=1 case would be more productive
than comparing them to the N=0 case, so releasing at N=1 would yield
better statistics
At 23:14 23/02/01 -0500, Bruce Momjian wrote:
There is one more thing. Even though the kernel says the data is on the
platter, it still may not be there.
This is true, but it does not mean we should say 'the disk is slightly
unreliable, so we can be too'. Also, IIRC, the last time this
On Fri, 23 Feb 2001, Hannu Krosing wrote:
HK DM I just done the experiment with increasing HZ to 1000 on my own machine
HK DM (PII 374). Your test program reports 2 ms instead of 20. The other side
HK DM of increasing HZ is surely more overhead to scheduler system. Anyway, it's
HK DM a bit
Bruce Momjian [EMAIL PROTECTED] writes:
My idea would be to let committing backends return "COMMIT" to the user,
and set a need_fsync flag that is guaranteed to cause an fsync within X
milliseconds. This way, if other backends commit in the next X
millisecond, they can all use one
Bruce Momjian [EMAIL PROTECTED] writes:
My idea would be to let committing backends return "COMMIT" to the user,
and set a need_fsync flag that is guaranteed to cause an fsync within X
milliseconds. This way, if other backends commit in the next X
millisecond, they can all use one fsync().
At 21:31 23/02/01 -0500, Bruce Momjian wrote:
Now, I know many will complain that we are returning commit while not
having the stuff on the platter.
You're definitely right there.
Maybe they do, but it seems
the benefit of grouped fsyncs() is large enough that many will say they
would
Philip Warner [EMAIL PROTECTED] writes:
It may have been much earler in the debate, but has anyone checked to see
what the maximum possible gains might be - or is it self-evident to people
who know the code?
fsync off provides an upper bound to the speed achievable from being
smarter about
Preliminary results from experimenting with an
N-transactions-must-be-running-to-cause-commit-delay heuristic are
attached. It seems to be a pretty definite win. I'm currently running
a more extensive set of cases on another machine for comparison.
The test case is pgbench, unmodified, but run
[EMAIL PROTECTED] (Nathan Myers) writes:
I see, I had it backwards: N=0 corresponds to "always delay", and
N=infinity (~0) is "never delay", or what you call zero delay. N=1 is
not interesting. N=M/2 or N=sqrt(M) or N=log(M) might be interesting,
where M is the number of backends, or the
Philip Warner [EMAIL PROTECTED] writes:
It may have been much earler in the debate, but has anyone checked to see
what the maximum possible gains might be - or is it self-evident to people
who know the code?
fsync off provides an upper bound to the speed achievable from being
smarter
89 matches
Mail list logo
