On 01/06/2014 08:29 PM, Andres Freund wrote:
On 2014-01-06 12:40:25 -0500, Robert Haas wrote:
On Mon, Jan 6, 2014 at 11:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 11:08:41 -0500, Robert Haas wrote:
Yea. But at least it would fail reliably instead of just under
concurrency
On 2014-01-07 10:45:24 +0200, Heikki Linnakangas wrote:
Overall, I'm leaning towards biting the bullet and always detoasting
everything in master. Probably best to just leave the stable branches alone.
If we're doing something coarse grained as this, I agree, it should be
master only.
I
On Jan7, 2014, at 09:45 , Heikki Linnakangas hlinnakan...@vmware.com wrote:
Overall, I'm leaning towards biting the bullet and always detoasting
everything in master. Probably best to just leave the stable branches alone.
+1
The fact that de-TOAST-ing can happen lazily is, at least to me, an
On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-02 16:05:09 -0500, Robert Haas wrote:
On Thu, Jan 2, 2014 at 3:19 PM, Andres Freund and...@2ndquadrant.com wrote:
I was wondering if we could somehow arrange to not
release the subtransaction's
On 2014-01-06 09:10:48 -0500, Robert Haas wrote:
On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund and...@2ndquadrant.com wrote:
I think the only principled fixes are to either retain the lock or
forcibly detoast before releasing it.
I don't think that's sufficient. Unless I miss something
On 2014-01-06 09:43:45 -0500, Robert Haas wrote:
I actually vote for not allowing doing so at all by erroring out when
accessing a plpgsql variable created in an aborted subxact, unless you
explicitly signal that you want to do do so by calling some function
deleting the information about
On Mon, Jan 6, 2014 at 9:19 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 09:10:48 -0500, Robert Haas wrote:
On Thu, Jan 2, 2014 at 4:15 PM, Andres Freund and...@2ndquadrant.com wrote:
I think the only principled fixes are to either retain the lock or
forcibly detoast before
On Mon, Jan 6, 2014 at 9:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 09:43:45 -0500, Robert Haas wrote:
I actually vote for not allowing doing so at all by erroring out when
accessing a plpgsql variable created in an aborted subxact, unless you
explicitly signal that
On 2014-01-06 11:08:41 -0500, Robert Haas wrote:
On Mon, Jan 6, 2014 at 9:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 09:43:45 -0500, Robert Haas wrote:
I actually vote for not allowing doing so at all by erroring out when
accessing a plpgsql variable created in an
On Mon, Jan 6, 2014 at 11:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 11:08:41 -0500, Robert Haas wrote:
On Mon, Jan 6, 2014 at 9:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 09:43:45 -0500, Robert Haas wrote:
I actually vote for not allowing doing
Robert Haas robertmh...@gmail.com writes:
Is forcibly detoast everything a complete no-go? I realize there
are performance concerns with that approach, but I'm not sure how
realistic a worry it actually is.
It's certainly possible to think of scenarios under which it'd be painful,
eg, you
On 2014-01-06 12:40:25 -0500, Robert Haas wrote:
On Mon, Jan 6, 2014 at 11:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-06 11:08:41 -0500, Robert Haas wrote:
Yea. But at least it would fail reliably instead of just under
concurrency and other strange circumstances - and
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-06 12:40:25 -0500, Robert Haas wrote:
Is forcibly detoast everything a complete no-go? I realize there
are performance concerns with that approach, but I'm not sure how
realistic a worry it actually is.
The scenario I am primarily
On 1/2/14, 1:32 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
The simplest fix would be to just detoast everything on assignment but
that was rejected on performance grounds in that previous thread. I
don't see any other realistic way to fix this, however, so maybe we
On 1/6/14, 2:21 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-06 12:40:25 -0500, Robert Haas wrote:
Is forcibly detoast everything a complete no-go? I realize there
are performance concerns with that approach, but I'm not sure how
realistic a worry it actually
On Mon, Jan 6, 2014 at 8:02 PM, Jim Nasby j...@nasby.net wrote:
If concurrent TRUNCATE isn't safe outside of this case then why do we allow
it? IE: why doesn't TRUNCATE exclusive lock the relation?
It *does*.
The problem is that the *other* transaction that's reading the
relation can still
On Fri, Jan 3, 2014 at 9:05 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Jan 3, 2014 at 12:51 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
Do you think we should detoast the local variable before
Hi All,
Test case:
drop table if exists t;
create table t(c text);
insert into t values ('x'), (repeat(md5('abcdefghijklmnop'), 1));
select pg_column_size(c), pg_column_size(c || '') FROM t;
CREATE OR REPLACE FUNCTION copy_toast_out() RETURNS VOID AS $$
declare
v text;
BEGIN
On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
Hi All,
Test case:
drop table if exists t;
create table t(c text);
insert into t values ('x'), (repeat(md5('abcdefghijklmnop'), 1));
select pg_column_size(c), pg_column_size(c || '') FROM t;
CREATE OR REPLACE FUNCTION copy_toast_out() RETURNS
Heikki Linnakangas hlinnakan...@vmware.com writes:
The simplest fix would be to just detoast everything on assignment but
that was rejected on performance grounds in that previous thread. I
don't see any other realistic way to fix this, however, so maybe we
should just bite the bullet and
On 2014-01-02 21:21:15 +0200, Heikki Linnakangas wrote:
I don't see any other realistic way to fix this, however, so maybe we
should just bite the bullet and do it anyway.
We could remember the subtransaction a variable was created in and error
out if it the creating subtransaction aborted and
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-02 21:21:15 +0200, Heikki Linnakangas wrote:
I don't see any other realistic way to fix this, however, so maybe we
should just bite the bullet and do it anyway.
We could remember the subtransaction a variable was created in and error
On 2014-01-02 15:00:58 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-02 21:21:15 +0200, Heikki Linnakangas wrote:
I don't see any other realistic way to fix this, however, so maybe we
should just bite the bullet and do it anyway.
We could remember the
On Thu, Jan 2, 2014 at 3:19 PM, Andres Freund and...@2ndquadrant.com wrote:
I was wondering if we could somehow arrange to not
release the subtransaction's AccessShareLock on the table, as long as it
was protecting toasted references someplace.
Sounds fairly ugly...
I think the only
On 2014-01-02 16:05:09 -0500, Robert Haas wrote:
On Thu, Jan 2, 2014 at 3:19 PM, Andres Freund and...@2ndquadrant.com wrote:
I was wondering if we could somehow arrange to not
release the subtransaction's AccessShareLock on the table, as long as it
was protecting toasted references
On Fri, Jan 3, 2014 at 12:51 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
Hi All,
Test case:
drop table if exists t;
create table t(c text);
insert into t values ('x'), (repeat(md5('abcdefghijklmnop'), 1));
select
26 matches
Mail list logo
