Re: Partitioning with temp tables is broken

On 2018/06/19 14:47, Michael Paquier wrote: > On Tue, Jun 19, 2018 at 10:56:49AM +0900, Amit Langote wrote: >> On 2018/06/18 15:02, Michael Paquier wrote: >>> Those tests should be upper-case I think to keep consistency with the >>> surrounding code. >> >> As you may have seen in the changed code,

Re: Adding tests for inheritance trees with temporary tables

Thanks. Some review comments here. +create table inh_perm_parent (a1 int); +create temp table inh_temp_parent (a1 int); +create temp table inh_temp_child (a1 int) inherits (inh_perm_parent); -- ok +NOTICE: merging column "a1" with inherited definition You could actually avoid this notice by chan

Re: Concurrency bug in UPDATE of partition-key

On Mon, Jun 18, 2018 at 6:19 PM, Amit Khandekar wrote: > On 18 June 2018 at 17:56, Amit Kapila wrote: >> On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar wrote: >>> Should we also create a test case where we can verify that some >>> unnecessary or duplicate triggers are not executed? >>> >> >> I am

Re: Query Rewrite for Materialized Views (Postgres Extension)

Hi Nico, I’m pretty impressed anything in this space can be written entirely in PlPGQSL! If you did integrate your implementation, it would be easy for my Extension to read from a table other than the one which it gets the MV definition from... Although having said that, if you went down the ro

Re: libpq compression

On 18.06.2018 23:34, Robbie Harwood wrote: t Konstantin Knizhnik writes: On 06.06.2018 02:03, Thomas Munro wrote: On Wed, Jun 6, 2018 at 2:06 AM, Konstantin Knizhnik wrote: Thank you for review. Updated version of the patch fixing all reported problems is attached. Small problem on Win

Re: Partitioning with temp tables is broken

On Tue, Jun 19, 2018 at 04:27:08PM +0900, Amit Langote wrote: > Looking at what changed from my patch: > > -One cannot have both temporary and permanent relations in a given > -partition tree. That is, if the root partitioned table is permanent, > -so must be its partitions at all lev

documenting forbidden expressions in column defaults

Hi. The description of DEFAULT in the documentation currently says: "The value is any variable-free expression (subqueries and cross-references to other columns in the current table are not allowed)." But the value cannot be an aggregate expression, a window function, or a set-returning function

pg_verify_checksums review

In looking over pg_verify_checksums I found a few small things that I think would improve on it: * pg_verify_checksums was placed in the Client Utils section in the docs. Since it requries physical access to the cluster datafiles it seems to belong in the Server Utils section. * The -D option and

Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov wrote: > Hi! > > On Sat, Jun 16, 2018 at 11:23 PM Darafei "Komяpa" Praliaskouski > wrote: >> It is cool to see this in Postgres 11. However: >> >>> >>> 4) vacuum_cleanup_index_scale_factor can be set either by GUC or reloption. >>> Default value

Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.

On Mon, Jun 18, 2018 at 9:27 PM, Andres Freund wrote: > On 2018-06-18 17:10:12 +0530, Jeevan Chalke wrote: > > On Mon, Jun 18, 2018 at 5:02 PM, Rajkumar Raghuwanshi < > > rajkumar.raghuwan...@enterprisedb.com> wrote: > > > > > Hi, > > > > > > Below test case crashed, when set enable_partitionwise

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada wrote: > On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov > > So, I'm proposing to raise maximum valus of > > vacuum_cleanup_index_scale_factor to DBL_MAX. Any objections? > > > > I agree to expand the maximum value. But if users don't want inde

Re: partition -> partitioned

On 2018/05/17 11:48, Amit Langote wrote: > On 2018/05/17 11:40, David Rowley wrote: >> On 17 May 2018 at 13:52, Amit Langote wrote: >>> Commit 499be013de6 used 'partition' where it really meant 'partitioned' in >>> a few places including in a variable name. For example, what almost all >>> places

Re: partition -> partitioned

On 2018/06/19 17:51, Amit Langote wrote: > On 2018/05/17 11:48, Amit Langote wrote: >> On 2018/05/17 11:40, David Rowley wrote: >>> On 17 May 2018 at 13:52, Amit Langote wrote: Commit 499be013de6 used 'partition' where it really meant 'partitioned' in a few places including in a variable

