Re: Feature: triggers on materialized views

Hi! One more version of the patch with slightly more deterministic tests. Mitar On Thu, Dec 27, 2018 at 11:43 PM Mitar wrote: > > Hi! > > I have made an updated version of the patch, added tests and > documentation changes. This is my view now a complete patch. Please > provide any feedback

Re: plpgsql plugin - stmt_beg/end is not called for top level block of statements

On Fri, Dec 28, 2018 at 07:57:45AM +0100, Pavel Stehule wrote: > There is only one difference - the plugin routine stmt_begin and stmt_end > is called for line 3. Nothing less, nothing more. Thanks for the detailed explanation! With your simple example it is easy enough to see the difference,

Re: Feature: temporary materialized views

Hi! One more version of the patch with more deterministic tests. Mitar On Thu, Dec 27, 2018 at 10:35 AM Mitar wrote: > > Hi! > > Thanks, I did it. > > I am attaching a new version of the patch with few more lines added to tests. > > I noticed that there is no good summary of the latest patch,

Re: Feature: triggers on materialized views

Hi! I have made an updated version of the patch, added tests and documentation changes. This is my view now a complete patch. Please provide any feedback or comments you might have for me to improve the patch. I will also add it to commitfest. A summary of the patch: This patch enables adding

RE: Speeding up creating UPDATE/DELETE generic plan for partitioned table into a lot

From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Maybe, we can invent new types of plans for queries on partitioned tables > that can be constructed by only looking at the parent relation. We'd need > new infrastructure before we can begin working on that though. For > example, until

Re: plpgsql plugin - stmt_beg/end is not called for top level block of statements

pá 28. 12. 2018 v 3:26 odesílatel Michael Paquier napsal: > On Wed, Dec 26, 2018 at 07:02:04AM +0100, Pavel Stehule wrote: > > is called two times, what is not expected, if you don't know some about > > this inconsistency. > > > > So it is reason, why I don't think so current behave is correct.

Re: Problems with plan estimates in postgres_fdw

(2018/12/26 16:35), Etsuro Fujita wrote: Attached is an updated version of the patch. Other changes: While self-reviewing the patch I noticed a thinko in the patch 0001 for pushing down the final sort: I estimated the costs for that using estimate_path_cost_size that was modified so that it

Re: Compiling on Termux

On Sat, Dec 22, 2018 at 11:51 AM Tom Lane wrote: > Thomas Munro writes: > > On Sat, Dec 22, 2018 at 9:19 AM David Fetter wrote: > >> I don't know precisely how it's going to play with Postgres, but > >> Termux does supply a Postgres in its native packages. That package > >> appears to work, at

Re: removal of dangling temp tables

On Fri, Dec 28, 2018 at 12:05:34AM -0300, Alvaro Herrera wrote: > The server code allocates arrays, but that's fine because that code is > recompiled. Extensions only pass pointers around -- they don't create > any additional arrays. There are many exotic extensions which could be using

add_partial_path() may remove dominated path but still in use

Hello, I've investigated a crash report of PG-Strom for a few days, then I doubt add_partial_path() can unexpectedly release dominated old partial path but still referenced by other Gather node, and it leads unexpected system crash. Please check at the gpuscan.c:373

Re: Minor comment fix for pg_config_manual.h

