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
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 fields,
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 during
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 routines in
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 common
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 also
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 that
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
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
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 is
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
[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 holding only
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
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
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 we
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 the
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: system time
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?
Not
[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
19 matches
Mail list logo