Re: WAL prefetch

On 18.06.2018 23:47, Andres Freund wrote: On 2018-06-18 16:44:09 -0400, Robert Haas wrote: On Sat, Jun 16, 2018 at 3:41 PM, Andres Freund wrote: The posix_fadvise approach is not perfect, no doubt about that. But it works pretty well for bitmap heap scans, and it's about 13249x better (roug

RE: Add function to release an allocated SQLDA

Hi Thomas Thank you for your reply. >This is not clear to me. ECPGfreeSQLDA() releases a whole chain, but >free() only releases a single SQLDA(), so they are obviously not >interchangeable. When exactly should a user prefer one over the other? If an application use FETCH ALL to get the result

Re: Postgres 11 release notes

On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski wrote: >> >> > I'm not sure it is usefull in release notes since it is more about API, >> > and not >> > user-facing change. Just in case. >> > GiST opclasses now can omit compress and decompress functions. If compress >> > function i

Re: Partitioning with temp tables is broken

On Tue, Jun 19, 2018 at 1:24 PM, Michael Paquier wrote: > On Tue, Jun 19, 2018 at 04:27:08PM +0900, Amit Langote wrote: >> Looking at what changed from my patch: >> >> -One cannot have both temporary and permanent relations in a given >> -partition tree. That is, if the root partitioned t

Re: Invisible Indexes

On 19.06.2018 01:11, Andres Freund wrote: On 2018-06-18 18:05:11 -0400, Tom Lane wrote: Andres Freund writes: On 2018-06-18 17:57:04 -0400, Tom Lane wrote: I think the actually desirable way to handle this sort of thing is through an "index advisor" sort of plugin, which can hide a given i

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Jun 19, 2018 at 5:43 PM, Alexander Korotkov wrote: > On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada > wrote: >> On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov >> > So, I'm proposing to raise maximum valus of >> > vacuum_cleanup_index_scale_factor to DBL_MAX. Any objections? >> >

Re: [WIP] [B-Tree] Retail IndexTuple deletion

On Tue, Jun 19, 2018 at 8:05 AM, Peter Geoghegan wrote: > On Mon, Jun 18, 2018 at 2:54 PM, Peter Geoghegan wrote: >> On Sun, Jun 17, 2018 at 9:39 PM, Andrey V. Lepikhov >> wrote: >>> Patch '0001-retail-indextuple-deletion' introduce new function >>> amtargetdelete() in access method interface. P

Re: Index Skip Scan

> On 18 June 2018 at 19:31, Alexander Korotkov > wrote: >> >> A couple of questions to begin with. >> >> Should the patch continue to "piggy-back" on T_IndexOnlyScan, or should >> a new node (T_IndexSkipScan) be created ? If latter, then there likely >> will be functionality that needs to be refa

Possible Spinlock impact of highly increased latency of PAUSE instruction on Skylake

Hi all, I just read an article about a recent architecture change in newer Intel processors. As mentioned in [1] https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpus-are-sometimes-50-slower-how-intel-has-broken-existing-code/ Intel changed the latency respective reciproque throug

Re: Postgres 11 release notes

On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov wrote: > On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski > wrote: > >> > >> > I'm not sure it is usefull in release notes since it is more about API, > >> > and not > >> > user-facing change. Just in case. > >> > GiST opclasses n

Re: Partitioning with temp tables is broken

On Tue, Jun 19, 2018 at 02:50:44PM +0530, Ashutosh Bapat wrote: > + > + > + > + Mixing temporary and permanent relations in the same partition tree > + is not allowed. Hence, if the root partitioned table is permanent, > > Do we want to mention "root" explicitly here? Yes,

Re: Partitioning with temp tables is broken

On Tue, Jun 19, 2018 at 4:22 PM, Michael Paquier wrote: > > I was under the impression that this was implied in the precious > phrasing but you guys visibly don't match with my impression. So I > would suggest this paragraph at the end: > "Mixing temporary and permanent relations in the same part

Re: WAL prefetch

