Alvaro Herrera wrote:
> I wrote an identical patch on Saturday and watched it pass
> CLOBBER_CACHE_ALWAYS test on Sunday. But the reason I didn't push is I
> couldn't understand *why* is there a problem here. I imagine that the
> source of the issue is supposed to be a relcache invalidation that
Michael Paquier wrote:
> The complaint comes from jaguarundi, like here:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-11-16%2015%3A33%3A23
>
> As Tom mentioned, adding a new parameter to set the persistence
> through RelationSetNewRelfilenode works. Patch, actually
On Mon, Nov 17, 2014 at 5:56 AM, Christian Ullrich wrote:
> * Alvaro Herrera wrote:
>
>> Michael Paquier wrote:
>>
>>> Btw, perhaps this diff should be pushed as a different patch as this is a
>>> rather different thing:
>>> - if (heapRelation->rd_rel->relpersistence ==
>>> RELPERSISTENCE_UN
* Alvaro Herrera wrote:
Michael Paquier wrote:
Btw, perhaps this diff should be pushed as a different patch as this is a
rather different thing:
- if (heapRelation->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED
&&
+ if (indexRelation->rd_rel->relpersistence ==
RELPERSISTENCE_UN
On Sat, Nov 15, 2014 at 2:23 AM, Alvaro Herrera
wrote:
>
> Michael Paquier wrote:
>
> > Btw, perhaps this diff should be pushed as a different patch as this is
a
> > rather different thing:
> > - if (heapRelation->rd_rel->relpersistence ==
RELPERSISTENCE_UNLOGGED
> > &&
> > + if (index
Michael Paquier wrote:
> Btw, perhaps this diff should be pushed as a different patch as this is a
> rather different thing:
> - if (heapRelation->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED
> &&
> + if (indexRelation->rd_rel->relpersistence ==
> RELPERSISTENCE_UNLOGGED &&
>
Thanks for the updated patch, Fabrizio.
On Tue, Nov 11, 2014 at 7:44 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> > A couple of minor comments about this patch:
> > 1) Reading it, I am wondering if it would not be finally time to
> > switch to a macro to get a relation's persis
On Thu, Nov 6, 2014 at 3:42 AM, Michael Paquier
wrote:
>
> On Sat, Sep 13, 2014 at 11:02 PM, Fabrízio de Royes Mello
> wrote:
> > Patch rebased and added to commitfest [1].
> It looks like a good thing to remove ATChangeIndexesPersistence, this
> puts the persistence switch directly into reindex
On Sat, Sep 13, 2014 at 11:02 PM, Fabrízio de Royes Mello
wrote:
> Patch rebased and added to commitfest [1].
It looks like a good thing to remove ATChangeIndexesPersistence, this
puts the persistence switch directly into reindex process.
A couple of minor comments about this patch:
1) Reading it
On Tue, Aug 26, 2014 at 1:42 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Fri, Aug 22, 2014 at 5:23 PM, Alvaro Herrera
wrote:
> >
> > Fabrízio de Royes Mello wrote:
> > > On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera <
alvhe...@2ndquadrant.com>
> > > wrote:
> >
> > > >
On Fri, Aug 22, 2014 at 5:23 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
> > On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera <
alvhe...@2ndquadrant.com>
> > wrote:
>
> > > I pointed out, in the email just before pushing the patch, that
perhaps
> > > we should pass down the new rel
On Mon, Aug 25, 2014 at 2:55 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
> > On Sat, Aug 23, 2014 at 8:53 AM, Michael Paquier <
michael.paqu...@gmail.com>
> > wrote:
> > >
> > > On Sat, Aug 23, 2014 at 3:32 AM, Alvaro Herrera
> > > wrote:
> > > > Great. Pushed. Thanks for the p
Fabrízio de Royes Mello wrote:
> On Sat, Aug 23, 2014 at 8:53 AM, Michael Paquier
> wrote:
> >
> > On Sat, Aug 23, 2014 at 3:32 AM, Alvaro Herrera
> > wrote:
> > > Great. Pushed. Thanks for the patch.
> > There is a typo in what has been pushed. Patch attached.
> >
>
> Thanks... I fixed that i
On Sat, Aug 23, 2014 at 8:53 AM, Michael Paquier
wrote:
>
> On Sat, Aug 23, 2014 at 3:32 AM, Alvaro Herrera
> wrote:
> > Great. Pushed. Thanks for the patch.
> There is a typo in what has been pushed. Patch attached.
>
Thanks... I fixed that in my last patch to change 'loggedness' to
'persiste
On Sat, Aug 23, 2014 at 3:32 AM, Alvaro Herrera
wrote:
> Great. Pushed. Thanks for the patch.
There is a typo in what has been pushed. Patch attached.
--
Michael
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index d37534e..1bb46ea 100644
--- a/src/backend/comm
On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera
wrote:
>
> BTW why is it that index_build() checks the heap's relpersistence flag
> rather than the index'?
>
I'm curious about it too... the code in src/backend/catalog/index.c is:
1975 if (heapRelation->rd_rel->relpersistence ==
RELPERSISTENC
Alvaro Herrera writes:
> Robert Haas wrote:
>> 1. Loggedness is not a word. I think that "persistence" or
>> "relpersistence" would be better.
> You want me to change that to chgPersistence and so on? No prob, just
> LMK.
+1 for s/loggedness/persistence/ -- I agree with Robert that it's
a bit
Robert Haas writes:
> 2. The patch seems to think that it can sometimes be safe to change
> the relpersistence of an existing relation. Unless you can be sure
> that no buffers can possibly be present in shared_buffers and nobody
> will use an existing relcache entry to read a new one in, it's no
Fabrízio de Royes Mello wrote:
> On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera
> wrote:
> > I pointed out, in the email just before pushing the patch, that perhaps
> > we should pass down the new relpersistence flag into finish_heap_swap,
> > and from there we could pass it down to reindex_inde
On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera
wrote:
>
> > 2. The patch seems to think that it can sometimes be safe to change
> > the relpersistence of an existing relation. Unless you can be sure
> > that no buffers can possibly be present in shared_buffers and nobody
> > will use an existing
Fabrízio de Royes Mello wrote:
> On Fri, Aug 22, 2014 at 4:22 PM, Robert Haas wrote:
> > 2. The patch seems to think that it can sometimes be safe to change
> > the relpersistence of an existing relation. Unless you can be sure
> > that no buffers can possibly be present in shared_buffers and no
Robert Haas wrote:
> Hmm. I confess to not having paid enough attention to this,
Sorry about that. I guess I should somehow flag threads "I'm planning
to commit this" so that other people can review stuff carefully.
> but:
>
> 1. Loggedness is not a word. I think that "persistence" or
> "relp
On Fri, Aug 22, 2014 at 4:22 PM, Robert Haas wrote:
>
> On Fri, Aug 22, 2014 at 2:32 PM, Alvaro Herrera
> wrote:
> > Fabrízio de Royes Mello wrote:
> >> Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera <
> >> alvhe...@2ndquadrant.com> escreveu:
> >>
> >> > Fabrízio de Royes Mello wrote:
> >>
On Fri, Aug 22, 2014 at 2:32 PM, Alvaro Herrera
wrote:
> Fabrízio de Royes Mello wrote:
>> Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera <
>> alvhe...@2ndquadrant.com> escreveu:
>>
>> > Fabrízio de Royes Mello wrote:
>> >
>> > > I forgot to mention... I did again a lot of tests using differ
On Fri, Aug 22, 2014 at 3:32 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
> > Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera <
> > alvhe...@2ndquadrant.com> escreveu:
> >
> > > Fabrízio de Royes Mello wrote:
> > >
> > > > I forgot to mention... I did again a lot of tests usin
Fabrízio de Royes Mello wrote:
> Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera <
> alvhe...@2ndquadrant.com> escreveu:
>
> > Fabrízio de Royes Mello wrote:
> >
> > > I forgot to mention... I did again a lot of tests using different
> > > replication scenarios to make sure all is ok:
> > > -
Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> Fabrízio de Royes Mello wrote:
>
> > I forgot to mention... I did again a lot of tests using different
> > replication scenarios to make sure all is ok:
> > - slaves async
> > - slaves sync
> > - cascade s
Fabrízio de Royes Mello wrote:
> I forgot to mention... I did again a lot of tests using different
> replication scenarios to make sure all is ok:
> - slaves async
> - slaves sync
> - cascade slaves
On v13 you mean?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Develop
On Thu, Aug 21, 2014 at 10:26 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Thu, Aug 21, 2014 at 8:04 PM, Alvaro Herrera
wrote:
> > Andres Freund wrote:
> >
> > > Have you looked at the correctness of the patch itself? Last time I'd
> > > looked it has fundamental correctn
On Thu, Aug 21, 2014 at 8:04 PM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>
> > Have you looked at the correctness of the patch itself? Last time I'd
> > looked it has fundamental correctness issues. I'd outlined a possible
> > solution, but I haven't looked since.
>
> Yeah, Fabrizio had it pa
Tom Lane wrote:
> Alvaro Herrera writes:
> > Agreed. I am going over this patch, and the last bit I need to sort out
> > is the wording of these messages. I have temporarily settled on this:
>
> > ereport(ERROR,
> > (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
> >
On 2014-08-21 16:59:17 -0400, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
> > In Postgres internals slang, non-permanent means temporary or
> > unlogged. But I agree we shouldn't expose users to that term; we use
> > it in the docs, and it's not used in command names either.
>
> Agreed.
Alvaro Herrera writes:
> Agreed. I am going over this patch, and the last bit I need to sort out
> is the wording of these messages. I have temporarily settled on this:
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
>errmsg("ca
Heikki Linnakangas wrote:
> In Postgres internals slang, non-permanent means temporary or
> unlogged. But I agree we shouldn't expose users to that term; we use
> it in the docs, and it's not used in command names either.
Agreed. I am going over this patch, and the last bit I need to sort out
is
On 08/21/2014 05:04 PM, Thom Brown wrote:
On 21 August 2014 14:45, Fabrízio de Royes Mello
wrote:
On Thu, Aug 21, 2014 at 5:23 AM, Christoph Berg wrote:
Re: Thom Brown 2014-08-20
7u7tsgl4s5jh1a+shq_ny7gorzc_g_yj7...@mail.gmail.com>
"ERROR: table test is not permanent"
Perhaps this would
On 21 August 2014 14:45, Fabrízio de Royes Mello
wrote:
>
> On Thu, Aug 21, 2014 at 5:23 AM, Christoph Berg wrote:
> >
> > Re: Thom Brown 2014-08-20 7u7tsgl4s5jh1a+shq_ny7gorzc_g_yj7...@mail.gmail.com>
> > > "ERROR: table test is not permanent"
> > >
> > > Perhaps this would be better as "tabl
On Thu, Aug 21, 2014 at 5:23 AM, Christoph Berg wrote:
>
> Re: Thom Brown 2014-08-20
> > "ERROR: table test is not permanent"
> >
> > Perhaps this would be better as "table test is unlogged" as "permanent"
> > doesn't match the term used in the DDL syntax.
>
> I was also wondering that, but then
Re: Thom Brown 2014-08-20
> "ERROR: table test is not permanent"
>
> Perhaps this would be better as "table test is unlogged" as "permanent"
> doesn't match the term used in the DDL syntax.
I was also wondering that, but then figured that when ALTER TABLE SET
UNLOGGED is invoked on temp tables
On Wed, Aug 20, 2014 at 12:35 PM, Thom Brown wrote:
>
> Hi Fabrizio,
>
> + This form changes the table persistence type from unlogged to
permanent or
> + from unlogged to permanent (see ).
>
> Shouldn't this read "unlogged to permanent or from permanent to unlogged"?
>
Fixed.
> "ERROR
On 17 August 2014 21:45, Fabrízio de Royes Mello
wrote:
>
> On Mon, Jul 28, 2014 at 2:24 PM, Fabrízio de Royes Mello <
> fabriziome...@gmail.com> wrote:
> >
> >
> > On Mon, Jul 28, 2014 at 1:41 PM, Christoph Berg wrote:
> > >
> > > Re: Fabrízio de Royes Mello 2014-07-28
>
> > > > There are some
On Mon, Jul 28, 2014 at 2:24 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Mon, Jul 28, 2014 at 1:41 PM, Christoph Berg wrote:
> >
> > Re: Fabrízio de Royes Mello 2014-07-28
> > > There are something that should I do on this patch yet?
> >
> > I haven't got around to have
On Mon, Jul 28, 2014 at 1:41 PM, Christoph Berg wrote:
>
> Re: Fabrízio de Royes Mello 2014-07-28
> > There are something that should I do on this patch yet?
>
> I haven't got around to have a look at the newest incarnation yet, but
> I plan to do that soonish. (Of course that shouldn't stop othe
Re: Fabrízio de Royes Mello 2014-07-28
> There are something that should I do on this patch yet?
I haven't got around to have a look at the newest incarnation yet, but
I plan to do that soonish. (Of course that shouldn't stop others from
doing that as well if they wish.)
Christoph
--
c...@df7c
On Wed, Jul 23, 2014 at 5:48 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Tue, Jul 22, 2014 at 3:29 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> >
> > On Tue, Jul 22, 2014 at 12:01 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> > >
> > >
On Tue, Jul 22, 2014 at 3:29 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Tue, Jul 22, 2014 at 12:01 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> >
> >
> >
> > On Thu, Jul 17, 2014 at 8:02 PM, Andres Freund
wrote:
> > >
> > > > That means should I "FlushR
On Tue, Jul 22, 2014 at 12:01 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
>
> On Thu, Jul 17, 2014 at 8:02 PM, Andres Freund
wrote:
> >
> > > That means should I "FlushRelationBuffers(rel)" before change the
> > > relpersistence?
> >
> > I don't think that'd help. I think wha
On Thu, Jul 17, 2014 at 8:02 PM, Andres Freund
wrote:
>
> > That means should I "FlushRelationBuffers(rel)" before change the
> > relpersistence?
>
> I don't think that'd help. I think what this means that you simply
> cannot change the relpersistence of the old relation before the heap
> swap is
On Mon, Jul 21, 2014 at 9:51 AM, Andres Freund
wrote:
>
> On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> > > The rewrite will read in the 'old' contents - but because it's done
> > > after the pg_class.relpersistence is changed they'll all not be marked
> > > as BM_PERMANENT in mem
On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> > The rewrite will read in the 'old' contents - but because it's done
> > after the pg_class.relpersistence is changed they'll all not be marked
> > as BM_PERMANENT in memory. Then the ALTER TABLE is rolled back,
> > including the relpe
Re: Fabrízio de Royes Mello 2014-07-16
> Anyway I think all is ok now. Is this ok for you?
Hi Fabrízio,
it's ok for me now, though Andres' concerns seem valid.
> > > +SET TABLESPACE class="PARAMETER">new_tablespace
> > > RESET ( class="PARAMETER">storage_parameter [, ... ] )
> > >
On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote:
> On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund
> wrote:
> >
> > On 2014-07-16 20:53:06 +0200, Andres Freund wrote:
> > > On 2014-07-16 20:25:42 +0200, Andres Freund wrote:
> > > > Hi,
> > > >
> > > > I quickly looked at this patch and
On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund
wrote:
>
> On 2014-07-16 20:53:06 +0200, Andres Freund wrote:
> > On 2014-07-16 20:25:42 +0200, Andres Freund wrote:
> > > Hi,
> > >
> > > I quickly looked at this patch and I think there's major missing
pieces
> > > around buffer management and wal l
On 2014-07-16 20:53:06 +0200, Andres Freund wrote:
> On 2014-07-16 20:25:42 +0200, Andres Freund wrote:
> > Hi,
> >
> > I quickly looked at this patch and I think there's major missing pieces
> > around buffer management and wal logging.
> >
> > a) Currently buffers that are in memory marked as
>
On Wed, Jul 16, 2014 at 3:53 PM, Andres Freund
wrote:
>
> On 2014-07-16 20:25:42 +0200, Andres Freund wrote:
> > Hi,
> >
> > I quickly looked at this patch and I think there's major missing pieces
> > around buffer management and wal logging.
> >
> > a) Currently buffers that are in memory marked
On 2014-07-16 20:25:42 +0200, Andres Freund wrote:
> Hi,
>
> I quickly looked at this patch and I think there's major missing pieces
> around buffer management and wal logging.
>
> a) Currently buffers that are in memory marked as
>permanent/non-permanent aren't forced out to disk/pruned from
Hi,
I quickly looked at this patch and I think there's major missing pieces
around buffer management and wal logging.
a) Currently buffers that are in memory marked as
permanent/non-permanent aren't forced out to disk/pruned from cache,
not even when they're dirty.
b) When converting from a
Re: Fabrízio de Royes Mello 2014-07-15
> > What about the wqueue mechanism, though? Isn't that made exactly for
> > the kind of catalog updates you are doing?
> >
>
> Works, but this mechanism create a new entry in pg_class for toast, so it's
> a little different than use the cluster_rel that ge
On Tue, Jul 15, 2014 at 3:04 PM, Christoph Berg wrote:
>
> Hi Fabrízio,
>
> thanks for the speedy new version.
>
You're welcome... If all happen ok I would like to have this patch commited
before the GSoC2014 ends.
> > > I've just tried some SET (UN)LOGGED operations with altering column
> > > t
Hi Fabrízio,
thanks for the speedy new version.
Re: Fabrízio de Royes Mello 2014-07-15
> > > > > +
> > > > > + if (pass == AT_PASS_SET_LOGGED_UNLOGGED)
> > > > > +
> > > ATPostAlterSetLoggedUnlogged(RelationGetRelid(rel));
> > > >
> > > > This must be done before relation_cl
On Mon, Jul 14, 2014 at 3:31 PM, Christoph Berg wrote:
>
> Oh I wasn't aware of the wiki page, I had just read the old thread.
> Thanks for the pointer.
>
:-)
Thanks again for your review!
> > > > diff --git a/doc/src/sgml/ref/alter_table.sgml
> > b/doc/src/sgml/ref/alter_table.sgml
> > > > in
Re: Fabrízio de Royes Mello 2014-07-12
> > ... that being the non-WAL-logging with wal_level=minimal, or more?
>
> This is the first of additional goals, but we have others. Please see [1].
Oh I wasn't aware of the wiki page, I had just read the old thread.
Thanks for the pointer.
> > > diff
Hi,
here's my review for this patch.
Generally, the patch addresses a real need, tables often only turn
out to be desired as unlogged if there are performance problems in
practice, and the other way round changing an unlogged table to logged
is way more involved manually than it could be with thi
On Wed, Jun 11, 2014 at 1:19 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Hi all,
>
> As part of GSoC2014 I'm sending a patch to add the capability of change an
> unlogged table to logged [1].
>
>
Hi all,
As part of GSoC2014 and with agreement of my mentor and reviewer (Stephen
Hi all,
As part of GSoC2014 I'm sending a patch to add the capability of change an
unlogged table to logged [1].
I'll add it to the 9.5CF1.
Regards,
[1]
https://wiki.postgresql.org/wiki/Allow_an_unlogged_table_to_be_changed_to_logged_GSoC_2014
--
Fabrízio de Royes Mello
Consultoria/Coaching P
64 matches
Mail list logo
