Re: AS OF queries

On 26.01.2018 03:55, Bruce Momjian wrote: On Sat, Dec 23, 2017 at 11:53:19PM +0300, konstantin knizhnik wrote: On Dec 23, 2017, at 2:08 AM, Greg Stark wrote: On 20 December 2017 at 12:45, Konstantin Knizhnik wrote: It seems to me that it will be not so

Re: [HACKERS] GnuTLS support

> On 26 Jan 2018, at 02:10, Michael Paquier wrote: > On Fri, Jan 26, 2018 at 12:27:16AM +0100, Daniel Gustafsson wrote: >> While only tangentially related to the issue this patch solves, converting >> be_tls_get_peerdn_name() to return const char * seems reasonable too

Re: JIT compiling with LLVM v9.0

Hi, I've spent the last weeks working on my LLVM compilation patchset. In the course of that I *heavily* revised it. While still a good bit away from committable, it's IMO definitely not a prototype anymore. Below are results on my system for Q1 TPC-H scale 10 (~13Gb database) Options

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On 21 January 2018 at 19:21, David Rowley wrote: > On 20 January 2018 at 18:50, Tom Lane wrote: >> Stephen Froehlich writes: >>> Are custom statistics in PG10 retained in LIKE (INCLUDING ALL) or do I need >>> to

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Jan 26, 2018 at 12:00 PM, Peter Geoghegan wrote: > On Thu, Jan 25, 2018 at 10:00 PM, Amit Kapila wrote: >>> At this point, my preferred solution is for someone to go implement >>> Amit's WaitForParallelWorkersToAttach() idea [1] (Amit himself seems

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Mon, 2018-01-08 at 11:18 -0500, Robert Haas wrote: > I also don't agree with the idea that we should reject syntax that > doesn't appear in the SQL standard. We have a great deal of such > syntax already, and we add more of it in every release, and a good > deal of it is contributed by you and

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Sun, 2018-01-07 at 09:58 +, Simon Riggs wrote: > > The attached README explains the ALIGN operation step-by-step with > > a TEMPORAL LEFT OUTER JOIN example. That is, we start from a query > > input, show how we rewrite it during parser stage, and show how the > > final execution generates

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Sat, 2018-01-06 at 20:29 +, Simon Riggs wrote: > * various PostJoinSetProjection() functions to be called as needed > So the idea is we enable Postgres to allow major new functionality, > as was done for PostGIS so successfully. If we use a post-join approach many intermediate result

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Thu, 2017-11-30 at 12:26 -0500, Robert Haas wrote: > I wonder if we could instead think about R NORMALIZE S ON R.x = S.y > WITH (R.time, S.time) as an ordinary join on R.x = S.y with some > extra processing afterwards. After finding all the join partners for > a row in R, extract all the lower

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Jan 25, 2018 at 10:00 PM, Amit Kapila wrote: >> At this point, my preferred solution is for someone to go implement >> Amit's WaitForParallelWorkersToAttach() idea [1] (Amit himself seems >> like the logical person for the job). >> > > I can implement it and share

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wed, Jan 24, 2018 at 12:44 PM, amul sul wrote: > On Tue, Jan 23, 2018 at 7:01 PM, Amit Kapila wrote: >> On Fri, Jan 12, 2018 at 11:43 AM, amul sul wrote: > [] >> I have asked to change the message "tuple to be updated .."

Re: General purpose hashing func in pgbench

Hello Ildar, Applies, compiles, runs. I still have a few very minor comments, sorry for this (hopefully) last iteration from my part. I'm kind of iterative... The XML documentation source should avoid a paragraph on one very long line, but rather be indented like other sections. I'd

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Jan 26, 2018 at 11:30 AM, Amit Kapila wrote: > On Thu, Jan 25, 2018 at 1:24 AM, Peter Geoghegan wrote: >> On Tue, Jan 23, 2018 at 9:43 PM, Amit Kapila wrote: >>> Right, but what if the worker dies due to something

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Jan 25, 2018 at 1:24 AM, Peter Geoghegan wrote: > On Tue, Jan 23, 2018 at 9:43 PM, Amit Kapila wrote: >> Right, but what if the worker dies due to something proc_exit(1) or >> something like that before calling BarrierArriveAndWait. I think this >>

Re: Redefining inet_net_ntop

