Commits 8de72b and 5457a1 (COPY FREEZE)
Part of that patch was reverted later:
I assume that refers to the discussion here:
http://archives.postgresql.org/pgsql-hackers/2012-02/msg01177.php
But that was quite a while ago, so is there a more recent discussion
that prompted this commit now?
I am a little confused about the case where setting HEAP_XMIN_COMMITTED
when loading the table in the same transaction is wrong. There was some
discussion about subtransactions, but those problems only seemed to
appear when the CREATE and the INSERT/COPY happened in different
subtransactions.
So, I guess my question is, why the partial revert?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4 December 2012 01:34, Jeff Davis <pgsql@j-davis.com> wrote:
I assume that refers to the discussion here:
http://archives.postgresql.org/pgsql-hackers/2012-02/msg01177.php
But that was quite a while ago, so is there a more recent discussion
that prompted this commit now?
Yes, this was discussed within the last month, thread "TRUNCATE SERIALIZABLE..."
The patch for that was already posted, so I committed it.
I am a little confused about the case where setting HEAP_XMIN_COMMITTED
when loading the table in the same transaction is wrong. There was some
discussion about subtransactions, but those problems only seemed to
appear when the CREATE and the INSERT/COPY happened in different
subtransactions.So, I guess my question is, why the partial revert?
Well, first, because I realised that it wasn't wanted. I was
re-reading the threads trying to figure out a way to help the checksum
patch further.
Second, because I realised why it wasn't wanted. Setting
HEAP_XMIN_COMMITTED causes MVCC violations within the transaction
issuing the COPY. Accepting the MVCC violation requires explicit
consent from user. If we have that, we may as well set everything we
can. So there's no middle ground. Nothing, or all frozen. We could
change that, but it would require some complex tweaks to tqual
routines, which I tried and was not happy with, since they would need
to get more complex. It's possible a route through that minefield
exists. I'm inclined to believe other approaches are more likely to
yield benefit.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2012-12-04 at 10:15 +0000, Simon Riggs wrote:
On 4 December 2012 01:34, Jeff Davis <pgsql@j-davis.com> wrote:
I assume that refers to the discussion here:
http://archives.postgresql.org/pgsql-hackers/2012-02/msg01177.php
But that was quite a while ago, so is there a more recent discussion
that prompted this commit now?Yes, this was discussed within the last month, thread "TRUNCATE SERIALIZABLE..."
The patch for that was already posted, so I committed it.
Thank you for pointing me toward that thread.
While experimenting with COPY FREEZE, I noticed something:
The simple case of BEGIN; CREATE TABLE ...; COPY ... WITH (FREEZE);
doesn't meet the pre-conditions. It only meets the conditions if
preceded by a TRUNCATE, which all of the tests do. I looked into it, and
I think the test:
... &&
cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId()
should be:
... &&
(cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId() ||
cstate->rel->rd_createSubid == GetCurrentSubTransactionId())
(haven't tested). Another option to consider is that
rd_newRelfilenodeSubid could be set on newly-created tables as well as
newly-truncated tables.
Also, I recommend a hint along with the NOTICE when the pre-conditions
aren't met to tell the user what they need to do. Perhaps something
like:
"Create or truncate the table in the same transaction as COPY
FREEZE."
The documentation could expand on that, clarifying that a TRUNCATE in
the same transaction (perhaps even ALTER?) allows a COPY FREEZE.
The code comment could be improved a little, while we're at it:
"Note that the stronger test of exactly which subtransaction created
it is crucial for correctness of this optimisation."
is a little vague, can you explain using the reasoning from the thread?
I would say something like:
"The transaction and subtransaction creating or truncating the table
must match that of the COPY FREEZE. Otherwise, it could mix tuples from
different transactions together, and it would be impossible to
distinguish them for the purposes of atomicity."
I am a little confused about the case where setting HEAP_XMIN_COMMITTED
when loading the table in the same transaction is wrong. There was some
discussion about subtransactions, but those problems only seemed to
appear when the CREATE and the INSERT/COPY happened in different
subtransactions.So, I guess my question is, why the partial revert?
Well, first, because I realised that it wasn't wanted. I was
re-reading the threads trying to figure out a way to help the checksum
patch further.Second, because I realised why it wasn't wanted. Setting
HEAP_XMIN_COMMITTED causes MVCC violations within the transaction
issuing the COPY.
After reading that thread, I still don't understand why it's unsafe to
set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would
think that a sufficiently narrow case -- such as CTAS outside of a
transaction block -- would be safe, along with some slightly broader
cases (like BEGIN; CREATE TABLE; INSERT/COPY).
But perhaps that requires more discussion. I was just curious if there
was a concrete problem that I was missing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pgsql@j-davis.com> wrote:
After reading that thread, I still don't understand why it's unsafe to
set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would
think that a sufficiently narrow case -- such as CTAS outside of a
transaction block -- would be safe, along with some slightly broader
cases (like BEGIN; CREATE TABLE; INSERT/COPY).
I haven't looked at the committed patch - which seemed a bit
precipitous to me given the stage the discussion was at - but I
believe the general issue with HEAP_XMIN_COMMITTED is that there might
be other snapshots in the same transaction, for example from open
cursors.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pgsql@j-davis.com> wrote:
After reading that thread, I still don't understand why it's unsafe to
set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would
think that a sufficiently narrow case -- such as CTAS outside of a
transaction block -- would be safe, along with some slightly broader
cases (like BEGIN; CREATE TABLE; INSERT/COPY).
I haven't looked at the committed patch - which seemed a bit
precipitous to me given the stage the discussion was at - but I
believe the general issue with HEAP_XMIN_COMMITTED is that there might
be other snapshots in the same transaction, for example from open
cursors.
From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED
couldn't possibly be from its own transaction, and thus it doesn't make
the tests that would be appropriate for a tuple that is from the current
transaction. Maybe it's all right anyway (i.e. if we should always treat
such a tuple as good) but I don't recall exactly what's tested in those
paths.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2012-12-05 at 19:43 -0500, Tom Lane wrote:
From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED
couldn't possibly be from its own transaction, and thus it doesn't make
the tests that would be appropriate for a tuple that is from the current
transaction. Maybe it's all right anyway (i.e. if we should always treat
such a tuple as good) but I don't recall exactly what's tested in those
paths.
Oh, I see, it probably warrants some more discussion. It seems like we
could solve these problems if we narrow the conditions enough.
Anyway, the partial revert looks good, and the commit message seems
appropriate (essentially, the code got ahead of the discussion).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6 December 2012 00:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pgsql@j-davis.com> wrote:
After reading that thread, I still don't understand why it's unsafe to
set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would
think that a sufficiently narrow case -- such as CTAS outside of a
transaction block -- would be safe, along with some slightly broader
cases (like BEGIN; CREATE TABLE; INSERT/COPY).I haven't looked at the committed patch - which seemed a bit
precipitous to me given the stage the discussion was at - but I
believe the general issue with HEAP_XMIN_COMMITTED is that there might
be other snapshots in the same transaction, for example from open
cursors.From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED
couldn't possibly be from its own transaction, and thus it doesn't make
the tests that would be appropriate for a tuple that is from the current
transaction. Maybe it's all right anyway (i.e. if we should always treat
such a tuple as good) but I don't recall exactly what's tested in those
paths.
Yes.
We'd need to add in a call to
TransactionIdIsCurrentTransactionId(xmin), which is basically just
wasted path in 99% of use cases.
I've looked at optimising TransactionIdIsCurrentTransactionId() with
what appears some vague success. Attached patch gives more consistent
response.
The other thing to do is to have a backend local flag that gets set
when we use the HEAP_XMIN_COMMITTED anywhere. When not set we just
skip past the TransactionIdIsCurrent test altogether.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
optimize_transactionidiscurrent.v1.patchapplication/octet-stream; name=optimize_transactionidiscurrent.v1.patchDownload+31-6
On 4 December 2012 20:38, Jeff Davis <pgsql@j-davis.com> wrote:
The simple case of BEGIN; CREATE TABLE ...; COPY ... WITH (FREEZE);
doesn't meet the pre-conditions. It only meets the conditions if
preceded by a TRUNCATE, which all of the tests do. I looked into it, and
I think the test:... &&
cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId()should be:
... &&
(cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId() ||
cstate->rel->rd_createSubid == GetCurrentSubTransactionId())(haven't tested). Another option to consider is that
rd_newRelfilenodeSubid could be set on newly-created tables as well as
newly-truncated tables.
I'll expand the test above and add new regression. I focused on
correctness ahead of a wide use case and missed this.
Also, I recommend a hint along with the NOTICE when the pre-conditions
aren't met to tell the user what they need to do. Perhaps something
like:"Create or truncate the table in the same transaction as COPY
FREEZE."
OK, will add hint.
The documentation could expand on that, clarifying that a TRUNCATE in
the same transaction (perhaps even ALTER?) allows a COPY FREEZE.The code comment could be improved a little, while we're at it:
"Note that the stronger test of exactly which subtransaction created
it is crucial for correctness of this optimisation."is a little vague, can you explain using the reasoning from the thread?
I would say something like:"The transaction and subtransaction creating or truncating the table
must match that of the COPY FREEZE. Otherwise, it could mix tuples from
different transactions together, and it would be impossible to
distinguish them for the purposes of atomicity."
OK, will try.
After reading that thread, I still don't understand why it's unsafe to
set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would
think that a sufficiently narrow case -- such as CTAS outside of a
transaction block -- would be safe, along with some slightly broader
cases (like BEGIN; CREATE TABLE; INSERT/COPY).
It *could* be safe, but needs changes to visibility rules, which as
explained I had not been able to optimise sufficiently.
The code is easy enough to add back in at the time it is sufficiently
well optimised and we all agree.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
On the subject of that patch. I am not a big fan of only emitting a NOTICE if
FREEZE wasn't properly used:
+ if (cstate->freeze && (hi_options & HEAP_INSERT_FROZEN) == 0)
+ ereport(NOTICE,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("FREEZE option specified but pre-conditions not met")));
+Imo it should fail. Imagine adding FREEZE to the loading part of your
application and not noticing the optimization broke because somebody
else changed something in another part of the loading procedure.
Not sure whether that discussed previously.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6 December 2012 13:12, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
On the subject of that patch. I am not a big fan of only emitting a NOTICE if
FREEZE wasn't properly used:+ if (cstate->freeze && (hi_options & HEAP_INSERT_FROZEN) == 0) + ereport(NOTICE, + (errcode(ERRCODE_INVALID_PARAMETER_VALUE), + errmsg("FREEZE option specified but pre-conditions not met"))); +Imo it should fail. Imagine adding FREEZE to the loading part of your
application and not noticing the optimization broke because somebody
else changed something in another part of the loading procedure.Not sure whether that discussed previously.
It was. Only Robert and I spoke about that.
Also imagine having to analyze your code in detail to reevaluate the
exact optimisation required each time. This way you get to add FREEZE
and have it work always, with feedback if its not optimized.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2012-12-06 14:07:32 +0000, Simon Riggs wrote:
On 6 December 2012 13:12, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
On the subject of that patch. I am not a big fan of only emitting a NOTICE if
FREEZE wasn't properly used:+ if (cstate->freeze && (hi_options & HEAP_INSERT_FROZEN) == 0) + ereport(NOTICE, + (errcode(ERRCODE_INVALID_PARAMETER_VALUE), + errmsg("FREEZE option specified but pre-conditions not met"))); +Imo it should fail. Imagine adding FREEZE to the loading part of your
application and not noticing the optimization broke because somebody
else changed something in another part of the loading procedure.Not sure whether that discussed previously.
It was. Only Robert and I spoke about that.
Also imagine having to analyze your code in detail to reevaluate the
exact optimisation required each time. This way you get to add FREEZE
and have it work always, with feedback if its not optimized.
I remain unconvinced by that argument, but if I am alone with this
ok. Could we at least make it a WARNING? Nobody ever reads NOTICEs
because it contains so much noise. And this is isn't noise. Its a bug
on the client side.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6 December 2012 14:12, Andres Freund <andres@2ndquadrant.com> wrote:
I remain unconvinced by that argument, but if I am alone with this
ok. Could we at least make it a WARNING? Nobody ever reads NOTICEs
because it contains so much noise. And this is isn't noise. Its a bug
on the client side.
It's not a bug. Requesting a useful, but not critical optimisation is
just a hint. The preconditions are not easy to understand, so I see no
reason to punish people that misunderstand, or cause programs to fail
in ways that need detailed understanding to make them work again.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote:
I haven't looked at the committed patch - which seemed a bit
Disclaimer- neither have I, but..
When I last recall this discussion (likely in some bar in Europe), the
problem was also that an independent session would be able to:
a) see that the table exists (due to SnapshotNow being used for lookups)
b) see rows in the table
Part 'a' is something which I think would be good to fix (but hard),
and it sounds like this patch might make part 'b' happen, which I think
makes the part 'a' problem worse. I'm guessing this isn't a problem for
the TRUNCATE case because the second session would still be looking at
the pre-TRUNCATE files on disk, right? Is that reference to exactly
which files on disk to look at being used to address the CREATE problem
too..?
That said, I love the idea of having a way to drop tuples in w/o having
to go back and rewrite them three times..
Thanks,
Stephen
* Simon Riggs (simon@2ndQuadrant.com) wrote:
It's not a bug. Requesting a useful, but not critical optimisation is
just a hint. The preconditions are not easy to understand, so I see no
reason to punish people that misunderstand, or cause programs to fail
in ways that need detailed understanding to make them work again.
I tend to agree with Andres on this one. This feels a bit like
accepting a command but then not actually following-through on it
if it turns out we can't actually do it. If it's truely an optimization
(and I suspect my other email/question might provide insight into that),
then it should be something we can 'just do' without needing to be asked
to do it, along the same lines of not WAL'ing when the appropriate
conditions are met (table created in this transaction, etc, etc).
Thanks,
Stephen
On Thu, 2012-12-06 at 11:55 -0500, Stephen Frost wrote:
* Robert Haas (robertmhaas@gmail.com) wrote:
When I last recall this discussion (likely in some bar in Europe), the
problem was also that an independent session would be able to:a) see that the table exists (due to SnapshotNow being used for lookups)
b) see rows in the tablePart 'a' is something which I think would be good to fix (but hard),
and it sounds like this patch might make part 'b' happen, which I think
makes the part 'a' problem worse. I'm guessing this isn't a problem for
the TRUNCATE case because the second session would still be looking at
the pre-TRUNCATE files on disk, right? Is that reference to exactly
which files on disk to look at being used to address the CREATE problem
too..?
That isn't a problem, because the other session won't see the tuple in
pg_class until the creating transaction commits, at which point the rows
have committed, too (because this would only kick in when the rows are
loaded in the same transaction as the CREATE).
So, yes, it's like TRUNCATE in that regard.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6 December 2012 17:02, Stephen Frost <sfrost@snowman.net> wrote:
* Simon Riggs (simon@2ndQuadrant.com) wrote:
It's not a bug. Requesting a useful, but not critical optimisation is
just a hint. The preconditions are not easy to understand, so I see no
reason to punish people that misunderstand, or cause programs to fail
in ways that need detailed understanding to make them work again.I tend to agree with Andres on this one. This feels a bit like
accepting a command but then not actually following-through on it
if it turns out we can't actually do it. If it's truely an optimization
(and I suspect my other email/question might provide insight into that),
then it should be something we can 'just do' without needing to be asked
to do it, along the same lines of not WAL'ing when the appropriate
conditions are met (table created in this transaction, etc, etc).
That depends whether its a command or a do-if-possible hint. Its
documented as the latter.
Similar to the way VACUUM tries to truncate a relation, but gives up
if it can't. And on an even closer example, VACUUM FREEZE itself,
which doesn't guarantee that all rows are frozen at the end of it...
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2012-12-06 at 18:16 +0000, Simon Riggs wrote:
I tend to agree with Andres on this one. This feels a bit like
accepting a command but then not actually following-through on it
if it turns out we can't actually do it. If it's truely an optimization
(and I suspect my other email/question might provide insight into that),
then it should be something we can 'just do' without needing to be asked
to do it, along the same lines of not WAL'ing when the appropriate
conditions are met (table created in this transaction, etc, etc).That depends whether its a command or a do-if-possible hint. Its
documented as the latter.Similar to the way VACUUM tries to truncate a relation, but gives up
if it can't. And on an even closer example, VACUUM FREEZE itself,
which doesn't guarantee that all rows are frozen at the end of it...
Also, if the set of conditions changes in the future, we would have a
problem if that caused new errors to appear.
I think a WARNING might make more sense than a NOTICE, but I don't have
a strong opinion about that.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jeff,
* Jeff Davis (pgsql@j-davis.com) wrote:
That isn't a problem, because the other session won't see the tuple in
pg_class until the creating transaction commits, at which point the rows
have committed, too (because this would only kick in when the rows are
loaded in the same transaction as the CREATE).
See, that's what I originally thought but was corrected on it at one
point (by Tom, iirc).
I just did a simple test against 9.2.1 using serializable mode. In this
mode, if you do something like this:
session a
---------
begin;
session b
---------
begin;
create table q (a integer);
insert into q values (1);
commit;
select * from q;
You'll get an empty table. That's not great, but it's life- once
something is in pg_class, all sessions can see it because the table
lookups are done using SnapshotNow and aren't truely transactional, but
at least you can't see any rows in the table because the individual rows
are marked with the transaction ID which created them and we can't see
them in our transaction that started before the table was created.
It sounds like, with this patch/change, this behavior would change.
Now, I'm not necessairly against this, but it's clearly something
different than what we had before and might be an issue for some. If,
in the general case, we're actually 'ok' with this, I'd ask why we don't
simply do it by default..? If we're *not* 'ok' with it, perhaps we
shouldn't be doing it at all...
If we fix the bigger issue (which, as I understand it from various
discussions with Tom and Robert, is very difficult), then this whole
problem goes away entirely. I always figured/expected that to be how
we'd fix this, not just punt on the issue and tell the user "sure, you
can do this, hope you know what you're doing...".
Thanks,
Stephen
On Thu, 2012-12-06 at 14:18 -0500, Stephen Frost wrote:
begin;
You need to do a SELECT here to actually get a snapshot.
session b
---------
begin;
create table q (a integer);
insert into q values (1);
commit;select * from q;
You'll get an empty table. That's not great, but it's life- once
something is in pg_class, all sessions can see it because the table
lookups are done using SnapshotNow and aren't truely transactional, but
at least you can't see any rows in the table because the individual rows
are marked with the transaction ID which created them and we can't see
them in our transaction that started before the table was created.It sounds like, with this patch/change, this behavior would change.
No, it would not change. Session A would see that the table exists and
see that the rows' inserting transaction (in Session B) committed. That
is correct because the inserting transaction *did* commit, and it's the
same as we have now.
However, the rows will *not* be visible, because the serializable
snapshot doesn't contain the inserting transaction.
Think about the current behavior: right after the commit, another select
could come along and set all those hint bits anyway. Even if the hint
bits aren't set, it will do a CLOG lookup and find that the transaction
committed.
The change being proposed is just to set those hint bits preemptively,
because the fate of the INSERT is identical to the fate of the CREATE
(they are in the same transaction). There will be no observable problem
outside of that CREATE+INSERT transaction. The only catch is what to do
about visibility of the tuples when still inside the transaction (which
is not a problem for transactions doing a simple load).
The interesting thing about HEAP_XMIN_COMMITTED is that it can be set
preemptively if we know that the transaction will actually commit (aside
from the visibility issues within the transaction). Even if the
transaction doesn't commit, it would still be possible to clean out the
dead tuples with a VACUUM, because no information has really been lost
in the process. So there may yet be some kind of safe protocol to set
these even during a load into an existing table...
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Jeff Davis (pgsql@j-davis.com) wrote:
However, the rows will *not* be visible, because the serializable
snapshot doesn't contain the inserting transaction.
That's what we've got now and what would be expected, however...
Think about the current behavior: right after the commit, another select
could come along and set all those hint bits anyway. Even if the hint
bits aren't set, it will do a CLOG lookup and find that the transaction
committed.
The command is 'FREEZE', which sounded to me like the transaction ID
would be set to FrozenXID, meaning that we wouldn't be able to tell if
the inserting transaction was before or after ours...
Your analysis of the hint bits themselves sounds reasonable but it seems
independent of the issue regarding setting the actual transaction ID.
Thanks,
Stephen
