Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-17 Thread Michael Paquier
On Mon, Nov 17, 2014 at 5:56 AM, Christian Ullrich ch...@chrullrich.net 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 ==

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-17 Thread Alvaro Herrera
Michael Paquier wrote: The complaint comes from jaguarundi, like here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2014-11-16%2015%3A33%3A23 As Tom mentioned, adding a new parameter to set the persistence through RelationSetNewRelfilenode works. Patch, actually

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-17 Thread Alvaro Herrera
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-16 Thread Christian Ullrich
* 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 ==

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-15 Thread Fabrízio de Royes Mello
On Sat, Nov 15, 2014 at 2:23 AM, Alvaro Herrera alvhe...@2ndquadrant.com 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 +

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-14 Thread Alvaro Herrera
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-10 Thread Fabrízio de Royes Mello
On Thu, Nov 6, 2014 at 3:42 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Sat, Sep 13, 2014 at 11:02 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: Patch rebased and added to commitfest [1]. It looks like a good thing to remove ATChangeIndexesPersistence, this puts the

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-10 Thread Michael Paquier
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 persistence,

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-11-05 Thread Michael Paquier
On Sat, Sep 13, 2014 at 11:02 PM, Fabrízio de Royes Mello fabriziome...@gmail.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-09-13 Thread Fabrízio de Royes Mello
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 alvhe...@2ndquadrant.com wrote: Fabrízio de Royes Mello wrote: On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-25 Thread Alvaro Herrera
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 alvhe...@2ndquadrant.com wrote: Great. Pushed. Thanks for the patch. There is a typo in what has been pushed. Patch

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-25 Thread Fabrízio de Royes Mello
On Mon, Aug 25, 2014 at 2:55 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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 alvhe...@2ndquadrant.com wrote:

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-25 Thread Fabrízio de Royes Mello
On Fri, Aug 22, 2014 at 5:23 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-23 Thread Michael Paquier
On Sat, Aug 23, 2014 at 3:32 AM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-23 Thread Fabrízio de Royes Mello
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 alvhe...@2ndquadrant.com wrote: Great. Pushed. Thanks for the patch. There is a typo in what has been pushed. Patch attached. Thanks... I fixed that in my

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Alvaro Herrera
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: - slaves async

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Fabrízio de Royes Mello
On Fri, Aug 22, 2014 at 3:32 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Robert Haas
On Fri, Aug 22, 2014 at 2:32 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Fabrízio de Royes Mello
On Fri, Aug 22, 2014 at 4:22 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Aug 22, 2014 at 2:32 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Fabrízio de Royes Mello wrote: Em sexta-feira, 22 de agosto de 2014, Alvaro Herrera alvhe...@2ndquadrant.com escreveu: Fabrízio

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Alvaro Herrera
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Alvaro Herrera
Fabrízio de Royes Mello wrote: On Fri, Aug 22, 2014 at 4:22 PM, Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Fabrízio de Royes Mello
On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Alvaro Herrera
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 relpersistence flag into finish_heap_swap, and from there we could pass it

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Tom Lane
Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-22 Thread Fabrízio de Royes Mello
On Fri, Aug 22, 2014 at 4:45 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Christoph Berg
Re: Thom Brown 2014-08-20 CAA-aLv7TeF8iM=7u7tsgl4s5jh1a+shq_ny7gorzc_g_yj7...@mail.gmail.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Fabrízio de Royes Mello
On Thu, Aug 21, 2014 at 5:23 AM, Christoph Berg c...@df7cb.de wrote: Re: Thom Brown 2014-08-20 CAA-aLv7TeF8iM= 7u7tsgl4s5jh1a+shq_ny7gorzc_g_yj7...@mail.gmail.com ERROR: table test is not permanent Perhaps this would be better as table test is unlogged as permanent doesn't match the

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Thom Brown
On 21 August 2014 14:45, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: On Thu, Aug 21, 2014 at 5:23 AM, Christoph Berg c...@df7cb.de wrote: Re: Thom Brown 2014-08-20 CAA-aLv7TeF8iM= 7u7tsgl4s5jh1a+shq_ny7gorzc_g_yj7...@mail.gmail.com ERROR: table test is not permanent

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Heikki Linnakangas
On 08/21/2014 05:04 PM, Thom Brown wrote: On 21 August 2014 14:45, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: On Thu, Aug 21, 2014 at 5:23 AM, Christoph Berg c...@df7cb.de wrote: Re: Thom Brown 2014-08-20 CAA-aLv7TeF8iM= 7u7tsgl4s5jh1a+shq_ny7gorzc_g_yj7...@mail.gmail.com

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Alvaro Herrera
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com 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),

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Andres Freund
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. I am

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com 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,

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Fabrízio de Royes Mello
On Thu, Aug 21, 2014 at 8:04 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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,

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Fabrízio de Royes Mello
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 alvhe...@2ndquadrant.com wrote: Andres Freund wrote: Have you looked at the correctness of the patch itself? Last time I'd looked it has

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Alvaro Herrera
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-21 Thread Fabrízio de Royes Mello
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 slaves On

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-20 Thread Thom Brown
On 17 August 2014 21:45, Fabrízio de Royes Mello fabriziome...@gmail.com 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 c...@df7cb.de wrote: Re: Fabrízio de Royes Mello 2014-07-28

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-20 Thread Fabrízio de Royes Mello
On Wed, Aug 20, 2014 at 12:35 PM, Thom Brown t...@linux.com wrote: Hi Fabrizio, + This form changes the table persistence type from unlogged to permanent or + from unlogged to permanent (see xref linkend=SQL-CREATETABLE-UNLOGGED). Shouldn't this read unlogged to permanent or from

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-08-17 Thread Fabrízio de Royes Mello
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 c...@df7cb.de wrote: Re: Fabrízio de Royes Mello 2014-07-28 CAFcNs+pctx4Q2UYsLOvVFWaznO3U0XhPpkMx5DRhR=jw8w3...@mail.gmail.com There are something that

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-28 Thread Fabrízio de Royes Mello
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 Thu, Jul

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-28 Thread Christoph Berg
Re: Fabrízio de Royes Mello 2014-07-28 CAFcNs+pctx4Q2UYsLOvVFWaznO3U0XhPpkMx5DRhR=jw8w3...@mail.gmail.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-28 Thread Fabrízio de Royes Mello
On Mon, Jul 28, 2014 at 1:41 PM, Christoph Berg c...@df7cb.de wrote: Re: Fabrízio de Royes Mello 2014-07-28 CAFcNs+pctx4Q2UYsLOvVFWaznO3U0XhPpkMx5DRhR=jw8w3...@mail.gmail.com There are something that should I do on this patch yet? I haven't got around to have a look at the newest incarnation

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-23 Thread Fabrízio de Royes Mello
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 and...@2ndquadrant.com wrote: That means should I

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-22 Thread Fabrízio de Royes Mello
On Thu, Jul 17, 2014 at 8:02 PM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-22 Thread Fabrízio de Royes Mello
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 and...@2ndquadrant.com wrote: That means should I FlushRelationBuffers(rel) before change the relpersistence? I don't think that'd help. I think

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-21 Thread Christoph Berg
Re: Fabrízio de Royes Mello 2014-07-16 cafcns+r_lmddxjrabwnj3rmy0qegwa-vv6v2smdescofb2d...@mail.gmail.com 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 replaceable

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-21 Thread Andres Freund
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-21 Thread Fabrízio de Royes Mello
On Mon, Jul 21, 2014 at 9:51 AM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-17 Thread Andres Freund
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 and...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-16 Thread Christoph Berg
Re: Fabrízio de Royes Mello 2014-07-15 CAFcNs+pXpmfwi_rKF-cSBOHWC+E=xtsrnxicrgay6bcmthb...@mail.gmail.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-16 Thread Andres Freund
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-16 Thread Andres Freund
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-16 Thread Fabrízio de Royes Mello
On Wed, Jul 16, 2014 at 3:53 PM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-16 Thread Andres Freund
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-16 Thread Fabrízio de Royes Mello
On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-15 Thread Christoph Berg
Hi Fabrízio, thanks for the speedy new version. Re: Fabrízio de Royes Mello 2014-07-15 cafcns+opbuhjuo1soathv8zqcowqp-yerjfoo15v1xpxspc...@mail.gmail.com + + if (pass == AT_PASS_SET_LOGGED_UNLOGGED) + ATPostAlterSetLoggedUnlogged(RelationGetRelid(rel));

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-15 Thread Fabrízio de Royes Mello
On Tue, Jul 15, 2014 at 3:04 PM, Christoph Berg c...@df7cb.de 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-14 Thread Christoph Berg
Re: Fabrízio de Royes Mello 2014-07-12 cafcns+qf5fukkp9vdjwokiabn_rrm4+hjqxeevpd_7-to0l...@mail.gmail.com ... 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-14 Thread Fabrízio de Royes Mello
On Mon, Jul 14, 2014 at 3:31 PM, Christoph Berg c...@df7cb.de 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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-07-08 Thread Christoph Berg
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

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

2014-06-26 Thread Fabrízio de Royes Mello
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 Frost)