[EMAIL PROTECTED] (Nathan Myers) writes:
> Here, backend B is a good citizen and locks while it makes its change.
No, backend B wasn't a good citizen: it should have been holding
exclusive lock on the buffer.
> Also, as hints, would it be Bad(tm) if an attempt to clear one failed?
Clearing hint
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> If you estimate that a process dispatch cycle is ~ 10 microseconds,
>> then waking 999 useless processes every 10 msec is just about enough
>> to consume 100% of the CPU doing nothing useful...
> Don't we back off the sleeps or was that code removed?
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> DeadLockCheck: real time
>>
> min | max | avg
> -+---+-
> 0 | 87671 | 3463.6996197719
>>
> DeadLockCheck: user time
>>
> min | max | avg
> -+-+---
> 0 | 330 | 14.2205323194
>>
> DeadLockCheck:
Okay, on to the next concern. I've been thinking some more about the
restrictions needed to make the world safe for concurrent VACUUM.
I previously said:
> 5. To physically remove a tuple or compact free space on a page, one
> must hold a pin and an exclusive lock, *and* observe while holding th
Matthew <[EMAIL PROTECTED]> writes:
> NOTICE: RegisterSharedInvalid: SI buffer overflow
> NOTICE: InvalidateSharedInvalid: cache state reset
These are normal; at most they suggest that you've got another backend
sitting around doing nothing (but in an open transaction) while VACUUM
runs.
I think
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> This is rather like MySQL's enum.
Yes. If we were going to do anything like this, I'd vote for stealing
the "enum" API, lock stock and barrel --- might as well be compatible.
regards, tom lane
---(end of
RISKO Gergely <[EMAIL PROTECTED]> writes:
> I found a funny bug in postgres with c functions. (or feature??)
Scribbling on your input datum is verboten. palloc a new value
to return.
regards, tom lane
---(end of broadcast)
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Mon, Jul 02, 2001 at 09:40:25PM -0400, Tom Lane wrote:
>> 4. It is considered OK to update tuple commit status bits (ie, OR the
>> values HEAP_XMIN_COMMITTED, HEAP_XMIN_INVALID, HEAP_XMAX_COMMITTED, or
>> HEAP_XMAX_INVALID into t_infomask) while holdin
This is rather like MySQL's enum. I still opt for the join, and if
you like make a view for those who don't want to know the data
structure.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinio
> With stock PostgreSQL... how many committed transactions can one
lose
> on a simple system crash/reboot? With Oracle or Informix, the answer
> is zero. Is that true with PostgreSQL in fsync mode? If not, does it
> lose all in the log, or just those not yet written to the DB?
With WAL the theory
> With stock PostgreSQL... how many committed transactions can one lose
> on a simple system crash/reboot? With Oracle or Informix, the answer
> is zero. Is that true with PostgreSQL in fsync mode? If not, does it
It's true or better say should be, keeping in mind probability of bugs.
> lose all
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I added some codes into HandleDeadLock to measure how long
> LockLockTable and DeadLOckCheck calls take. Followings are the result
> in running pgbench -c 1000 (it failed with stuck spin lock
> error). "real time" shows how long they actually run (using
>
Alex Pilosov <[EMAIL PROTECTED]> writes:
> True true. On other hand, unlike union, its automatically typechecked, you
> cannot by mistake reference a field you shouldn't be referencing.
Only true to the extent that you have cast a generic pointer to the
correct type to begin with. However, we've
On Tue, 3 Jul 2001, Joe Brenner wrote:
> The reason I'm asking is that the place that I work is
> actually contemplating reverting from Oracle's expensive
> bugs to MySQL's (supposedly) cheap ones. They'd consider
> postgresql, but they figure that with MySQL they can at
> least point to sites t
> On further thought, btbuild is not that badly broken at the moment,
> because CREATE INDEX acquires ShareLock on the relation, so
> there can be no concurrent writers at the page level. Still, it
> seems like it'd be a good idea to do "LockBuffer(buffer,
BUFFER_LOCK_SHARE)"
> here, and probably
Alex Pilosov <[EMAIL PROTECTED]> writes:
> On Tue, 3 Jul 2001, Tom Lane wrote:
>> So you have four (soon to be six or seven) different structs that *must*
>> have the same fields? I don't think that's cleaner than a union ...
> Please see my diffs. Its implemented via #define to declare all comm
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I believe that nbtree.c's btbuild() code is currently in violation of
>> these rules, because it calls HeapTupleSatisfiesNow() while holding a
>> pin but no lock on the containing buffer.
> OK, we had better avoid using heapam routine
Where can I find some more information on it? I'm curious now.
Alex Pilosov wrote:
On Mon, 2 Jul 2001, Thomas Swan wrote:
I sit corrected. *slightly humbled*Why not do an unsigned int16 to hold your UUID generated numbers.
Not a good idea, since rules for comparison of U
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> this. Given that cursors (are supposed to) support FETCH BACKWARDS,
> I really don't see why they shouldn't be expected to handle ReScan...
>> I thought only scrollable cursors can do that. What if cursor isn't
>> scrollable? Should it error du
Alex Pilosov <[EMAIL PROTECTED]> writes:
>> And what are you doing with the places that don't care which kind of RTE
>> they are dealing with (which is most of them IIRC)? While you haven't
> They just have things declared as RangeTblEntry *, and as long as they
> don't access type-specific fiel
> > That's gonna have to be fixed. If you're not up for it, don't implement
> > this. Given that cursors (are supposed to) support FETCH BACKWARDS,
> > I really don't see why they shouldn't be expected to handle ReScan...
> I thought only scrollable cursors can do that. What if cursor isn't
> sc
21 matches
Mail list logo
