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 ==
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
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
* 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 ==
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
+
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
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
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,
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
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:
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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: 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
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
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
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
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
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),
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
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,
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,
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
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
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
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
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
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
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: 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
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
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
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
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: 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
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
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
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: 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
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
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
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
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 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
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));
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: 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
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
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
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)
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
64 matches
Mail list logo