On Sun, Jun 13, 2004 at 01:22:05PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Not sure how to fix this -- I'm not even sure what the exact problem is,
> > because it's trying to insert the oid of a toast table in
> > pg_class_oid_index during the first ALTER TABLE ... C
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Not sure how to fix this -- I'm not even sure what the exact problem is,
> because it's trying to insert the oid of a toast table in
> pg_class_oid_index during the first ALTER TABLE ... CREATE TOAST TABLE.
> Why would it see an old tuple with the same v
Alvaro Herrera wrote:
> On Tue, Jun 01, 2004 at 06:40:07PM -0400, Bruce Momjian wrote:
>
> > When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> > replace it with xmin=3. xid=3 will be marked as committed if xid2
> > aborts, and will be marked as aborted if xid3 commits.
> >
I said
> One such possible caller is EvalPlanQual. It could go to sleep using
> XactLockTableWait() on the SnapshotDirty's xmax. But the tuple has
> something strange in its xmax -- it's the tuple's cmin actually.
> Leaving this would be probably a bug.
>
> However, if the tuple is new, then Ev
On Tue, Jun 01, 2004 at 06:40:07PM -0400, Bruce Momjian wrote:
> When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> replace it with xmin=3. xid=3 will be marked as committed if xid2
> aborts, and will be marked as aborted if xid3 commits.
>
> So, if xid2 aborts, the insert
Alvaro Herrera wrote:
> On Wed, Jun 02, 2004 at 10:57:05AM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> > > No, I said own xid --- so the "phantom xid" part is still there. But
> > > your idea definitely does *not* work unless you use a single CID
> > > sequence for the whole main xact; a
On Wed, Jun 02, 2004 at 10:57:05AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
>
> > No, I said own xid --- so the "phantom xid" part is still there. But
> > your idea definitely does *not* work unless you use a single CID
> > sequence for the whole main xact; and I'm still wondering if there's
Alvaro Herrera wrote:
> On Wed, Jun 02, 2004 at 12:23:37PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
>
> > > If we go with a global CID counter then we don't have to add that step.
> >
> > Seems Alvaro is already using a global counter.
>
> I think I stated already that I'm in fact using i
On Wed, Jun 02, 2004 at 12:23:37PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > If we go with a global CID counter then we don't have to add that step.
>
> Seems Alvaro is already using a global counter.
I think I stated already that I'm in fact using it. Not sure why it
didn't show up in
On Wed, Jun 02, 2004 at 11:12:31AM -0400, Tom Lane wrote:
> A global CID counter would also simplify other visibility tests. Alvaro
> hasn't said anything about how he's doing visibility checks across
> different subxacts of the same main xact, but without global CID there
> would need to be some
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't understand why a single counter is needed for phantom xids. We
> > keep the cmin/cmax on the tuple already, and our own backend can look up
> > the xmin/xmax that goes with the phantom.
>
> Oh, so you're thinking of an intern
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't understand why a single counter is needed for phantom xids. We
> keep the cmin/cmax on the tuple already, and our own backend can look up
> the xmin/xmax that goes with the phantom.
Oh, so you're thinking of an internal table that provides a map
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Wed, Jun 02, 2004 at 09:52:28AM -0400, Tom Lane wrote:
> >> AFAICS your proposal does not support this. The two cursors' snapshots
> >> will differ only in the recorded current-cid for the outer transaction.
> >> If the subtrans h
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've been trying to think of ways to solve these problems by having a
> >> main xact and all its subxacts share a common CID sequence (ie, a
> >> subxact would have its own xid but would not start CID over at one).
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've been trying to think of ways to solve these problems by having a
>> main xact and all its subxacts share a common CID sequence (ie, a
>> subxact would have its own xid but would not start CID over at one).
>> If you assume that, th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> This is exactly the same argument as not being able to overwrite cmin.
>
> > Basically the phantom xid's are a shorthand for saying the tuple was
> > created by xid1 and deleted by xid2, both part of the same main
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, Jun 02, 2004 at 09:52:28AM -0400, Tom Lane wrote:
>> AFAICS your proposal does not support this. The two cursors' snapshots
>> will differ only in the recorded current-cid for the outer transaction.
>> If the subtrans has overwritten xmin/cmin,
On Wed, Jun 02, 2004 at 09:52:28AM -0400, Tom Lane wrote:
> BEGIN;
> DECLARE CURSOR c1 FOR SELECT * FROM a ...;
> INSERT INTO a VALUES(...); -- call this row x
> DECLARE CURSOR c2 FOR SELECT * FROM a ...;
> BEGIN;
> DELETE FROM a WHERE ...;-- assume
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is exactly the same argument as not being able to overwrite cmin.
> Basically the phantom xid's are a shorthand for saying the tuple was
> created by xid1 and deleted by xid2, both part of the same main
> transaction.
> A cursor
Alvaro Herrera wrote:
> > Also, we will need a phantom xid for every xid1/xid2 pair. You can't
> > just create one phantom xid per subtransaction because you must be able
> > to control independently commit/rollback rows based on the status of the
> > insert transaction.
>
> Oh, sure. This could
On Tue, Jun 01, 2004 at 11:17:40PM -0400, Bruce Momjian wrote:
> Basically the phantom xid's are a shorthand for saying the tuple was
> created by xid1 and deleted by xid2, both part of the same main
> transaction.
Hmm... this would spread the ugliness elsewhere (hopefully only
HeapTupleHeaderGet
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> You can't change xmin --- this would break visibility tests.
>
> > Basically the phantom xid's are a shorthand for saying the tuple was
> > created by xid1 and deleted by xid2, both part of the same main
> > trans
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You can't change xmin --- this would break visibility tests.
> Basically the phantom xid's are a shorthand for saying the tuple was
> created by xid1 and deleted by xid2, both part of the same main
> transaction.
That would be fine if
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > BEGIN; xid=1
> > INSERT a;
> > BEGIN; xid=2
> > INSERT b;
> > DELETE a; xid=3
> > COMMIT;
> > COMMIT;
>
> > When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> > replace it with xmin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> BEGIN; xid=1
> INSERT a;
> BEGIN; xid=2
> INSERT b;
> DELETE a; xid=3
> COMMIT;
> COMMIT;
> When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> replace it with xmin=3.
You can't change xm
On Tue, Jun 01, 2004 at 06:40:07PM -0400, Bruce Momjian wrote:
> So, we need a way to record the xmin and xmax while keeping cmin and
> cmax in the tuple header. My idea is for subtransactions to create
> additional xid's that represent the opposite of the commit state for
> changing tuples creat
26 matches
Mail list logo