Craig Ringer writes: > Should we be using our own if the OS has it? I'm thinking of adding a test > to configure and omitting our own version if configure finds it. Objections? I can't imagine that there's any real upside here. The amount of code involved is barely over a

RE: Temporary tables prevent autovacuum, leading to XID wraparound

From: Robert Haas [mailto:robertmh...@gmail.com] > I think we should consider having backends try to remove their temporary > schema on startup; then, if a temp table in a backend is old enough that > it's due for vacuum for wraparound, have autovacuum kill the connection. > The former is

RE: Temporary tables prevent autovacuum, leading to XID wraparound

From: Masahiko Sawada [mailto:sawada.m...@gmail.com] > On Thu, Jan 25, 2018 at 3:14 PM, Tsunakawa, Takayuki > wrote: > > * Why does autovacuum launcher always choose only one database when that > database need vacuuming for XID wraparound? Shouldn't it also choose

Re: Redefining inet_net_ntop

On 1/25/18 22:24, Craig Ringer wrote: > port.h declares inet_net_ntop and we always compile our own > from port/inet_net_ntop.c . > > But it's part of -lresolv on Linux, and more importantly, it's declared > in . > > Should we be using our own if the OS has it? I'm thinking of adding a > test to

Re: WIP: Covering + unique indexes.

On Fri, Jan 26, 2018 at 3:01 AM, Anastasia Lubennikova wrote: > Thanks for the reminder. Rebased patches are attached. This is a really cool and also difficult feature. Thanks for working on it! Here are a couple of quick comments on the documentation, since I

Re: [HACKERS] generated columns

On 1/19/18 00:18, Michael Paquier wrote: > Instead of leaving bits for a feature that may or may not be > implemented, have you considered just blocking STORED at parsing level > and remove those bits? There is little point in keeping the equivalent > of dead code in the tree. So I would suggest a

Redefining inet_net_ntop

Hi folks port.h declares inet_net_ntop and we always compile our own from port/inet_net_ntop.c . But it's part of -lresolv on Linux, and more importantly, it's declared in . Should we be using our own if the OS has it? I'm thinking of adding a test to configure and omitting our own version if

Re: [HACKERS] GnuTLS support

On 1/25/18 20:10, Michael Paquier wrote: > Peter, could you change ssl_version() and ssl_cipher() in sslinfo at the > same time please? I think that those should use the generic backend-side > APIs as well. sslinfo depends heavily on OpenSSL, OK, but if possible > getting this code more generic

Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

On 1/25/18 09:40, Tom Lane wrote: > Peter Eisentraut writes: >> On 1/23/18 13:39, Robert Haas wrote: >>> I don't understand. AAUI, it is currently the case that if you set >>> the options before the TOAST table exists, they are lost. > >> Well, that's also

Re: [PATCH] Logical decoding of TRUNCATE

On 1/24/18 07:53, Petr Jelinek wrote: > That depends on if we consider this to be part of sequence handling or > truncate statement replication handling. It's true that if we had > sequence replication, the restart would get propagated that way anyway. > OTOH, if we'll want to add option in the

Re: [HACKERS] Subscription code improvements

On 1/24/18 02:33, Masahiko Sawada wrote: > Thank you for notification. Since it seems to me that no one is > interested in this patch, it would be better to close out this patch. > This patch is a refactoring patch but subscription code seems to work > fine so far. If a problem appears around

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Thu, Jan 25, 2018 at 07:38:37AM -0500, Stephen Frost wrote: > Michael, all, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Wed, Jan 24, 2018 at 12:43:51PM -0500, Stephen Frost wrote: >>> * chenhj (chjis...@163.com) wrote: At 2018-01-23 09:56:48, "Stephen Frost"

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Craig, Michael, all, * Craig Ringer (cr...@2ndquadrant.com) wrote: > On 21 December 2017 at 11:31, Michael Paquier > wrote: > > > On Thu, Dec 21, 2017 at 11:46 AM, Alvaro Herrera > > wrote: > > > Michael Paquier wrote: > > >> Well, the idea

Re: \describe*

On 01/26/2018 02:11 AM, Corey Huinker wrote: > Some of the discussions about making psql more user friendly (more tab > completions help, exit, etc) got me thinking about other ways that psql > could be more friendly, and the one that comes to mind is our terse but > cryptic \d* commands. > > I

RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Robert Haas [mailto:robertmh...@gmail.com] > If I understand correctly, those results are all just pg_test_fsync results. > That's not reflective of what will happen when the database is actually > running. When you use open_sync or open_datasync, you force WAL write and > WAL flush to

