On 11 December 2012 03:01, Noah Misch n...@leadboat.com wrote:
On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote:
I think the current behavior, where we treat FREEZE as a hint, is just
awful. Regardless of whether the behavior is automatic or manually
requested, the idea that you
On Fri, Dec 21, 2012 at 06:47:56PM +, Simon Riggs wrote:
On 11 December 2012 03:01, Noah Misch n...@leadboat.com wrote:
Until these threads, I did not know that a relcache invalidation could trip
up
the WAL avoidance optimization, and now this. I poked at the relevant
relcache.c
On 21 December 2012 20:10, Noah Misch n...@leadboat.com wrote:
I thought of one case where we do currently forget rd_newRelfilenodeSubid:
BEGIN;
TRUNCATE t;
SAVEPOINT save;
TRUNCATE t;
ROLLBACK TO save;
That's a weird one. Aborting a subtransacton that sets it, when it was
already set.
On Sat, Dec 22, 2012 at 12:42:43AM +, Simon Riggs wrote:
On 21 December 2012 20:10, Noah Misch n...@leadboat.com wrote:
I thought of one case where we do currently forget rd_newRelfilenodeSubid:
BEGIN;
TRUNCATE t;
SAVEPOINT save;
TRUNCATE t;
ROLLBACK TO save;
That's a weird
On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote:
You know, I hadn't been taking that option terribly seriously, but
maybe we ought to reconsider it. It would certainly be simpler, and
as you point out, it's not really any worse from an MVCC point of view
than anything else we do.
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
Agreed, but that is also be a silent change of current behaviour.
Sure, proper MVCC for catalog entries would be a change, but I think
it's one which would actually reduce the surprises for our users. Today
we tell people we have
On Mon, Dec 10, 2012 at 08:32:53AM -0500, Stephen Frost wrote:
* Noah Misch (n...@leadboat.com) wrote:
On Fri, Dec 07, 2012 at 06:51:18PM -0500, Stephen Frost wrote:
Now, what I've honestly been hoping for on this thread was for someone
to speak up and point out why I'm wrong about this
On Sun, Dec 9, 2012 at 3:06 PM, Noah Misch n...@leadboat.com wrote:
I favor[1] unconditionally letting older snapshots see the new rows after the
CREATE+COPY transaction commits. To recap, making affected scans see an empty
table is as wrong as making them see those rows. Robert also
Noah,
* Noah Misch (n...@leadboat.com) wrote:
I agree we should be reticent to compromise correctness for convenience.
Compromising mere bug-compatibility, trading one incorrect behavior for
another incorrect behavior, is not as bad. Furthermore, today's behavior in
question is not something
* Robert Haas (robertmh...@gmail.com) wrote:
You know, I hadn't been taking that option terribly seriously, but
maybe we ought to reconsider it. It would certainly be simpler, and
as you point out, it's not really any worse from an MVCC point of view
than anything else we do. Moreover, it
On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote:
I think the current behavior, where we treat FREEZE as a hint, is just
awful. Regardless of whether the behavior is automatic or manually
requested, the idea that you might get the optimization or not
depending on the timing of
On Mon, Dec 10, 2012 at 08:54:04PM -0500, Stephen Frost wrote:
I agree that it's unlikely that
applications are depending on today's behavior of TRUNCATE making
concurrent transactions see an empty table, but it does *not* follow
that applications *won't* start depending on this new behavior
On Mon, Dec 10, 2012 at 7:02 PM, Stephen Frost sfr...@snowman.net wrote:
I continue to hold that this could end up being a slippery slope for us
to go down wrt 'correctness' vs. 'do whatever the user wants'. If we
keep this to only COPY and where the table has to be truncated/created
in the
On Mon, 2012-12-10 at 08:16 -0500, Stephen Frost wrote:
I'm trying to figure out why there are all the constraints around this
command to begin with. If we're going to support this, why do we
require the user to create or truncate the table in the same
transaction? Clearly that's going to
On 8 December 2012 22:18, Stephen Frost sfr...@snowman.net wrote:
So the committed feature does address the visibility issue.
Not hardly. It lets a user completely violate the basic rules of the
overall database. The *correct* solution to this problem is to actually
*fix* it, by setting it
On Wed, Dec 05, 2012 at 07:43:08PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis pg...@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
On Fri, Dec 07, 2012 at 06:51:18PM -0500, Stephen Frost wrote:
* Jeff Davis (pg...@j-davis.com) wrote:
Most of your concerns seem to be related to freezing, and I'm mostly
interested in HEAP_XMIN_COMMITTED optimizations. So I think we're
talking past each other.
My concern is about this
On 7 December 2012 23:51, Stephen Frost sfr...@snowman.net wrote:
Jeff,
* Jeff Davis (pg...@j-davis.com) wrote:
Most of your concerns seem to be related to freezing, and I'm mostly
interested in HEAP_XMIN_COMMITTED optimizations. So I think we're
talking past each other.
My concern is
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
Visibility of pre-hinted data is an issue and because of that we
previously agreed that it would be allowed only when explicitly
requested by the user, which has been implemented as the FREEZE option
on COPY. This then makes it identical to
On 4 December 2012 20:38, Jeff Davis pg...@j-davis.com wrote:
Even if it is, I would
think that a sufficiently narrow case -- such as CTAS outside of a
transaction block -- would be safe
CTAS would be safe to do that with. CLUSTER and VACUUM FULL are already done.
Outside of a transaction
On Thu, 2012-12-06 at 22:34 -0500, Stephen Frost wrote:
* Jeff Davis (pg...@j-davis.com) wrote:
That is documented in the committed patch -- it's a trade, basically
saying that you lose isolation but avoid extra writes. It seems
reasonable that the user gets this behavior if specifically
Jeff,
* Jeff Davis (pg...@j-davis.com) wrote:
Most of your concerns seem to be related to freezing, and I'm mostly
interested in HEAP_XMIN_COMMITTED optimizations. So I think we're
talking past each other.
My concern is about this patch/capability as a whole. I agree that the
hint bit
On 6 December 2012 00:43, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis pg...@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
On 4 December 2012 20:38, Jeff Davis pg...@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:
...
Hi,
On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
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
On 6 December 2012 13:12, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
On the subject of that patch. I am not a big fan of only
On 2012-12-06 14:07:32 +, Simon Riggs wrote:
On 6 December 2012 13:12, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
On the
On 6 December 2012 14:12, Andres Freund and...@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.
* Robert Haas (robertmh...@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
* Simon Riggs (si...@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
On Thu, 2012-12-06 at 11:55 -0500, Stephen Frost wrote:
* Robert Haas (robertmh...@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
On 6 December 2012 17:02, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@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
On Thu, 2012-12-06 at 18:16 +, 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
Jeff,
* Jeff Davis (pg...@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
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;
* Jeff Davis (pg...@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
On Thu, 2012-12-06 at 20:12 -0500, Stephen Frost wrote:
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...
Freezing does lose information, but I
Jeff,
* Jeff Davis (pg...@j-davis.com) wrote:
On Thu, 2012-12-06 at 20:12 -0500, Stephen Frost wrote:
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
On Thu, 2012-12-06 at 20:49 -0500, Stephen Frost wrote:
I'm less concerned about the hint bits and more concerned about the
implications of the FrozenXID being used, which would make the rows
visible to other transactions even if they began before the rows were
loaded.
That is documented in
* Jeff Davis (pg...@j-davis.com) wrote:
That is documented in the committed patch -- it's a trade, basically
saying that you lose isolation but avoid extra writes. It seems
reasonable that the user gets this behavior if specifically requested.
Strictly speaking, it could actually be two
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis pg...@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 --
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis pg...@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
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
On 4 December 2012 01:34, Jeff Davis pg...@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
On Tue, 2012-12-04 at 10:15 +, Simon Riggs wrote:
On 4 December 2012 01:34, Jeff Davis pg...@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
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
Part of that patch was reverted later:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5457a130d3a66db807d1e0ee2b8e829321809b83
I assume that refers to the discussion
46 matches
Mail list logo
