> >> 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 file created..." in postmaster' log -
backend writes this after releasing ControlFileLockId.

> Likely we shouldn't be using a spinlock at all for that, but the
> short-term solution might be a longer timeout for this 
> particular lock.
> Alternatively, could we avoid holding that lock while initializing a
> new log segment?

How to synchronize with checkpoint-er if wal_files > 0?
And you know - I've run same tests on ~ Mar 9 snapshot
without any problems.

Vadim

Fri, 16 Mar 2001 15:16:30 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Stuck spins in current 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> 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 PID-dependent name
	fill it with zeroes and fsync it
	acquire ControlFileLockId
	rename temp file into place as next uncreated segment
	update pg_control
	release ControlFileLockId

Since the things are just filled with 0's, there's no need to know which
segment it will be while you're filling it.

This would leave you sometimes with more advance files than you really
needed, but so what ...

> 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.

			regards, tom lane

Fri, 16 Mar 2001 18:25:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Stuck spins in current 