Re: Boolean partitions syntax

Hi Stephen. On 2018/01/26 10:16, Stephen Frost wrote: > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > Still compiles and passes regression tests, which is good. Thanks for looking at this. >>> I extended your test a bit to check whether partitions over booleans are >>> useful. >>>

Re: Fix a typo in autoprewarm.c

On Fri, Jan 26, 2018 at 10:13 AM, Bruce Momjian wrote: > On Fri, Dec 22, 2017 at 02:30:56PM +0900, Masahiko Sawada wrote: >> Hi, >> >> Attached a patch for fixing a typo in autoprewarm.c. I'm sorry if I'm >> mistaken. >> >> s/withs/with/ > > Patch applied to head, thanks.

RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Or to put it short, the lack of granular syncs in ext3 kills performance > for some workloads. Tomas Vondra's presentation on such matters are a really > cool read by the way: >

Re: [PATCH] Logical decoding of TRUNCATE

On 26/01/18 02:34, Robert Haas wrote: > On Wed, Jan 17, 2018 at 12:07 PM, Petr Jelinek > wrote: >> The patch will cascade truncation on downstream if cascade was specified >> on the upstream, that can potentially be dangerous and we either should >> not do it and

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Thu, Jan 25, 2018 at 8:32 PM, Tsunakawa, Takayuki wrote: > As I showed previously, regular file writes on PCIe flash, *not writes using > PMDK on persistent memory*, was 20% faster with open_datasync than with > fdatasync. If I understand correctly, those

Re: [PATCH] Logical decoding of TRUNCATE

On Wed, Jan 17, 2018 at 12:07 PM, Petr Jelinek wrote: > The patch will cascade truncation on downstream if cascade was specified > on the upstream, that can potentially be dangerous and we either should > not do it and only truncate the tables which were truncated

RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Robert Haas [mailto:robertmh...@gmail.com]> On Thu, Jan 25, 2018 at 7:08 PM, Tsunakawa, Takayuki > wrote: > > No, I'm not saying we should make the persistent memory mode the default. > I'm simply asking whether it's time to make open_datasync the default >

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Thu, Jan 25, 2018 at 09:30:45AM -0500, Robert Haas wrote: > On Wed, Jan 24, 2018 at 10:31 PM, Tsunakawa, Takayuki > wrote: >>> This is just a guess, of course. You didn't mention what the underlying >>> storage for your test was? >> >> Uh, your guess was

Re: Temporary tables prevent autovacuum, leading to XID wraparound

On Thu, Jan 25, 2018 at 1:14 AM, Tsunakawa, Takayuki wrote: > * I think temporary tables should not require vacuuming for XID wraparound. > Furtherover, should updates/deletes to temporary tables be in-place instead > of creating garbage, so that any form of

Re: Documentation of pgcrypto AES key sizes

On Fri, Jan 26, 2018 at 12:33:41PM +1300, Thomas Munro wrote: > I noticed that the documentation for encrypt()/decrypt() says "aes — > AES (Rijndael-128)", but in fact 192 and 256 bit keys are also > supported, whether you build --with-openssl or --without-openssl. > Should that say "AES

Re: Boolean partitions syntax

Greetings Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > On 2017/12/20 6:46, Mark Dilger wrote: > >> On Dec 12, 2017, at 10:32 PM, Amit Langote > >> wrote: > >> Added to CF: https://commitfest.postgresql.org/16/1410/ > > > > This compiles and

Re: list partition constraint shape

Fujita-san, Thanks for the review. On 2018/01/25 21:17, Etsuro Fujita wrote: > Thanks for the updated patch!  Some minor comments: > > +   /* > +    * Construct an ArrayExpr for the non-null partition > +    * values > +    */ > +  

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Thu, Jan 25, 2018 at 7:08 PM, Tsunakawa, Takayuki wrote: > No, I'm not saying we should make the persistent memory mode the default. > I'm simply asking whether it's time to make open_datasync the default > setting. We can write a notice in the release note

Re: Removing WITH clause support in CREATE FUNCTION, for isCachable and isStrict

On Thu, Jan 25, 2018 at 06:30:04PM -0500, Tom Lane wrote: > I poked into the git log and confirmed Michael's statement that > CREATE FUNCTION ... WITH has been documented as deprecated since > 7.3 (commit 94bdc4855 to be exact). Thanks for the confirmation. > I think the original intention was