On 06/19/2018 11:08 AM, Konstantin Knizhnik wrote: On 18.06.2018 23:47, Andres Freund wrote: On 2018-06-18 16:44:09 -0400, Robert Haas wrote: On Sat, Jun 16, 2018 at 3:41 PM, Andres Freund wrote: The posix_fadvise approach is not perfect, no doubt about that. But it works pretty well for

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Mon, Jun 18, 2018 at 10:33 PM, Peter Geoghegan wrote: > On Mon, Jun 18, 2018 at 7:57 AM, Claudio Freire > wrote: >> Way back when I was dabbling in this kind of endeavor, my main idea to >> counteract that, and possibly improve performance overall, was a >> microvacuum kind of thing that woul

Re: MERGE SQL statement for PG12

On 06/19/2018 07:06 AM, Pavan Deolasee wrote: Hello, I would like to resubmit the MERGE patch for PG12. The past discussions about the patch can be found here [1] [2]. The patch is rebased on the current master. But otherwise I haven't done any further work on it since it was punted from

Re: MERGE SQL statement for PG12

On Tue, Jun 19, 2018 at 4:41 PM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > It's already in the commitfest, although I think it's almost certain to be > pushed out to the September CF. I'll add this email to the existing item. > > Thanks Andrew; I was gonna do that once the emai

Re: WAL prefetch

On 19.06.2018 14:03, Tomas Vondra wrote: On 06/19/2018 11:08 AM, Konstantin Knizhnik wrote: On 18.06.2018 23:47, Andres Freund wrote: On 2018-06-18 16:44:09 -0400, Robert Haas wrote: On Sat, Jun 16, 2018 at 3:41 PM, Andres Freund wrote: The posix_fadvise approach is not perfect, no dou

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/06/15 20:56), Etsuro Fujita wrote: Actually, I've created a patch implementing that proposal. But I think that patch needs more work, so I'm planning to post it next week. Here is a patch for that. * As I said upthread, the patch makes code much more simple; I removed all the changes

Re: WAL prefetch

On 06/19/2018 02:33 PM, Konstantin Knizhnik wrote: On 19.06.2018 14:03, Tomas Vondra wrote: On 06/19/2018 11:08 AM, Konstantin Knizhnik wrote: ... >>> Also there are two points which makes prefetching into shared buffers more complex: 1. Need to spawn multiple workers to make prefetch in p

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

On Fri, May 25, 2018 at 3:37 PM, Andres Freund wrote: > Hi, > > Moving discussion to -hackers. Tom, I think you worked most with this > code, your input would be appreciated. > > Original discussion is around: > http://archives.postgresql.org/message-id/20180524211311. > tnswfnjwnii54htx%40alvhe

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Hello friends. On Tue, Jun 12, 2018 at 3:31 PM, Andres Freund wrote: > > On 2018-06-11 17:39:14 -0700, Andres Freund wrote: > > I plan to go over the change again tomorrow, and then push. Unless > > somebody has comments before then, obviously. > > Done. > > Sorry to bother about this, but do yo

Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.

On Tue, Jun 19, 2018 at 2:13 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > > > On Mon, Jun 18, 2018 at 9:27 PM, Andres Freund wrote: > >> On 2018-06-18 17:10:12 +0530, Jeevan Chalke wrote: >> > On Mon, Jun 18, 2018 at 5:02 PM, Rajkumar Raghuwanshi < >> > rajkumar.raghuwan...@enterp

Re: missing toast table for pg_policy

On 2/20/18, Michael Paquier wrote: > Regression tests of pg_upgrade are failing as follows: > New cluster database "postgres" is not empty > Failure, exiting > + rm -rf /tmp/pg_upgrade_check-Xn0ZLe I looked into this briefly. The error comes from check_new_cluster_is_empty() in src/bin/pg_upgrade

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

On Tue, Jun 19, 2018 at 8:26 AM Matheus de Oliveira < matioli.math...@gmail.com> wrote: > Hello friends. > > On Tue, Jun 12, 2018 at 3:31 PM, Andres Freund wrote: > >> >> On 2018-06-11 17:39:14 -0700, Andres Freund wrote: >> > I plan to go over the change again tomorrow, and then push. Unless >>

