BTW, I've got ~320tps with 50 clients inserting (int4, text[1-256])
records into 50 tables (-B 16384, wal_buffers = 256) on Ultra10
with 512Mb RAM, IDE (clients run on the same host as server).
Not bad. What were you getting before these recent changes?
As I already reported - with
BTW, I've got ~320tps with 50 clients inserting (int4, text[1-256])
records into 50 tables (-B 16384, wal_buffers = 256) on Ultra10
with 512Mb RAM, IDE (clients run on the same host as server).
Not bad. What were you getting before these recent changes?
As I already reported -
"Vadim Mikheev" [EMAIL PROTECTED] writes:
Anyway, deadlock in my tests are very correlated with new log file
creation - something probably is still wrong...
Well, if you can reproduce it easily, seems like you could
get in there and verify or disprove my theory about where
the deadlock
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
"Vadim Mikheev" [EMAIL PROTECTED] writes:
Anyway, deadlock in my tests are very correlated with new log file
creation - something probably is still wrong...
Well, if you can reproduce it easily, seems like you could
get in there and verify or
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
xlog.c revision 1.55 from Feb 26 already had log file
zero-filling, so ...
Oh, you're right, I didn't study the CVS log carefully enough. Hmm,
maybe the control file lock isn't the problem. The abort() in
s_lock_stuck should have left a core
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
And you know - I've run same tests on ~ Mar 9 snapshot
without any problems.
Oh, I see it:
Process A is doing GetSnapShotData. It holds SInvalLock and calls
ReadNewTransactionId, which wants XidGenLockId.
Process B is doing GetNewTransactionId. It
At this point I must humbly say "yes, you told me so", because if I
No, I didn't - I must humbly say that I didn't foresee this deadlock,
so "I didn't tell you so" -:)
Anyway, deadlock in my tests are very correlated with new log file
creation - something probably is still wrong...
Vadim
"Vadim Mikheev" [EMAIL PROTECTED] writes:
Anyway, deadlock in my tests are very correlated with new log file
creation - something probably is still wrong...
Well, if you can reproduce it easily, seems like you could get in there
and verify or disprove my theory about where the deadlock is.
Or
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Got it at spin.c:156 with 50 clients doing inserts into
50 tables (int4, text[1-256 bytes]).
-B 16384, -wal_buffers=256 (with default others wal params).
SpinAcquire() ... but on which lock?
regards, tom lane
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Got it at spin.c:156 with 50 clients doing inserts into
50 tables (int4, text[1-256 bytes]).
-B 16384, -wal_buffers=256 (with default others wal params).
SpinAcquire() ... but on which lock?
After a little bit of thought I'll bet it's
How to synchronize with checkpoint-er if wal_files 0?
I was sort of visualizing assigning the created xlog files
dynamically:
create a temp file of a PID-dependent name
fill it with zeroes and fsync it
acquire ControlFileLockId
rename temp file into place as
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Alternatively, could we avoid holding that lock while initializing a
new log segment?
How to synchronize with checkpoint-er if wal_files 0?
I was sort of visualizing assigning the created xlog files dynamically:
create a temp file of a
Got it at spin.c:156 with 50 clients doing inserts into
50 tables (int4, text[1-256 bytes]).
-B 16384, -wal_buffers=256 (with default others wal params).
SpinAcquire() ... but on which lock?
After a little bit of thought I'll bet it's ControlFileLockId.
I see "XLogWrite: new log
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
And you know - I've run same tests on ~ Mar 9 snapshot
without any problems.
That was before I changed the code to pre-fill the file ---
now it takes longer to init a log segment. And we're only
using a plain SpinAcquire, not the flavor with a
And you know - I've run same tests on ~ Mar 9 snapshot
without any problems.
That was before I changed the code to pre-fill the file ---
now it takes longer to init a log segment. And we're only
using a plain SpinAcquire, not the flavor with a longer timeout.
xlog.c revision
15 matches
Mail list logo
