Re: ToDo: show size of partitioned table

On 2018/06/02 0:15, Ashutosh Bapat wrote: > I think we should at least display "Type" as "partitioned table" for a > partitioned table, so that it's easy to understand why the size is 0; > partitioned tables do not hold any data by themselves. There was a long discussion last year (during PG 10

Re: Spilling hashed SetOps and aggregates to disk

On Fri, 2018-06-15 at 12:30 -0700, David Gershuni wrote: > For example, imagine a tuple that belongs to a group G in grouping > set A had to be > spilled because it also belonged to an evicted group from grouping > set B. Then group > G would remain in set A’s hash table at the end of the phase,

Re: Partitioning with temp tables is broken

On 20/06/18 16:47, Michael Paquier wrote: On Wed, Jun 20, 2018 at 01:32:58PM +0900, Amit Langote wrote: Just a minor nit in the last sentence: "have to be from" -> "must be from / must belong to" I think that both have the same meaning, but I am no native speaker so I may be missing a nuance

Re: Possible bug in logical replication.

On Mon, Jun 18, 2018 at 09:42:36PM +0900, Michael Paquier wrote: > On Fri, Jun 15, 2018 at 06:27:56PM +0300, Arseny Sher wrote: > It seems to me that we still want to have the slot forwarding finish in > this case even if this is interrupted. Petr, isn't that the intention > here? I have been

Re: [HACKERS] GUC for cleanup indexes threshold.

On Wed, Jun 20, 2018 at 1:00 AM, Alexander Korotkov wrote: > 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,

Re: Partitioning with temp tables is broken

On Wed, Jun 20, 2018 at 01:32:58PM +0900, Amit Langote wrote: > Just a minor nit in the last sentence: > > "have to be from" -> "must be from / must belong to" I think that both have the same meaning, but I am no native speaker so I may be missing a nuance of some kind. -- Michael

Re: Partitioning with temp tables is broken

On 2018/06/20 10:54, Michael Paquier wrote: > On Tue, Jun 19, 2018 at 04:26:56PM +0530, Ashutosh Bapat wrote: >> 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

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

Michael Paquier writes: > On Tue, Jun 19, 2018 at 06:59:36PM -0400, Tom Lane wrote: >> No, but it needs some adjustments. I'll go fix what I checked. > c992dca2 did not change anything about ldap packages. Are the ones > listed for RHEL and FreeBSD correct? No, that patch was

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

On Tue, Jun 19, 2018 at 8:52 PM, Amit Kapila wrote: > Both values will be present in the index, but the old value will be > delete-marked. It is correct that we can't remove the value (index > tuple) from the index until it is truly dead (not visible to anyone), > but during a delete or

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

On Wed, Jun 20, 2018 at 12:59:04PM +0900, Michael Paquier wrote: > On Tue, Jun 19, 2018 at 06:59:36PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > >> On Tue, Jun 19, 2018 at 06:45:54PM -0400, Tom Lane wrote: > >>> I was a bit disturbed that you'd push information that was "just guessed", >

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

On 19.06.2018 04:05, 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. Patch

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

On Wed, Jun 20, 2018 at 11:06:52AM +1200, Thomas Munro wrote: > I think he used Brew paths? > > https://www.postgresql.org/message-id/0a7646b1-f6f6-1364-f0e3-814aed302db4%402ndquadrant.com Yes, stuff in /usr/local/ involves homebrew. -- Michael signature.asc Description: PGP signature

Re: partition -> partitioned

On 2018-Jun-20, Michael Paquier wrote: > On Tue, Jun 19, 2018 at 06:02:22PM +0900, Amit Langote wrote: > > Noticed that the relevant code changed, so I rebased the patch. Also, > > made a minor update to a nearby comment. > > That looks right to me as we speak about non-leaf partitions here. >

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

On Tue, Jun 19, 2018 at 06:59:36PM -0400, Tom Lane wrote: > Bruce Momjian writes: >> On Tue, Jun 19, 2018 at 06:45:54PM -0400, Tom Lane wrote: >>> I was a bit disturbed that you'd push information that was "just guessed", >>> so I went and tried to run the ldap tests on a couple different

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

On Tue, Jun 19, 2018 at 11:13 PM, Peter Geoghegan wrote: > 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

Re: partition -> partitioned

On Tue, Jun 19, 2018 at 06:02:22PM +0900, Amit Langote wrote: > Noticed that the relevant code changed, so I rebased the patch. Also, > made a minor update to a nearby comment. That looks right to me as we speak about non-leaf partitions here. Alvaro, as 499be013 is yours, would you fix this

Re: Fast default stuff versus pg_upgrade

On 2018-06-19 22:41:26 -0400, Andrew Dunstan wrote: > This unfortunately crashes and burns if we use DirectFunctionCall3 to call > array_in, because it uses fn_extra. There is the CallerFInfoFunctionCall > stuff, but it only has 1 and 2 arg variants, and array_in takes 3. In > retrospect we should

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: Partitioning with temp tables is broken

On Tue, Jun 19, 2018 at 04:26:56PM +0530, Ashutosh Bapat wrote: > 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

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

On 20 June 2018 at 02:28, Robert Haas wrote: > On Sun, Jun 17, 2018 at 10:59 PM, David Rowley >> 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 >

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

On Wed, Jun 20, 2018 at 10:45 AM, Tom Lane wrote: > FreeBSD 12: you need openldap-client (NOT openldap24-client) to build > with --with-ldap at all. Then also openldap-server to run this test. Well, it's "pkg install openldap-client" but it's "net/openldap24-client" if you're building ports

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

Bruce Momjian writes: > On Tue, Jun 19, 2018 at 06:45:54PM -0400, Tom Lane wrote: >> I was a bit disturbed that you'd push information that was "just guessed", >> so I went and tried to run the ldap tests on a couple different platforms. > I assumed they were guessed at and at least the URLs

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

On Tue, Jun 19, 2018 at 06:45:54PM -0400, Tom Lane wrote: > I was a bit disturbed that you'd push information that was "just guessed", > so I went and tried to run the ldap tests on a couple different platforms. I assumed they were guessed at and at least the URLs checked out. Should we remove

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

Bruce Momjian writes: > On Mon, May 21, 2018 at 10:34:25AM +0900, Michael Paquier wrote: >> 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

pglife and post-beta commits

FYI, you can now see all the commits since the most recent beta in pglife (http://pglife.momjian.us/). It is the plus sign link after "11 beta". The link currently is:

Re: Time to put context diffs in the grave

On 06/19/2018 05:45 PM, Peter Geoghegan wrote: On Tue, Jun 19, 2018 at 2:41 PM, Tom Lane wrote: Not requiring them is considerably different from actually trying to stamp them out. To my mind, where we're trying to go here is not having one set of people impose their diff format

Re: Time to put context diffs in the grave

On Tue, Jun 19, 2018 at 2:41 PM, Tom Lane wrote: > Not requiring them is considerably different from actually trying > to stamp them out. To my mind, where we're trying to go here is > not having one set of people impose their diff format preferences > on other people. Am I the only one that

Re: Time to put context diffs in the grave

On 2018-06-19 17:41:00 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > 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

Re: Time to put context diffs in the grave

Andrew Dunstan writes: > 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 ;-) Not requiring them is considerably

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 >

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 Dunstan

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,

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

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 >>

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. > > >

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: 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

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: 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

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

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: 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

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 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

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

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: 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

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: 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: 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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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: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

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

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

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

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

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

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: 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

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

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

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: 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

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

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

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: [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

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"

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.

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

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

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

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

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

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: 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

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 < >> >

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

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. >

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

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

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

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

  1   2   >