Re: WAL prefetch

On Tue, Jun 19, 2018 at 4:04 PM Tomas Vondra wrote: > Right. My point is that while spawning bgworkers probably helps, I don't > expect it to be enough to fill the I/O queues on modern storage systems. > Even if you start say 16 prefetch bgworkers, that's not going to be > enough for large arrays

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

On Mon, Jun 18, 2018 at 11:36 PM, Amit Kapila wrote: > Fixed in the attached patch. I will wait for a day or two to see if > Tom or Robert wants to say something and then commit. The patch LGTM but the commit message could perhaps use a little word-smithing, e.g. "Commit ab72716778 allowed Paral

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

On Sun, Jun 17, 2018 at 10:59 PM, David Rowley wrote: > Thanks for looking. > > Robert, do you have any objections to the proposed patch? I don't have time to study this right now, but I think the main possible objection is around performance. If not flattening the Append is the best way to make

Re: [bug fix] ECPG: freeing memory for pgtypes crashes on Windows

On Mon, Jun 11, 2018 at 10:04 AM, Tom Lane wrote: > Given that this has been broken since forever, and there've been > no complaints before now, I do not think the case for back-patching > is strong enough to justify the problems it would cause. Just > put it in v11 and be done. I'm not sure I u

Re: Excessive CPU usage in StandbyReleaseLocks()

On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: > This should be a PANIC imo. -1. As a developer, I would prefer PANIC. But as an end-user, I would much rather have replay continue (with possible problems) than have it stopped cold in its tracks with absolutely nothing that I as the admin

Re: WAL prefetch

On 19.06.2018 16:57, Ants Aasma wrote: On Tue, Jun 19, 2018 at 4:04 PM Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote: Right. My point is that while spawning bgworkers probably helps, I don't expect it to be enough to fill the I/O queues on modern storage systems.

Fast default stuff versus pg_upgrade

AFAICS, the fast-default patch neglected to consider what happens if a database containing columns with active attmissingval entries is pg_upgraded. I do not see any code in either pg_dump or pg_upgrade that attempts to deal with that situation, which means the effect will be that the "missing" va

Re: [HACKERS] Custom compression methods

On Mon, Apr 23, 2018 at 12:34 PM, Konstantin Knizhnik wrote: > May be. But in any cases, there are several direction where compression can > be used: > - custom compression algorithms > - libpq compression > - page level compression > ... > > and them should be somehow finally "married" with each

Re: WAL prefetch

On 06/19/2018 04:50 PM, Konstantin Knizhnik wrote: On 19.06.2018 16:57, Ants Aasma wrote: On Tue, Jun 19, 2018 at 4:04 PM Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote: Right. My point is that while spawning bgworkers probably helps, I don't expect it to be enough

Re: Postgres 11 release notes

> On 19 Jun 2018, at 12:40, Alexander Korotkov > wrote: > > On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov > wrote: >> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski >> wrote: > I'm not sure it is usefull in release notes since it is more about API, > and no

Re: Postgres 11 release notes

On Tue, Jun 19, 2018 at 6:18 PM Daniel Gustafsson wrote: > > On 19 Jun 2018, at 12:40, Alexander Korotkov > > wrote: > > > > On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov > > wrote: > >> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski > >> wrote: > > > I'm not sur

Re: Query Rewrite for Materialized Views (Postgres Extension)

On Tue, Jun 19, 2018 at 08:46:06AM +0100, Dent John wrote: > I’m pretty impressed anything in this space can be written entirely in > PlPGQSL! https://github.com/twosigma/postgresql-contrib PG is quite powerful! I have even implemented a COMMIT TRIGGER in pure PlPgSQL. You'll notice I make exte

Re: WAL prefetch

On 2018-06-19 12:08:27 +0300, Konstantin Knizhnik wrote: > I do not think that prefetching in shared buffers requires much more efforts > and make patch more envasive... > It even somehow simplify it, because there is no to maintain own cache of > prefetched pages... > But it will definitely have

Re: Fast default stuff versus pg_upgrade

