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).
Vadim
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"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 Contr
> > 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
"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 o
> >> 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
"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 flav
> > 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.
>
> >
"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
"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.
> 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.
> "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
> th
"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
> > 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 - w
> > > 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 alread
16 matches
Mail list logo
