On Sat, Dec 22, 2012 at 12:42:43AM +, Simon Riggs wrote:
> On 21 December 2012 20:10, Noah Misch 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
On 21 December 2012 20:10, Noah Misch 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.
The loss of
On Fri, Dec 21, 2012 at 06:47:56PM +, Simon Riggs wrote:
> On 11 December 2012 03:01, Noah Misch 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 code, and it
On 11 December 2012 03:01, Noah Misch 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 might get the
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 d
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 t
On Mon, Dec 10, 2012 at 7:02 PM, Stephen Frost 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 same transact
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 behavio
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 r
* 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
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 someth
On Sun, Dec 9, 2012 at 3:06 PM, Noah Misch 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 listed[2] that
> as a c
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 abou
* 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 concern and explain
> > how this patch addresses that issue. If
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 transactiona
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 abo
On Wed, Dec 05, 2012 at 07:43:08PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis 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 tha
On 8 December 2012 22:18, Stephen Frost 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 up such that
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
On 7 December 2012 23:51, Stephen Frost 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 about this p
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 sett
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 specifica
On 4 December 2012 20:38, Jeff Davis 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 block would be aut
* 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 diff
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 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 af
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 thou
* 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 se
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
> -
> begi
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 transactio
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 em
On 6 December 2012 17:02, Stephen Frost 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 misunderstand, or cause p
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 bein
* 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 understa
* 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 tabl
On 6 December 2012 14:12, Andres Freund 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. R
On 2012-12-06 14:07:32 +, Simon Riggs wrote:
> On 6 December 2012 13:12, Andres Freund 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 o
On 6 December 2012 13:12, Andres Freund 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 emitting a NOTICE if
>
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 4 December 2012 20:38, Jeff Davis 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:
>
> ... &&
> csta
On 6 December 2012 00:43, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis 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 na
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
Robert Haas writes:
> On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis 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
>> transac
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis 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
On Tue, 2012-12-04 at 10:15 +, Simon Riggs wrote:
> On 4 December 2012 01:34, Jeff Davis 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 discus
On 4 December 2012 01:34, Jeff Davis 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 withi
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 here
47 matches
Mail list logo