On 06/19/2018 10:55 AM, Tom Lane wrote: AFAICS, the fast-default patch neglected to consider what happens if a database containing columns with active attmissingval entries is pg_upgraded. I do not see any code in either pg_dump or pg_upgrade that attempts to deal with that situation, which m

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Hi, On 2018-06-19 10:26:26 -0300, Matheus de Oliveira wrote: > Hello friends. > > On Tue, Jun 12, 2018 at 3:31 PM, Andres Freund wrote: > > > > > On 2018-06-11 17:39:14 -0700, Andres Freund wrote: > > > I plan to go over the change again tomorrow, and then push. Unless > > > somebody has commen

Re: missing toast table for pg_policy

On 2018-02-18 11:18:49 -0500, Tom Lane wrote: > Joe Conway writes: > > Is there really a compelling reason to not just create toast tables for > > all system catalogs as in the attached? > > What happens when you VACUUM FULL pg_class? (The associated toast table > would have to be nonempty for t

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Jun 19, 2018 at 12:25 PM Masahiko Sawada wrote: > On Tue, Jun 19, 2018 at 5:43 PM, Alexander Korotkov > wrote: > > On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada > > wrote: > >> On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov > >> > So, I'm proposing to raise maximum valus of > >>

Re: Concurrency bug in UPDATE of partition-key

On 19 June 2018 at 13:06, Dilip Kumar wrote: > On Mon, Jun 18, 2018 at 6:19 PM, Amit Khandekar > wrote: >> On 18 June 2018 at 17:56, Amit Kapila wrote: >>> On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar wrote: Should we also create a test case where we can verify that some unnecessary

Re: Fast default stuff versus pg_upgrade

Hi, On 2018-06-19 11:51:16 -0400, Andrew Dunstan wrote: > My initial thought was that as a fallback we should disable pg_upgrade on > databases containing such values, and document the limitation in the docs > and the release notes. The workaround would be to force a table rewrite > which would cl

Re: Fast default stuff versus pg_upgrade

Andres Freund writes: > On 2018-06-19 11:51:16 -0400, Andrew Dunstan wrote: >> Have we ever recommended use of pg_upgrade for some manual catalog fix after >> release? I don't recall doing so. Certainly it hasn't been common. > No, but why does it matter? We absolutely have, as recently as last

Re: Fast default stuff versus pg_upgrade

Andrew Dunstan writes: > I have no idea how large an actual fix might be. I'll at least start > working on it immediately. I agree it's very late in the day. On reflection, it seems like there are two moving parts needed: * Add a binary-upgrade support function to the backend, which would take,

Re: Fast default stuff versus pg_upgrade

On 06/19/2018 12:05 PM, Andres Freund wrote: Hi, On 2018-06-19 11:51:16 -0400, Andrew Dunstan wrote: My initial thought was that as a fallback we should disable pg_upgrade on databases containing such values, and document the limitation in the docs and the release notes. The workaround would

Re: Fast default stuff versus pg_upgrade

On 2018-06-19 12:17:56 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > I have no idea how large an actual fix might be. I'll at least start > > working on it immediately. I agree it's very late in the day. > > On reflection, it seems like there are two moving parts needed: > > * Add a binar

Re: WAL prefetch

On 19.06.2018 18:50, Andres Freund wrote: On 2018-06-19 12:08:27 +0300, Konstantin Knizhnik wrote: I do not think that prefetching in shared buffers requires much more efforts and make patch more envasive... It even somehow simplify it, because there is no to maintain own cache of prefetched

Re: Fast default stuff versus pg_upgrade

On 2018-06-19 12:17:59 -0400, Andrew Dunstan wrote: > > > On 06/19/2018 12:05 PM, Andres Freund wrote: > > Hi, > > > > On 2018-06-19 11:51:16 -0400, Andrew Dunstan wrote: > > > My initial thought was that as a fallback we should disable pg_upgrade on > > > databases containing such values, and d

Re: Fast default stuff versus pg_upgrade

Andres Freund writes: > On 2018-06-19 12:17:56 -0400, Tom Lane wrote: >> The hard part here is how exactly are we going to represent the default >> value. AFAICS, the only thing that pg_dump could readily lay its hands >> on is the "anyarray" textual representation of attmissingval, which maybe >

Re: WAL prefetch

On 06/19/2018 05:50 PM, Andres Freund wrote: On 2018-06-19 12:08:27 +0300, Konstantin Knizhnik wrote: I do not think that prefetching in shared buffers requires much more efforts and make patch more envasive... It even somehow simplify it, because there is no to maintain own cache of prefetch

Re: WAL prefetch

On 2018-06-19 19:34:22 +0300, Konstantin Knizhnik wrote: > On 19.06.2018 18:50, Andres Freund wrote: > > On 2018-06-19 12:08:27 +0300, Konstantin Knizhnik wrote: > > > I do not think that prefetching in shared buffers requires much more > > > efforts > > > and make patch more envasive... > > > It

Re: WAL prefetch

Hi, On 2018-06-19 18:41:24 +0200, Tomas Vondra wrote: > I'm confused. I thought you wanted to prefetch directly to shared buffers, > so that it also works with direct I/O in the future. But now you suggest to > use posix_fadvise() to work around the synchronous buffer read limitation. I > don't fo

Re: Fast default stuff versus pg_upgrade

Hi, On 2018-06-19 12:37:52 -0400, Tom Lane wrote: > Andres Freund writes: > > And if the default value bugs us, > > we can easily add a support function that dumps the value without the > > anyarray adornment? > > The problem here is that that function does not exist in 11beta1. > Since adding t

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Hi, On 2018-06-19 08:25:33 -0500, Jeremy Finzel wrote: > I have a question related to this - and specifically, preventing the error > until we have a patch :). The patch has been committed to postgres, although no release has been made including it yet. > We are encountering this error every fe