On 2018-Dec-28, Michael Paquier wrote: > On Wed, Dec 26, 2018 at 09:36:57AM +0900, Michael Paquier wrote: > > like the attached perhaps? At the same time I am thinking about > > reformulating the second sentence as well.. > > > > /* > > - * This is default value for wal_segment_size to be used

Re: Alter table documentation page (again)

On 2018-Dec-28, Michael Paquier wrote: > On Wed, Dec 26, 2018 at 01:46:48PM +0900, Michael Paquier wrote: > > What's proposed here looks good to me, and all the grounds are > > covered, so I am switching the patch as ready for committer. > > And committed, mentioning on the way Brigitte for the

Re: Synchronous replay take III

Hello, Here is a rebased patch, and separate replies to Michael and Michail. On Sat, Dec 1, 2018 at 4:57 PM Michael Paquier wrote: > On Sat, Dec 01, 2018 at 02:48:29PM +1300, Thomas Munro wrote: > > Right, it conflicted with 4c703369 and cfdf4dc4. While rebasing on > > top of those, I found

Re: removal of dangling temp tables

On 2018-Dec-28, Michael Paquier wrote: > On Thu, Dec 27, 2018 at 04:30:21PM -0300, Alvaro Herrera wrote: > > We allow structs to receive new members at the end of the struct, since > > this doesn't affect the offset of existing members; thus code already > > compiled with the previous struct

Re: [HACKERS] Block level parallel vacuum

On Thu, Dec 20, 2018 at 3:38 PM Amit Kapila wrote: > > On Tue, Dec 18, 2018 at 1:29 PM Masahiko Sawada wrote: > > > > Attached the updated patches. I scaled back the scope of this patch. > > The patch now includes only feature (a), that is it execute both index > > vacuum and cleanup index in

Re: plpgsql plugin - stmt_beg/end is not called for top level block of statements

On Wed, Dec 26, 2018 at 07:02:04AM +0100, Pavel Stehule wrote: > is called two times, what is not expected, if you don't know some about > this inconsistency. > > So it is reason, why I don't think so current behave is correct. On second > hand, the impact is very small - only few extensions uses

Re: Minor comment fix for pg_config_manual.h

On Wed, Dec 26, 2018 at 09:36:57AM +0900, Michael Paquier wrote: > like the attached perhaps? At the same time I am thinking about > reformulating the second sentence as well.. > > /* > - * This is default value for wal_segment_size to be used at initdb when run > - * without --walsegsize

Re: Offline enabling/disabling of data checksums

On Fri, Dec 28, 2018 at 01:14:05AM +0100, Tomas Vondra wrote: > I'm sorry, but I'm not sure I understand the question. Of course, asking > over at -packagers won't hurt, but my guess is the response will be it's > not a big deal from the packaging perspective. (The previous email had an extra

Re: [HACKERS] SERIALIZABLE on standby servers

On Fri, Nov 30, 2018 at 3:01 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > On Tue, Sep 25, 2018 at 4:51 PM Kevin Grittner wrote: > > On Fri, Sep 21, 2018 at 7:29 AM Thomas Munro > > wrote: > > > I'll add it to the next Commitfest so I know when to rebase it. > > > > I signed up as reviewer

Re: Alter table documentation page (again)

On Wed, Dec 26, 2018 at 01:46:48PM +0900, Michael Paquier wrote: > What's proposed here looks good to me, and all the grounds are > covered, so I am switching the patch as ready for committer. And committed, mentioning on the way Brigitte for the report. -- Michael signature.asc Description:

Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Thu, Dec 27, 2018 at 7:58 PM Andrew Dunstan wrote: > On 12/24/18 5:47 PM, Andrew Dunstan wrote: > > On 12/24/18 5:25 PM, Alexander Korotkov wrote: > >> BTW, patch for reducing isolation testing for gin predicate locking is > >> attached. Could anybody check its execution time with valgrind

Re: Offline enabling/disabling of data checksums

On 12/28/18 12:25 AM, Michael Paquier wrote: > On Thu, Dec 27, 2018 at 03:46:48PM +0100, Tomas Vondra wrote: >> On 12/27/18 11:43 AM, Magnus Hagander wrote: >>> Should we double-check with packagers that this won't cause a problem? >>> Though the fact that it's done in a major release should

Re: row filtering for logical replication

On 27/12/2018 20:19, Stephen Frost wrote: > Greetings, > > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: >> On 14/12/2018 16:56, Stephen Frost wrote: >>> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: On 11/23/18 8:03 PM, Stephen Frost wrote: > * Fabrízio de Royes Mello

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Thu, Dec 27, 2018 at 11:04:09AM +0100, Peter Eisentraut wrote: > The current patch prevents REINDEX CONCURRENTLY of invalid indexes, but > I wonder why that is so. Anyone remember? It should be around this time:

Re: Offline enabling/disabling of data checksums

On Thu, Dec 27, 2018 at 03:46:48PM +0100, Tomas Vondra wrote: > On 12/27/18 11:43 AM, Magnus Hagander wrote: >> Should we double-check with packagers that this won't cause a problem? >> Though the fact that it's done in a major release should make it >> perfectly fine I think -- and it's a smaller

Re: could recovery_target_timeline=latest be the default in standby mode?

On Thu, Dec 27, 2018 at 06:36:23PM +0200, David Steele wrote: > I like the idea of defaulting to the latest timeline since this is what you > want to do most of the time, but I think we'd then need a value for > following the current timelime, i.e. the one that the backup was taken on > (which is

Re: row filtering for logical replication

Hi, On 27/12/2018 20:05, Stephen Frost wrote: > Greetings, > > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: >> On 14/12/2018 16:38, Stephen Frost wrote: >>> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: I do see the appeal here, if you consider logical replication to be a

Re: Poor buildfarm coverage of strong-random alternatives

Michael Paquier writes: > On Thu, Dec 27, 2018 at 03:56:52PM -0500, Tom Lane wrote: >> More urgently, what about the lack of --disable-strong-random >> coverage? I feel like we should either have a buildfarm >> critter or two testing that code, or decide that it's no longer >> interesting and

Re: random() (was Re: New GUC to sample log queries)

Fabien COELHO writes: >> Another idea, which would be a lot less prone to breakage by >> add-on code, is to change drandom() and setseed() to themselves >> use pg_erand48() with a private seed. > The pg_erand48 code looks like crumbs from the 70's optimized for 16 bits > architectures (which it

Re: Poor buildfarm coverage of strong-random alternatives

On Thu, Dec 27, 2018 at 03:56:52PM -0500, Tom Lane wrote: > More urgently, what about the lack of --disable-strong-random > coverage? I feel like we should either have a buildfarm > critter or two testing that code, or decide that it's no longer > interesting and rip it out. backend_random.c, to

Re: removal of dangling temp tables

On Thu, Dec 27, 2018 at 04:30:21PM -0300, Alvaro Herrera wrote: > We allow structs to receive new members at the end of the struct, since > this doesn't affect the offset of existing members; thus code already > compiled with the previous struct definition does not break. AFAICS > there is no

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On Thu, Dec 27, 2018 at 07:04:41PM -0300, Alvaro Herrera wrote: > On 2018-Dec-27, Tom Lane wrote: > > > I poked around a little on my own machines, and I can confirm that > > Getopt::Long is present in a default Perl install-from-source at > > least as far back as perl 5.6.1. It's barely

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 2018-Dec-27, Tom Lane wrote: > I poked around a little on my own machines, and I can confirm that > Getopt::Long is present in a default Perl install-from-source at > least as far back as perl 5.6.1. It's barely conceivable that some > packager might omit it from their minimal package, but

Re: pg_dumpall --exclude-database option

Hello, While poking around the dump output, I noticed some unrelated points: * Command "pg_dump" could tell which database is dumped in the output Or "pg_dumpall" could issue a comment line in the output telling which database is being considered. * The database dumps should have an

Re: Cache relation sizes?

On Thu, Dec 27, 2018 at 8:00 PM Jamison, Kirk wrote: > I also find this proposed feature to be beneficial for performance, > especially when we want to extend or truncate large tables. > As mentioned by David, currently there is a query latency spike when we make > generic plan for partitioned

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Andrew Dunstan writes: > On 12/27/18 3:34 PM, Tom Lane wrote: >> ... that's a pretty thin argument, and if Getopt::Long is present even >> in the most minimal Perl installations then it's certainly moot. > It's bundled separately, but on both systems I looked at it's needed by > the base perl

Poor buildfarm coverage of strong-random alternatives

I just noticed that, since I retired pademelon in August, we have exactly no buildfarm coverage of --disable-strong-random code paths. What's more, because the vast majority of the buildfarm enables --with-openssl, we're mostly just testing the punt-to-OpenSSL variant of pg_strong_random.

Re: pg_dumpall --exclude-database option

On 12/25/18 3:36 AM, Fabien COELHO wrote: > > Hello Andrew, > >> Rebased and updated patch attached. > > Here is a review of v5, sorry for the delay. > > Patch applies cleanly, compiles, "make check" is ok. > > I do not see Michaël's issue, and do not see how it could be so, for > me the whole

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 12/27/18 3:34 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 12/27/18 3:00 PM, John Naylor wrote: >>> This style was cargo-culted from the catalog scripts. I can settle on >>> just the first form if you like. >> I would rather we used the standard perl module Getopt::Long, as >> numerous

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Andrew Dunstan writes: > On 12/27/18 3:00 PM, John Naylor wrote: >> This style was cargo-culted from the catalog scripts. I can settle on >> just the first form if you like. > I would rather we used the standard perl module Getopt::Long, as > numerous programs we have already do. Hmm ...

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 12/27/18 3:00 PM, John Naylor wrote: > On 12/27/18, Tom Lane wrote: >> diff --git a/src/tools/gen_keywords.pl b/src/tools/gen_keywords.pl >> +elsif ($arg =~ /^-o/) >> +{ >> +$output_path = length($arg) > 2 ? substr($arg, 2) : shift @ARGV; >> +} >> >> My perl-fu is not

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor writes: > On 12/27/18, Tom Lane wrote: >> +$kw_input_file =~ /((\w*)kwlist)\.h/; >> +my $base_filename = $1; >> +$prefix = $2 if !defined $prefix; >> >> Hmm, what happens if the input filename does not end with "kwlist.h"? > If that's a maintainability hazard, I can force every

Re: using index or check in ALTER TABLE SET NOT NULL

> On Thu, Nov 22, 2018 at 6:04 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Absolutely agree. Looking at the history of the patch I see that it went > through some extensive review and even was marked as Ready for Committer > before > the commentary from Peter, but since then some changes

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 12/27/18, Tom Lane wrote: > diff --git a/src/tools/gen_keywords.pl b/src/tools/gen_keywords.pl > + elsif ($arg =~ /^-o/) > + { > + $output_path = length($arg) > 2 ? substr($arg, 2) : shift @ARGV; > + } > > My perl-fu is not great, but it looks like this will accept

Re: random() (was Re: New GUC to sample log queries)

I wrote: > Peter Geoghegan writes: >> We're already making fairly broad assumptions about our having control >> of the backend's PRNG state within InitProcessGlobals(). How should >> this affect the new drandom()/setseed() private state, if at all? > I would think that InitProcessGlobals would

Re: random() (was Re: New GUC to sample log queries)

Thomas Munro writes: > On Thu, Dec 27, 2018 at 3:55 PM Peter Geoghegan wrote: >> On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote: >>> The point here is not to be cryptographically strong at every single >>> place where the backend might want a random number; I think we're >>> all agreed that we

Re: random() (was Re: New GUC to sample log queries)

Peter Geoghegan writes: > On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote: >> Now, we could probably fix that with some less intrusive patch than >> #define'ing random() --- in particular, if we give drandom and setseed >> their own private PRNG state, we've really fixed the security exposure >>

Re: removal of dangling temp tables

On 2018-Dec-27, Michael Paquier wrote: > On Wed, Dec 26, 2018 at 08:51:56PM -0300, Alvaro Herrera wrote: > > Having been victim of ABI incompatibility myself, I loathe giving too > > much priority to other issues that can be resolved in other ways, so I > > don't necessarily support your view on

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Andrew Dunstan writes: > RD parsers are not terribly hard to write. Sure, as long as they are for grammars that are (a) small, (b) static, and (c) LL(1), which is strictly weaker than the LALR(1) grammar class that bison can handle. We already have a whole lot of constructs that are at the

Re: row filtering for logical replication

Greetings, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 14/12/2018 16:56, Stephen Frost wrote: > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > >> On 11/23/18 8:03 PM, Stephen Frost wrote: > >>> * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote: > On Fri, Nov

Re: row filtering for logical replication

Greetings, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 14/12/2018 16:38, Stephen Frost wrote: > > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > >> I do see the appeal here, if you consider logical replication to be a > >> streaming select it probably applies well. > >> > >>

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

John Naylor writes: > Barring additional bikeshedding on 0001, I'll plan on implementing > offset-based lookup for the other keyword types and retire the old > ScanKeyword. Once that's done, we can benchmark and compare with the > optimizations in 0002. Sounds like a plan. Assorted minor

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 12/27/18 12:12 PM, Tom Lane wrote: >> I don't buy that we're inable to write a descent parser that way. > I do not think that we could write one for the current state of the > PG grammar without an investment of effort so large that it's not > going to happen. Even if such a parser were to

Re: Feature: temporary materialized views

Hi! Thanks, I did it. I am attaching a new version of the patch with few more lines added to tests. I noticed that there is no good summary of the latest patch, so let me make it here: So the latest version of the patch adds an option for "temporary" materialized views. Such materialized views

Re: Alternative to \copy in psql modelled after \g

On 2018-Dec-27, Daniel Verite wrote: > > Maybe I misunderstand something, as I'm not familiar with TAP tests, > but hasn't psql no such test to begin with, as opposed to the > other programs in src/bin that have a t/ directory? That's correct. psql does have some tests though, in

Re: Alternative to \copy in psql modelled after \g

Fabien COELHO wrote: > Dunno. Even if an additional tap test would not be backpatched, it could > be added on master. I'm basically sadden by pg test coverage, especially > psql which is under 40%, so I try to grasp any improvement opportunity… > > See https://coverage.postgresql.org/

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Andres Freund writes: > On 2018-12-26 14:03:57 -0500, Tom Lane wrote: >> It's impossible to write correct RD parsers by hand for any but the most >> trivial, conflict-free languages, and what we have got to deal with >> is certainly neither of those; moreover, it's a constantly moving target. >>

Re: Remove Deprecated Exclusive Backup Mode

On 12/27/18 6:53 PM, Magnus Hagander wrote: On Fri, Dec 21, 2018 at 5:43 PM Robert Haas I think the old CommitFest application let you set the CommitFest via the Edit screen also, so you could pick a specific CommitFest to target.  But that doesn't seem to exist in Magnus's version.

Re: GIN predicate locking slows down valgrind isolationtests tremendously

On 12/24/18 5:47 PM, Andrew Dunstan wrote: > On 12/24/18 5:25 PM, Alexander Korotkov wrote: >> On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov >> wrote: >>> чт, 20 дек. 2018 г., 2:22 Andres Freund and...@anarazel.de: On 2018-12-03 16:07:40 -0800, Andres Freund wrote: > As far as I

Re: tickling the lesser contributor's withering ego

On 12/27/18 4:53 AM, Magnus Hagander wrote: > > > On Fri, Dec 21, 2018 at 4:17 PM Alvaro Herrera > wrote: > > On 2018-Dec-21, Tom Lane wrote: > > > Alvaro Herrera > writes: > > > I propose the following patch,

Re: could recovery_target_timeline=latest be the default in standby mode?

On 12/27/18 1:02 PM, Peter Eisentraut wrote: On 22/12/2018 00:38, Michael Paquier wrote: On Fri, Dec 21, 2018 at 01:54:20PM +0300, Sergei Kornilov wrote: I am +1 for recovery_target_timeline=latest by default. This is common case in my opinion. I agree also that switching to the latest

Re: Alternative to \copy in psql modelled after \g

Fabien COELHO wrote: > > It does not add "unless the query is a COPY", so it seems right > > to make that just work, and call it a bug fix. > > Does this suggest backpatching? Yes, I think it's a candidate for back-patching. > > There is a precedent in

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

On 12/26/18, John Naylor wrote: > On 12/26/18, Robert Haas wrote: >> I wonder if we could do something really simple like a lookup based on >> the first character of the scan keyword. It looks to me like there are >> 440 keywords right now, and the most common starting letter is 'c', >> which is

Re: Offline enabling/disabling of data checksums

On Thu, Dec 27, 2018 at 3:54 PM Tomas Vondra wrote: > > > On 12/27/18 11:39 AM, Magnus Hagander wrote: > > > > > > On Thu, Dec 27, 2018 at 2:15 AM Michael Paquier > > wrote: > > > > On Wed, Dec 26, 2018 at 07:43:17PM +0100, Fabien COELHO wrote: > > >> It adds

Re: Offline enabling/disabling of data checksums

On 12/27/18 11:39 AM, Magnus Hagander wrote: > > > On Thu, Dec 27, 2018 at 2:15 AM Michael Paquier > wrote: > > On Wed, Dec 26, 2018 at 07:43:17PM +0100, Fabien COELHO wrote: > >> It adds an (now mandatory) --action parameter that takes either >

Re: Offline enabling/disabling of data checksums

On 12/27/18 11:43 AM, Magnus Hagander wrote: > > > On Sat, Dec 22, 2018 at 12:28 AM Michael Paquier > wrote: > > On Fri, Dec 21, 2018 at 09:16:16PM +0100, Michael Banck wrote: > > I think that this is independently useful, I got this stuff part of an >

Re: PostgreSQL partition tables use more private memory

Thanks you guys, I will test the patches you mentioned, and keep you updated. Thanks, Marcus Sent from my iPhone > On Dec 27, 2018, at 19:28, Amit Langote wrote: > > Hi, > >> On 2018/12/27 15:44, 大松 wrote: >> # PostgreSQL partition tables use more private memory >> >> Hi, there is a process

Re: global / super barriers (for checksums)

On Thu, Dec 27, 2018 at 2:22 PM Andres Freund wrote: > Hi, > > On 2018-12-27 13:54:34 +0100, Magnus Hagander wrote: > > Finally getting around to playing with this one and it unfortunately > > doesn't apply anymore (0003). > > > > I think it's just a matter of adding those two rows though,

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2018-Dec-27, Alexey Kondratov wrote: > To summarize: > > 1) Alvaro and Michael agreed, that REINDEX with tablespace move may be > useful. This is done in the patch attached to my initial email. Adding > REINDEX to ALTER TABLE as new action seems quite questionable for me and not > completely

Re: global / super barriers (for checksums)

Hi, On 2018-12-27 13:54:34 +0100, Magnus Hagander wrote: > Finally getting around to playing with this one and it unfortunately > doesn't apply anymore (0003). > > I think it's just a matter of adding those two rows though, right? That is, > it's not an actual conflict it's just something else

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Hi, On 2018-12-26 14:03:57 -0500, Tom Lane wrote: > Andres Freund writes: > > My bet is, and has been for quite a while, that we'll have to go for a > > hand-written recursive descent type parser. > > I will state right up front that that will happen over my dead body. > > It's impossible to

Re: Feature: temporary materialized views

On 2018-Dec-27, Mitar wrote: > Hi! > > I made a new version of the patch. I added tests and changes to the > docs and made sure various other aspects of this change for as well. I > think this now makes temporary materialized views fully implemented > and that in my view patch is complete. If

Implementing Incremental View Maintenance

Hi, I would like to implement Incremental View Maintenance (IVM) on PostgreSQL. IVM is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputate the contents as the current REFRESH command does. I had a

Re: global / super barriers (for checksums)

On Tue, Oct 30, 2018 at 6:16 AM Andres Freund wrote: > Hi, > > Magnus cornered me at pgconf.eu and asked me whether I could prototype > the "barriers" I'd been talking about in the online checksumming thread. > > The problem there was to make sure that all processes, backends and > auxiliary

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

Hi, Thank you all for replies. ALTER TABLE already has a lot of logic that is oriented towards being able to do multiple things at the same time. If we added CLUSTER, VACUUM FULL, and REINDEX to that set, then you could, say, change a data type, cluster, and change tablespaces all in a single

Re: PostgreSQL partition tables use more private memory

Hi, On 2018/12/27 15:44, 大松 wrote: > # PostgreSQL partition tables use more private memory > > Hi, there is a process private memory issue about partition tables in our > production environment. We're not sure if it's a bug or Pg just works in this > way. > > - when dml operated on partition

Re: Offline enabling/disabling of data checksums

For enable/disable, while the command is running, it should mark the cluster as opened to prevent an unwanted database start. I do not see where this is done. You have pretty much the same class of problems if you attempt to start a cluster on which pg_rewind or the existing

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

On Tue, Dec 25, 2018 at 9:08 AM Michael Paquier wrote: > On Fri, Nov 30, 2018 at 12:24:04PM +1300, Thomas Munro wrote: > > The tests pass and show the feature working correctly. I think this > > is getting close to committable. I see that Magnus has signed up as > > committer. > > It has been

Re: could recovery_target_timeline=latest be the default in standby mode?

On 22/12/2018 00:38, Michael Paquier wrote: > On Fri, Dec 21, 2018 at 01:54:20PM +0300, Sergei Kornilov wrote: >> I am +1 for recovery_target_timeline=latest by default. This is >> common case in my opinion. > > I agree also that switching to the latest timeline should be the > default. People

Re: PostgreSQL partition tables use more private memory

Hi čt 27. 12. 2018 v 11:48 odesílatel 大松 napsal: > # PostgreSQL partition tables use more private memory > > Hi, there is a process private memory issue about partition tables in our > production environment. We're not sure if it's a bug or Pg just works in > this way. > > - when dml operated

Re: tickling the lesser contributor's withering ego

On Fri, Dec 21, 2018 at 4:17 PM Alvaro Herrera wrote: > On 2018-Dec-21, Tom Lane wrote: > > > Alvaro Herrera writes: > > > I propose the following patch, which will make those links stable -- > > > then we can add the following links to the contributors page: > > > >

Re: Offline enabling/disabling of data checksums

On Sat, Dec 22, 2018 at 12:28 AM Michael Paquier wrote: > On Fri, Dec 21, 2018 at 09:16:16PM +0100, Michael Banck wrote: > > I think that this is independently useful, I got this stuff part of an > upgrade workflow where the user is ready to accept some extra one-time > offline time so as

Re: Offline enabling/disabling of data checksums

On Thu, Dec 27, 2018 at 2:15 AM Michael Paquier wrote: > On Wed, Dec 26, 2018 at 07:43:17PM +0100, Fabien COELHO wrote: > >> It adds an (now mandatory) --action parameter that takes either verify, > >> enable or disable as argument. > > > > I'd rather have explicit switches for verify, enable &

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 09/12/2018 19:55, Sergei Kornilov wrote: >> >> An index build with the CONCURRENTLY option failed, >> leaving >> an invalid index. Such indexes are useless but it can be >> - convenient to use REINDEX to rebuild them. Note >> that >> - REINDEX will not perform a

Re: Feature: temporary materialized views

Hi! I made a new version of the patch. I added tests and changes to the docs and made sure various other aspects of this change for as well. I think this now makes temporary materialized views fully implemented and that in my view patch is complete. If there is anything else to add, please let me

Re: Speeding up creating UPDATE/DELETE generic plan for partitioned table into a lot

Kato-san, On 2018/12/27 16:53, Kato, Sho wrote: >> What do you mean by "since the partitions to access are partial"? > > I mean planner create scan nodes based on the parameters specified for > EXECUTE and backend keep them in CachedPlan. > > Before: > > postgres=# explain execute

RE: Timeout parameters

From: Fabien COELHO [mailto:coe...@cri.ensmp.fr] > I still do not understand the use-case specifics: for me, aborting the > connection, or a softer cancelling the statement, will result in the > server stopping the statement, so the server does NOT "continue the job", > so I still do not see how