Re: Fix a typo in autoprewarm.c

On Fri, Dec 22, 2017 at 02:30:56PM +0900, Masahiko Sawada wrote: > Hi, > > Attached a patch for fixing a typo in autoprewarm.c. I'm sorry if I'm > mistaken. > > s/withs/with/ Patch applied to head, thanks. --- > >

Re: [HACKERS] GnuTLS support

On Fri, Jan 26, 2018 at 12:27:16AM +0100, Daniel Gustafsson wrote: >> On 25 Jan 2018, at 15:07, Peter Eisentraut >> wrote: >> >> On 1/19/18 13:43, Peter Eisentraut wrote: >>> Comparing the existing {be,fe}-secure-openssl.c with the proposed >>>

Re: PATCH: psql tab completion for SELECT

On 26 January 2018 at 13:44, Vik Fearing wrote: > On 01/26/2018 01:28 AM, Edmund Horner wrote: >> The patch mentioned attempts to put savepoints around the tab >> completion query where appropriate. > > I am -1 on this idea. May I ask why? It doesn't stop psql

Re: [HACKERS] GnuTLS support

On Fri, Jan 19, 2018 at 01:55:30PM -0500, Robert Haas wrote: > On Wed, Jan 17, 2018 at 10:02 PM, Tom Lane wrote: >> Also, this isn't really a good argument against using uniform names >> for parameters that every implementation is certain to have, like >> ssl_key_file. > >

Re: AS OF queries

On Sat, Dec 23, 2017 at 11:53:19PM +0300, konstantin knizhnik wrote: > > On Dec 23, 2017, at 2:08 AM, Greg Stark wrote: > > > On 20 December 2017 at 12:45, Konstantin Knizhnik > > wrote: > > > >> It seems to me that it will be not so difficult to implement them in >

Re: PATCH: psql tab completion for SELECT

On 01/26/2018 01:28 AM, Edmund Horner wrote: > On 19 January 2018 at 05:37, Vik Fearing wrote: >> On 01/18/2018 01:07 AM, Tom Lane wrote: >>> Edmund Horner writes: On 15 January 2018 at 15:45, Andres Freund wrote: > All

Re: PATCH: psql tab completion for SELECT

On 19 January 2018 at 05:37, Vik Fearing wrote: > On 01/18/2018 01:07 AM, Tom Lane wrote: >> Edmund Horner writes: >>> On 15 January 2018 at 15:45, Andres Freund wrote: All worries like this are supposed to check the server

Re: ALTER TABLE ADD COLUMN fast default

On Thu, Jan 25, 2018 at 6:10 PM, Thomas Munro wrote: > On Wed, Jan 17, 2018 at 2:21 AM, Andrew Dunstan > wrote: >> Yeah, got caught by the bki/pg_attribute changes on Friday. here's an >> updated version. Thanks for looking. > > A

Re: PATCH: psql tab completion for SELECT

On 23 January 2018 at 21:47, Vik Fearing wrote: > Don't forget to include the list :-) > I'm quoting the entirety of the message---which I would normally trim---for > the archives. Thanks for spotting that. Sorry list! > If this were my patch, I'd have one query

RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Robert Haas [mailto:robertmh...@gmail.com] > On Wed, Jan 24, 2018 at 10:31 PM, Tsunakawa, Takayuki > wrote: > > As you said, open_datasync was 20% faster than fdatasync on RHEL7.2, on > a LVM volume with ext4 (mounted with options noatime, nobarrier) on a

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

Alvaro, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > Stephen Frost wrote: > > Alvaro, Tom, > > > > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > > > > Crazy idea: maybe a large fraction of that test could be replaced with > > > comparisons of the "pg_restore -l" output file rather

Documentation of pgcrypto AES key sizes

Hi, I noticed that the documentation for encrypt()/decrypt() says "aes — AES (Rijndael-128)", but in fact 192 and 256 bit keys are also supported, whether you build --with-openssl or --without-openssl. Should that say "AES (Rijndael-128, -192 or -256)" instead? -- Thomas Munro

Re: Removing WITH clause support in CREATE FUNCTION, for isCachable and isStrict

Daniel Gustafsson writes: >> On 15 Jan 2018, at 03:27, Michael Paquier wrote: >> As noticed by Daniel here: >> https://www.postgresql.org/message-id/d5f34c9d-3ab7-4419-af2e-12f67581d...@yesql.se > In that thread I proposed a patch to fix this, but I