Re: Index Skip Scan

Hi Alexander, On 06/18/2018 01:31 PM, Alexander Korotkov wrote: wrote: Should the patch continue to "piggy-back" on T_IndexOnlyScan, or should a new node (T_IndexSkipScan) be created ? If latter, then there likely will be functionality that needs to be refactored into shared code between the n

Re: Excessive CPU usage in StandbyReleaseLocks()

Hi, On 2018-06-19 10:45:04 -0400, Robert Haas wrote: > On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: > > This should be a PANIC imo. > > -1. As a developer, I would prefer PANIC. But as an end-user, I > would much rather have replay continue (with possible problems) than > have it stop

Re: Excessive CPU usage in StandbyReleaseLocks()

On Tue, Jun 19, 2018 at 1:01 PM, Andres Freund wrote: > On 2018-06-19 10:45:04 -0400, Robert Haas wrote: >> On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: >> > This should be a PANIC imo. >> >> -1. As a developer, I would prefer PANIC. But as an end-user, I >> would much rather have repl

Re: Index Skip Scan

Hi Dmitry, On 06/19/2018 06:01 AM, Dmitry Dolgov wrote: On 18 June 2018 at 19:31, Alexander Korotkov wrote: Is skip scan only possible for index-only scan? I guess, that no. We could also make plain index scan to behave like a skip scan. And it should be useful for accelerating DISTINCT ON c

Re: WAL prefetch

On 06/19/2018 06:34 PM, Konstantin Knizhnik wrote: On 19.06.2018 18:50, Andres Freund wrote: On 2018-06-19 12:08:27 +0300, Konstantin Knizhnik wrote: I do not think that prefetching in shared buffers requires much more efforts and make patch more envasive... It even somehow simplify it, beca

Re: Fast default stuff versus pg_upgrade

On Tue, Jun 19, 2018 at 12:37 PM, Tom Lane wrote: > The problem here is that that function does not exist in 11beta1. > Since adding the "incoming" function is certainly going to require > initdb, we have to be able to dump from the server as it now stands, > or we'll be cutting existing beta test

Re: Fast default stuff versus pg_upgrade

Andres Freund writes: > On 2018-06-19 12:37:52 -0400, Tom Lane wrote: >> The problem here is that that function does not exist in 11beta1. >> Since adding the "incoming" function is certainly going to require >> initdb, we have to be able to dump from the server as it now stands, >> or we'll be cu

Re: Excessive CPU usage in StandbyReleaseLocks()

