Sorry overlooked this.
At Thu, 14 Feb 2019 16:35:45 +0100, Peter Eisentraut
wrote in
<84c6bcc4-026f-a44f-5726-e8035f4d1...@2ndquadrant.com>
> On 08/02/2019 04:04, Kyotaro HORIGUCHI wrote:
> > By the way, I'm confused to see that attributes that don't want
> > to go external are marked as 'x' in
On 2019-02-08 04:04, Kyotaro HORIGUCHI wrote:
> Hi, I got redirected here by a kind suggestion by Tom.
I have committed my patch, which also addresses the issue you had in
your other thread.
I rest of these discussions have merit but are not really dependent on
my patch.
--
Peter Eisentraut
On 2/8/19, Kyotaro HORIGUCHI wrote:
> [v2 patch]
I poked this around a bit and found that this mechanism only works for
bootstrapped tables, as those are the only ones where we can scribble
on pg_attribute entries directly during bootstrap. As such, with this
patch we cannot perform ALTER TABLE
On 08/02/2019 04:04, Kyotaro HORIGUCHI wrote:
> By the way, I'm confused to see that attributes that don't want
> to go external are marked as 'x' in system catalogs. Currently
> (putting aside its necessity) the following operation ends with
> successful attaching a new TOAST relation, which we re
I have a couple of thoughts here.
On Fri, Feb 8, 2019 at 4:35 AM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Fri, 08 Feb 2019 12:03:31 +0900 (Tokyo Standard Time), Kyotaro
> HORIGUCHI wrote in <
> 20190208.120331.167280496.horiguchi.kyot...@lab.ntt.co.jp>
> > By the way, I'm
At Fri, 08 Feb 2019 12:03:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190208.120331.167280496.horiguchi.kyot...@lab.ntt.co.jp>
> By the way, I'm confused to see that attributes that don't want
> to go external are marked as 'x' in system catalogs. Currently
> (putting aside its
Hi, I got redirected here by a kind suggestion by Tom.
At Fri, 28 Sep 2018 22:58:36 +0200, Peter Eisentraut
wrote in
<61666008-d1cd-7a66-33c8-215449f5d...@2ndquadrant.com>
> On 21/08/2018 17:24, Andres Freund wrote:
> >> Attached is a patch that instead moves those special cases into
> >> needs
On 21/08/2018 17:24, Andres Freund wrote:
>> Attached is a patch that instead moves those special cases into
>> needs_toast_table(), which was one of the options suggested by Andres.
>> There were already similar checks there, so I guess this makes a bit of
>> sense.
> The big difference is that th
On 2018-Sep-28, Andres Freund wrote:
> On 2018-09-28 16:06:30 -0300, Alvaro Herrera wrote:
> > On 2018-Aug-21, Andres Freund wrote:
> >
> > > I still think it's wrong to work around this than to actually fix the
> > > issue with pg_attribute not having a toast table.
> >
> > FWIW I'm still bothe
On 2018-09-28 16:06:30 -0300, Alvaro Herrera wrote:
> On 2018-Aug-21, Andres Freund wrote:
>
> > On 2018-08-21 17:04:41 +0200, Peter Eisentraut wrote:
> >
> > > That doesn't solve the original problem, which is being able to set
> > > reloptions on pg_attribute, because pg_attribute doesn't have a
On 2018-Aug-21, Andres Freund wrote:
> On 2018-08-21 17:04:41 +0200, Peter Eisentraut wrote:
>
> > That doesn't solve the original problem, which is being able to set
> > reloptions on pg_attribute, because pg_attribute doesn't have a toast
> > table but would need one according to existing rules.
On 2018-08-21 17:04:41 +0200, Peter Eisentraut wrote:
> On 20/08/2018 15:34, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2018-08-20 14:38:25 +0200, Peter Eisentraut wrote:
> >>> Do you have an alternative in mind?
> >
> >> One is to just not do anything. I'm not sure I'm on board with the g
On 20/08/2018 15:34, Tom Lane wrote:
> Andres Freund writes:
>> On 2018-08-20 14:38:25 +0200, Peter Eisentraut wrote:
>>> Do you have an alternative in mind?
>
>> One is to just not do anything. I'm not sure I'm on board with the goal
>> of changing things to make DDL on system tables more palata
Andres Freund writes:
> On 2018-08-20 14:38:25 +0200, Peter Eisentraut wrote:
>> Do you have an alternative in mind?
> One is to just not do anything. I'm not sure I'm on board with the goal
> of changing things to make DDL on system tables more palatable.
FWIW, I agree with doing as little as p
On 2018-08-20 14:38:25 +0200, Peter Eisentraut wrote:
> On 20/08/2018 12:48, Andres Freund wrote:
> > On 2018-08-20 11:37:49 +0900, Michael Paquier wrote:
> >> On Fri, Jul 13, 2018 at 11:05:10AM +0200, Peter Eisentraut wrote:
> >>> After reviewing that thread, I think my patch would still be releva
On 20/08/2018 12:48, Andres Freund wrote:
> On 2018-08-20 11:37:49 +0900, Michael Paquier wrote:
>> On Fri, Jul 13, 2018 at 11:05:10AM +0200, Peter Eisentraut wrote:
>>> After reviewing that thread, I think my patch would still be relevant.
>>> Because the pending proposal is to not add TOAST table
On Mon, Aug 20, 2018 at 12:43:20PM +0200, Peter Eisentraut wrote:
> Tests would require enabling allow_system_table_mods, which is
> PGC_POSTMASTER, so we couldn't do it inside the normal regression test
> suite. I'm not sure setting up a whole new test suite for this is worth it.
I forgot this p
On 2018-08-20 11:37:49 +0900, Michael Paquier wrote:
> On Fri, Jul 13, 2018 at 11:05:10AM +0200, Peter Eisentraut wrote:
> > After reviewing that thread, I think my patch would still be relevant.
> > Because the pending proposal is to not add TOAST tables to some catalogs
> > such as pg_attribute,
On 20/08/2018 04:37, Michael Paquier wrote:
> For 0002, indeed the patch is still
> seems relevant. The comment block at the beginning of
> create_toast_table should be updated. Some tests would also be nice to
> have.
Tests would require enabling allow_system_table_mods, which is
PGC_POSTMASTER
On Fri, Jul 13, 2018 at 11:05:10AM +0200, Peter Eisentraut wrote:
> After reviewing that thread, I think my patch would still be relevant.
> Because the pending proposal is to not add TOAST tables to some catalogs
> such as pg_attribute, so my original use case of allowing ALTER TABLE /
> SET on sy
On 28.06.18 10:14, Peter Eisentraut wrote:
> On 6/28/18 01:10, Michael Paquier wrote:
>> On Wed, Jun 27, 2018 at 01:37:33PM -0700, Andres Freund wrote:
>>> On 2018-06-27 22:31:30 +0200, Peter Eisentraut wrote:
I propose that we instead silently ignore attempts to add TOAST tables
to share
On 6/28/18 01:10, Michael Paquier wrote:
> On Wed, Jun 27, 2018 at 01:37:33PM -0700, Andres Freund wrote:
>> On 2018-06-27 22:31:30 +0200, Peter Eisentraut wrote:
>>> I propose that we instead silently ignore attempts to add TOAST tables
>>> to shared and system catalogs after bootstrapping.
>>
>>
On Wed, Jun 27, 2018 at 01:37:33PM -0700, Andres Freund wrote:
> On 2018-06-27 22:31:30 +0200, Peter Eisentraut wrote:
>> I propose that we instead silently ignore attempts to add TOAST tables
>> to shared and system catalogs after bootstrapping.
>
> That seems like an extremely bad idea to me. I
Hi,
On 2018-06-27 22:31:30 +0200, Peter Eisentraut wrote:
> ALTER TABLE on system catalogs is occasionally useful, for example
>
> ALTER TABLE pg_attribute SET (autovacuum_vacuum_scale_factor=0);
> However, this doesn't actually work. The above command produc
ALTER TABLE on system catalogs is occasionally useful, for example
ALTER TABLE pg_attribute SET (autovacuum_vacuum_scale_factor=0);
However, this doesn't actually work. The above command produces
ERROR: AccessExclusiveLock required to add toast table.
If it's a shared c
25 matches
Mail list logo
