Added to TODO, just so we don't forget later:
* Use a phantom command counter for nested subtransactions to reduce
tuple overhead
---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ...
Alvaro Herrera [EMAIL PROTECTED] writes:
- GUC vars are rolled back on subxact abort
This did not work very well, but here is a revised GUC patch that I think
does work. It requires xact.c to export a function to report the
current nesting depth, and requires AtEOXact_GUC to be called in all
On Sun, Jun 20, 2004 at 08:49:22PM -0400, Tom Lane wrote:
There's a good deal more than that missing :-(. Here are the modules or
actions that are called in CommitTransaction and/or AbortTransaction
that have not yet been touched by the patch:
localbuf.c (refcounts need fixed same as
Alvaro Herrera [EMAIL PROTECTED] writes:
As with the bufmgr.c original patch, I don't really know how to test
that this actually works. I fooled around with printing what it was
doing during a subtrans commit/abort, and it seems OK, but that's about
it. In what situations can a transaction
On Tue, Jun 29, 2004 at 06:59:20PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
As with the bufmgr.c original patch, I don't really know how to test
that this actually works. [...]
I forgot to mention to you that that code didn't work at all, btw.
Bad news, I guess.
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm ... yes, this could be very ugly indeed, but I haven't even looked
at the executor code so I can't comment. Are executor nodes copyable?
Nope, and even if we had support for that the executor tree per se
is just the tip of the iceberg. There's also
On Sun, Jun 27, 2004 at 12:49:10AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I'll work on adding the Xid-cache to PGPROC and using that in
TransactionIdIsInProgress and the tqual routines. If you want to work
on that let me know and I'll handle things like the
On Sat, Jun 26, 2004 at 07:56:09PM -0400, Tom Lane wrote:
Do we really need SubtransCutoffXid? AFAICS the reason for having it is
only this claim in RecordTransactionCommit:
* We can't mark committed subtransactions as fully committed,
* because concurrent transactions
On Sat, Jun 26, 2004 at 07:56:09PM -0400, Tom Lane wrote:
BTW, it would help to know what parts of the patch you intend to work on
over the next couple of days. I'm reviewing and editorializing right
now with intent to commit soon, so it would be good if we can avoid
tromping on each others'
On Wed, 2004-06-23 at 13:57, Bruce Momjian wrote:
I am sorry to have given Alvaro another idea that didn't work.
No way! Keep having the ideas, please.
I've done some more digging in dead time on all of this and I think
we're on the right course in general by implementing all of this.
...well
On Sun, Jun 20, 2004 at 08:49:22PM -0400, Tom Lane wrote:
Regarding GUC, a WIP report:
Given patches for inval.c and guc.c, I would say that the patch is
functionally close enough to done that we could commit to including
it in 7.5 --- the other stuff could be wrapped up post-feature-freeze.
Alvaro Herrera wrote:
On Sun, Jun 20, 2004 at 04:37:16PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here I present the nested transactions patch and the phantom Xids patch
that goes with it.
I looked at the phantom XIDs stuff a bit. I still have little
On Wed, Jun 23, 2004 at 08:58:15AM -0400, Bruce Momjian wrote:
If we add nested transactions for 7.5, are we going to need savepoints
too in the same release? If we don't, are we going to get a lot of
complaints?
It'd be good to have savepoints right now. I'm not sure it'd be good to
expose
On Wed, Jun 23, 2004 at 08:57:11AM -0400, Bruce Momjian wrote:
I am sorry to have given Alvaro another idea that didn't work.
It allowed me to learn a lot of cool tricks, so it wasn't wasted work.
The only think I'm sorry about is that I should have used the time for
something more useful, like
Alvaro Herrera [EMAIL PROTECTED] writes:
It'd be good to have savepoints right now. I'm not sure it'd be good to
expose the nested transactions implementation if we are going to offer
savepoints later, because it means we will have to keep nested
transactions forever.
Nested transactions are
On Sun, Jun 20, 2004 at 08:49:22PM -0400, Tom Lane wrote:
Of these the one that I think most urgently needs attention is inval.c;
that is complicated code already and figuring out what should happen
for subtrans commit/abort is not trivial. The others look relatively
straightforward to fix,
On Sun, Jun 20, 2004 at 04:37:16PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here I present the nested transactions patch and the phantom Xids patch
that goes with it.
I looked at the phantom XIDs stuff a bit. I still have little confidence
that the concept is
On Mon, Jun 21, 2004 at 10:28:59PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This is tricky because chunks are prepended to the queue, but it also
means we can stop processing as soon as a message belongs to another
transaction.
AFAIR there isn't any essential
Alvaro Herrera [EMAIL PROTECTED] writes:
On Mon, Jun 21, 2004 at 10:28:59PM -0400, Tom Lane wrote:
Also, rather than labeling each entry individually, it might be better
to keep a separate list for each level of transaction. Then instead of
relabeling, you'd just concat the subtrans list to
Alvaro Herrera [EMAIL PROTECTED] writes:
Here I present the nested transactions patch and the phantom Xids patch
that goes with it.
I looked at the phantom XIDs stuff a bit. I still have little confidence
that the concept is correct :-( but here are some comments on the code
level.
+ * They
Bruce Momjian [EMAIL PROTECTED] writes:
I don't feel too bad about the runtime cost if only subtransactions are
paying that cost.
That's exactly why I'm so exercised about what's been done to the
HeapTupleSet/Get macros. That's significant cost that's paid even when
you're not using *any* of
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here I present the nested transactions patch and the phantom Xids patch
that goes with it.
I looked at the phantom XIDs stuff a bit. I still have little confidence
that the concept is correct :-( but
Bruce Momjian [EMAIL PROTECTED] writes:
Let me add that outside transactions read those phantom xid only when
they are doing dirty reads. What I don't understand is when do outside
transactions see tuples created inside a transaction? INSERT into a
table with a unique key?
Once the main
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Let me add that outside transactions read those phantom xid only when
they are doing dirty reads. What I don't understand is when do outside
transactions see tuples created inside a transaction? INSERT into a
table with a unique
Alvaro Herrera [EMAIL PROTECTED] writes:
Here I present the nested transactions patch and the phantom Xids patch
that goes with it.
I took a very preliminary look through the nested-xacts patch, too.
Missing: rollback of SET CONSTRAINTS and GUC vars.
There's a good deal more than that
Bruce Momjian [EMAIL PROTECTED] writes:
What ideas do you have to help him?
Eat the four-byte overhead.
Quite frankly, given the other functionality and performance issues
he has to solve in the next ten days (see my other message just now),
I think he'd be a fool to spend one more minute on
26 matches
Mail list logo