On 2018-06-19 13:05:48 -0400, Robert Haas wrote: > On Tue, Jun 19, 2018 at 1:01 PM, Andres Freund wrote: > > On 2018-06-19 10:45:04 -0400, Robert Haas wrote: > >> On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund wrote: > >> > This should be a PANIC imo. > >> > >> -1. As a developer, I would prefer

Re: Fast default stuff versus pg_upgrade

On Tue, Jun 19, 2018 at 10:12 AM, Robert Haas wrote: > I have to admit that I think this feature is scary. I'm not sure that > it was adequately reviewed and tested, and I'm worried this may not be > the only problem it causes. But this particular problem, as Andres > says, doesn't seem like anyth

Re: [WIP] [B-Tree] Retail IndexTuple deletion

On Tue, Jun 19, 2018 at 2:33 AM, Masahiko Sawada wrote: > I think that we do the partial lazy vacuum using visibility map even > now. That does heap pruning, index tuple killing but doesn't advance > relfrozenxid. Right, that's what I was thinking. Opportunistic HOT pruning isn't like vacuuming b

Re: Fast default stuff versus pg_upgrade

On 06/19/2018 01:19 PM, Tom Lane wrote: Andres Freund writes: On 2018-06-19 12:37:52 -0400, Tom Lane wrote: The problem here is that that function does not exist in 11beta1. Since adding the "incoming" function is certainly going to require initdb, we have to be able to dump from the server

Re: Fast default stuff versus pg_upgrade

On Tue, Jun 19, 2018 at 9:37 AM, Tom Lane wrote: > The problem here is that that function does not exist in 11beta1. > Since adding the "incoming" function is certainly going to require > initdb, we have to be able to dump from the server as it now stands, > or we'll be cutting existing beta test

Re: ToDo: show size of partitioned table

On Fri, Jun 1, 2018 at 8:51 PM, Pavel Stehule wrote: > > > 2018-06-01 17:15 GMT+02:00 Ashutosh Bapat >: > >> On Fri, Jun 1, 2018 at 12:56 AM, Pavel Stehule >> wrote: >> > Hi >> > >> > postgres=# SELECT count(*) from data; >> > ┌─┐ >> > │ count │ >> > ╞═╡ >> > │ 100 │ >> >

Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On Tue, Jun 19, 2018 at 4:03 AM, Amit Kapila wrote: >> I imagine that retail index tuple deletion (the whole point of this >> project) would be run by a VACUUM-like process that kills tuples that >> are dead to everyone. Even with something like zheap, you cannot just >> delete index tuples until

Re: Excessive CPU usage in StandbyReleaseLocks()

Andres Freund writes: > On 2018-06-19 13:05:48 -0400, Robert Haas wrote: >> I don't expect you to agree with my vote, but I stand by it. > Yea, I didn't expect (but hoped!) to change your mind... ;) FWIW, I agree with Robert --- a PANIC here will certainly create problems, and it's much less cle

Re: MERGE SQL statement for PG12

On Tue, Jun 19, 2018 at 4:06 AM, Pavan Deolasee wrote: > I would like to resubmit the MERGE patch for PG12. The past discussions > about the patch can be found here [1] [2]. FWIW, I'm really glad that you're going to work on this for v12. -- Peter Geoghegan

Re: Fast default stuff versus pg_upgrade

"David G. Johnston" writes: > On Tue, Jun 19, 2018 at 9:37 AM, Tom Lane wrote: >> The problem here is that that function does not exist in 11beta1. >> Since adding the "incoming" function is certainly going to require >> initdb, we have to be able to dump from the server as it now stands, >> or w

Re: Invisible Indexes

On Mon, Jun 18, 2018 at 6:12 PM, Tom Lane wrote: > Peter Geoghegan writes: >> On Mon, Jun 18, 2018 at 2:57 PM, Tom Lane wrote: >>> I think the actually desirable way to handle this sort of thing is through >>> an "index advisor" sort of plugin, which can hide a given index from the >>> planner w

Re: Invisible Indexes

2018-06-19 15:05 GMT-03:00 Robert Haas : > Yeah, I agree that a GUC seems more powerful and easier to roll out. > A downside is that there could be cached plans still using that old > index. If we did DDL on the index we could be sure they all got > invalidated, but otherwise how do we know? > If