Re: [HACKERS] GnuTLS support

> On 25 Jan 2018, at 15:07, Peter Eisentraut > wrote: > > On 1/19/18 13:43, Peter Eisentraut wrote: >> Comparing the existing {be,fe}-secure-openssl.c with the proposed >> {be,fe}-secure-gnutls.c, and with half an eye on the previously proposed >> Apple Secure

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 24 Jan 2018, at 16:45, Alvaro Herrera wrote: > > A quick suggestion from a passer-by -- would you put the new code in > src/backend/storage/ipc/backend_signal.c instead? Sounds like a better > place than utils/misc/; and "signal" is more general in nature than just

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

Hello Doug, This time with the revised patch file: pgbench11-ppoll-v8.patch Patch applies cleanly. Compiles cleanly and runs fine in both ppoll & select cases. I'm okay with having a preferred ppoll implementation because of its improved capability. A few minor additional

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

Alvaro Herrera writes: > Well, the current implementation compares a dozen of pg_dump output text > files, three hundred lines apiece, against a thousand of regexes (give > or take). Whenever there is a mismatch, what you get is "this regexp > failed to match " (or

Re: MCV lists for highly skewed distributions

Dean Rasheed writes: > It occurs to me that maybe a better test to exclude a value from the > MCV list would be to demand that its relative standard error not be > too high. Such a test, in addition to the existing tests, might be > sufficient to solve the opposite

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

Stephen Frost wrote: > Alvaro, Tom, > > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > > Crazy idea: maybe a large fraction of that test could be replaced with > > comparisons of the "pg_restore -l" output file rather than pg_dump's > > text output (i.e. the TOC entry for each object,

Invalid result from hash_page_items function

Hi, While researching hash index, I found that hash_page_items could return an invalid result as follows. postgres(1:1056)=# create table hash_test (c int); CREATE TABLE postgres(1:1056)=# insert into hash_test select generate_series(1,50) % 5; INSERT 0 50 postgres(1:1056)=# create index

Re: After dropping the rule - Not able to insert / server crash (one time ONLY)

Can someone review this thread and determine if this patch is needed? Thanks. --- On Fri, Dec 22, 2017 at 04:58:47PM +0530, Dilip Kumar wrote: > On Mon, Dec 11, 2017 at 4:33 PM, Dilip Kumar wrote: >

Re: reducing isolation tests runtime

Tom Lane wrote: > Alvaro Herrera writes: > > Here's a concrete proposal. Runtime is 45.7 seconds on my laptop. It > > can be further reduced, but not by more than a second or two unless you > > get in the business of modifying other tests. (I only modified > >

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Fri, Jan 26, 2018 at 9:38 AM, Claudio Freire wrote: > I had the tests running in a loop all day long, and I cannot reproduce > that variance. > > Can you share your steps to reproduce it, including configure flags? Here are two build logs where it failed:

Re: reducing isolation tests runtime

Alvaro Herrera writes: > Here's a concrete proposal. Runtime is 45.7 seconds on my laptop. It > can be further reduced, but not by more than a second or two unless you > get in the business of modifying other tests. (I only modified > deadlock-soft-2 because it saves 5

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

Alvaro, Tom, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > Tom Lane wrote: > > > The changes in t/002_pg_dump.pl largely failed to apply, which is > > partially due to the age of the patch but IMO speaks more to the > > unmaintainability of that TAP test. It still didn't run after I'd > >

Re: proposal: alternative psql commands quit and exit

On Mon, Jan 15, 2018 at 11:10:44AM -0500, Robert Haas wrote: > On Mon, Jan 15, 2018 at 10:57 AM, Tom Lane wrote: > > Robert Haas writes: > >> I've discovered one thing about this design that is not so good, which > >> is that if you open a single,

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

Tom Lane wrote: > The changes in t/002_pg_dump.pl largely failed to apply, which is > partially due to the age of the patch but IMO speaks more to the > unmaintainability of that TAP test. It still didn't run after I'd > manually fixed the merge failures, so I gave up in disgust and > did not

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Thu, Jan 25, 2018 at 10:56 AM, Claudio Freire wrote: > On Thu, Jan 25, 2018 at 4:11 AM, Thomas Munro > wrote: >> On Thu, Jan 18, 2018 at 9:17 AM, Claudio Freire >> wrote: >>> Huh. That was simpler than I thought.

Re: reducing isolation tests runtime

Tom Lane wrote: > Alvaro Herrera writes: > > I think we could solve this by putting in the same parallel group only > > slow tests that mostly sleeps, ie. nothing that would monopolize CPU for > > long enough to cause a problem. Concretely: > > test: timeouts

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

Robins Tharakan writes: > Attached is an updated patch (v4) with basic tests for pg_dump / pg_dumpall. I've reviewed and pushed this, after making some changes so that the switch works in pg_restore as well, and minor cosmetic adjustments. The changes in t/002_pg_dump.pl

Re: PATCH: Exclude unlogged tables from base backups

On 1/25/18 12:31 AM, Masahiko Sawada wrote: > On Thu, Jan 25, 2018 at 3:25 AM, David Steele wrote: >>> >>> Here is the first review comments. >>> >>> + unloggedDelim = strrchr(path, '/'); >>> >>> I think it doesn't work fine on windows. How about using >>>

Re: [HACKERS] Proposal: Local indexes for partitioned table

Alvaro Herrera wrote: > I think this is the right fix for this problem. I wonder about > exploring other callers of RelationGetIndexList to see who else could be > confused ... CLUSTER was also affected (and ALTER TABLE .. CLUSTER ON). Patched both and added simple tests. Couldn't detect any

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote: > I don't know when this would be released, August-October range. > but the minimal supported LLVM > version will have a strong influence on the availability of that feature. If > today this JIT compiling was released with only LLVM

Re: Possible performance regression with pg_dump of a large number of relations

Luke, * Luke Cowell (lcow...@gmail.com) wrote: > > On Jan 24, 2018, at 2:56 PM, Stephen Frost wrote: > >>> ERROR: relation "pg_init_privs" does not exist > >>> LINE 139: LEFT JOIN pg_init_privs pip > > > > I certainly hope that works on 9.6, since that's when pg_init_privs

Re: plpgsql function startup-time improvements

Hi 2018-01-25 0:16 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > please, can you rebase all three patches necessary for patching? > > Done. These now need to be applied over > https://www.postgresql.org/message-id/833.1516834...@sss.pgh.pa.us

Re: CONSTANT/NOT NULL/initializer properties for plpgsql record variables

> On 25 Jan 2018, at 16:34, Tom Lane wrote: > Daniel Gustafsson writes: >> One tiny thing: while not introduced in this patch, I wonder if it would be >> worth adding an errhint in the following hunk when applied to arrays, to >> clarify what CONSTANT in an

Re: Possible performance regression with pg_dump of a large number of relations

> On Jan 24, 2018, at 2:56 PM, Stephen Frost wrote: > > Hi there! > > >>> ERROR: relation "pg_init_privs" does not exist >>> LINE 139: LEFT JOIN pg_init_privs pip > > I certainly hope that works on 9.6, since that's when pg_init_privs was > added.. My mistake. That

Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

В письме от 25 января 2018 11:29:34 пользователь Tom Lane написал: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Well, maybe the right answer is to address that. It's clear to me > >> why that would happen if we store these things as reloptions on the > >> toast

Re: [HACKERS] [POC] Faster processing at Gather node

On Tue, Jan 9, 2018 at 7:09 PM, Andres Freund wrote: >> + * mq_sender and mq_bytes_written can only be changed by the sender. >> + * mq_receiver and mq_sender are protected by mq_mutex, although, >> importantly, >> + * they cannot change once set, and thus may be read without

Re: Further cleanup of pg_dump/pg_restore item selection code

"David G. Johnston" writes: > Should pg_restore fail if asked to --create without a database entry in the > TOC? Yeah, I wondered about that too. This patch makes it a non-issue for archives created with v11 or later pg_dump, but there's still a hazard if you're

Re: [PROPOSAL] Shared Ispell dictionaries

Hello, Thank you for your review! Good catches. On Thu, Jan 25, 2018 at 03:26:46PM +0300, Ildus Kurbangaliev wrote: > In 0001 there are few lines where is only indentation has changed. Fixed. > 0002: > - TsearchShmemSize - calculating size using hash_estimate_size seems > redundant since you

Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

Alvaro Herrera writes: > Tom Lane wrote: >> Well, maybe the right answer is to address that. It's clear to me >> why that would happen if we store these things as reloptions on the >> toast table, but can't they be stored on the parent table? > Actually, Nikolay

Re: Doc tweak for huge_pages?

On 1/22/18 01:10, Thomas Munro wrote: > Sorry, right, that was 100% wrong. It would probably be correct to > remove the "not", but let's just remove that bit. New version > attached. Committed that. I reordered some of the existing material because it seemed to have gotten a bit out of order

Re: unique indexes on partitioned tables

Hi Alvaro, On 01/22/2018 05:55 PM, Alvaro Herrera wrote: Alvaro Herrera wrote: Version 4 of this patch, rebased on today's master. Passes make check-world. Maybe add a test case to indexing.sql that highlights that hash indexes doesn't support UNIQUE; although not unique to partitioned

CONSTANT/NOT NULL/initializer properties for plpgsql record variables

On Thursday, January 25, 2018, Tom Lane wrote: > > The documentation currently says > > The CONSTANT option prevents the variable from being assigned to > after initialization, so that its value will remain constant for > the duration of the block. >

Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

Tom Lane wrote: > Peter Eisentraut writes: > > On 1/23/18 13:39, Robert Haas wrote: > >> I don't understand. AAUI, it is currently the case that if you set > >> the options before the TOAST table exists, they are lost. > > > Well, that's also weird. > > Well,

Re: JIT compiling with LLVM v9.0

On 24.01.2018 10:20, Andres Freund wrote: Hi, I've spent the last weeks working on my LLVM compilation patchset. In the course of that I *heavily* revised it. While still a good bit away from committable, it's IMO definitely not a prototype anymore. There's too many small changes, so I'm

Re: [HACKERS] SERIALIZABLE with parallel query

On Wed, Jan 24, 2018 at 7:39 PM, Thomas Munro wrote: > This started crashing some time yesterday with an assertion failure in > the isolation tests after commit 2badb5af landed. Reordering of code > in parallel.c confused patch's fuzz heuristics leading >

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

ISTM that the v7 patch version you sent is identical to v6. -- Fabien.

Re: reducing isolation tests runtime

Alvaro Herrera writes: > Tom Lane wrote: >> Alvaro Herrera writes: >>> On the subject of test total time, we could paralelize isolation tests. >> BTW, one small issue there is that the reason the timeouts test is so >> slow is that we have to

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Claudio Freire wrote: > On Thu, Jan 25, 2018 at 4:11 AM, Thomas Munro > wrote: > > *** 128,134 > > SELECT pg_relation_size('vactst', 'main'); > >pg_relation_size > > -- > > ! 0 > > (1 row) > > > > SELECT count(*)

Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

Peter Eisentraut writes: > On 1/23/18 13:39, Robert Haas wrote: >> I don't understand. AAUI, it is currently the case that if you set >> the options before the TOAST table exists, they are lost. > Well, that's also weird. Well, maybe the right answer is to

Re: reducing isolation tests runtime

Tom Lane wrote: > Alvaro Herrera writes: > > On the subject of test total time, we could paralelize isolation tests. > > Right now "make check" in src/test/isolation takes 1:16 on my machine. > > Test "timeouts" takes full 40s of that, with nothing running in parallel > >

Re: Foreign keys and partitioned tables

On Sun, Dec 31, 2017 at 2:43 PM, Alvaro Herrera wrote: > This patch removes all the ONLY markers from queries in ri_triggers.c. > That makes the queries work for the new use case, but I haven't figured > if it breaks things for other use cases. I suppose not, since

Re: [HACKERS] Add support for tuple routing to foreign partitions

Etsuro, * Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: > (2017/12/18 23:25), Alvaro Herrera wrote: > >InitResultRelInfo becomes unintelligible after this patch -- it was > >straightforward but adding partition_root makes things shaky. Please > >add a proper comment indicating what each

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On Thu, Jan 25, 2018 at 5:13 PM, Shubham Barai wrote: > > > On 25 January 2018 at 18:40, Alexander Korotkov > wrote: > >> On Wed, Jan 10, 2018 at 9:55 PM, Shubham Barai >> wrote: >> >>> The previous patch couldn't

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Wed, Jan 24, 2018 at 10:31 PM, Tsunakawa, Takayuki wrote: >> This is just a guess, of course. You didn't mention what the underlying >> storage for your test was? > > Uh, your guess was correct. My file system was ext3, where fsync() writes > all dirty

  1   2   >