Re: Invisible Indexes

On Tue, Jun 19, 2018 at 12:22 PM, Euler Taveira wrote: > If we want to test the effect of disabling an index, we could set GUC > only on the current session. DDL will make the index invisible > immediately. Things can go worse after that. I prefer the former. It > is more conservative but could co

Re: Add necessary package list to ldap TAP's README

On Mon, May 21, 2018 at 10:34:25AM +0900, Michael Paquier wrote: > Hi all, > > The kerberos test suite mentions the package list to use on a set of > distributions, which is very useful. However we don't do the same for > ldap. Something like the attached would be adapted then to help setting >

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

On Tue, Jun 19, 2018 at 12:53 PM, Andres Freund wrote: > Hi, > > On 2018-06-19 10:26:26 -0300, Matheus de Oliveira wrote: > > Hello friends. > > > > On Tue, Jun 12, 2018 at 3:31 PM, Andres Freund > wrote: > > > > > > > > On 2018-06-11 17:39:14 -0700, Andres Freund wrote: > > > > I plan to go ove

Re: Invisible Indexes

Hi, On 2018-06-19 14:05:24 -0400, Robert Haas wrote: > Yeah, I agree that a GUC seems more powerful and easier to roll out. > A downside is that there could be cached plans still using that old > index. If we did DDL on the index we could be sure they all got > invalidated, but otherwise how do w

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Hi, On 2018-06-19 17:05:48 -0300, Matheus de Oliveira wrote: > > You should first make sure it's actually this problem - which tables are > > holding back the xmin horizon? > > > How can I be sure? The tables are `pg_authid` and `pg_auth_members`, the > following message is logged every minute (

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

Hello hackers, Any objections fixing this on Pg11? My opinion is that it's better to fix it now rather than waiting for pg12. It's already broken in pg10 (xmltable) and older (rest of the xml stuff). As Markus advised, I'd not backpatch fixes for fear of breaking stuff, but I'd rather release p

Re: Time to put context diffs in the grave

On Wed, May 23, 2018 at 05:01:58PM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > OK, that's done. Now I think we can get rid of git-external-diff. > > I for one rely on that. I won't tell anyone else what kind of diff > they have to read, but if you try to tell me what kind of diff I have

Re: Time to put context diffs in the grave

Hi, On 2018-05-21 21:51:11 -0400, Andrew Dunstan wrote: > > We haven't insisted on context diffs in years now, and one of my > interlocutors has just turned handsprings trying to follow the advice at > to produce his first > patch. > > > Unles

Re: libpq compression

Konstantin Knizhnik writes: > On 18.06.2018 23:34, Robbie Harwood wrote: > >> I also don't like that you've injected into the *startup* path - >> before authentication takes place. Fundamentally, authentication (if >> it happens) consists of exchanging some combination of short strings >> (e.g.,

Re: Time to put context diffs in the grave

On 06/19/2018 04:54 PM, Andres Freund wrote: Hi, On 2018-05-21 21:51:11 -0400, Andrew Dunstan wrote: We haven't insisted on context diffs in years now, and one of my interlocutors has just turned handsprings trying to follow the advice at t

Re: Time to put context diffs in the grave

On 2018-06-19 17:18:32 -0400, Andrew Dunstan wrote: > On 06/19/2018 04:54 PM, Andres Freund wrote: > > Could we please also change pg_regress' diff invocations? I find it > > really painful to see differences in buildfarm output due to the > > -C3. Locally I've long exported PG_REGRESS_DIFF_OPTS, b

Re: Time to put context diffs in the grave

On 06/19/2018 05:21 PM, Andres Freund wrote: Given that we've "officially" stopped relying on context diffs, I don't see why we'd not also retire them in pg_regress. Well I suspect at least one person would be made unhappy ;-) cheers andrew -- Andrew Dunstanhttps://www.

Re: PostgreSQL and Homomorphic Encryption

On Wed, May 23, 2018 at 09:05:15AM +0800, Craig Ringer wrote: > Presumably it'd have to support some non-equality ops like < and > for b-tree > indexing, so you can compare two encrypted texts without decryption. > > If the user can supply cleartext to be compared against, this exposes > search-ba

  1   2   >