Re: Guidelines on dropping objects in regression tests, sqlsmith

On Sat, Apr 14, 2018 at 8:02 PM, Tom Lane wrote: > So we've got *some*, but it sure looks like they were all added by the > patch to fix covering indexes for partitions. I'd want to see some for > plain-table cases as well. Will do. -- Peter Geoghegan

Re: Guidelines on dropping objects in regression tests, sqlsmith

Peter Geoghegan writes: > I took a look through all of the SQL files that the INCLUDE covering > indexes patch added tests to. At no point do they leave behind any > INCLUDE indexes. I'll do something about that as part of the INCLUDE > patch that I'm working on at the moment. A

Re: partitioning code reorganization

On Sun, Apr 15, 2018 at 11:57 AM, Amit Langote wrote: > On Sun, Apr 15, 2018 at 9:17 AM, Alvaro Herrera > wrote: >> Thanks! I pushed this now, putting back the enum in parsenodes and >> including this delta patch of yours. > > Thank you. Do

Re: partitioning code reorganization

On Sun, Apr 15, 2018 at 9:17 AM, Alvaro Herrera wrote: > Thanks! I pushed this now, putting back the enum in parsenodes and > including this delta patch of yours. Thank you. Do you think the following CF entry is good to be closed? Regards, Amit

Re: Guidelines on dropping objects in regression tests, sqlsmith

On Sat, Apr 14, 2018 at 6:18 PM, Tom Lane wrote: > Traditionally, we've left around instances of various sorts of objects > so that pg_dump/pg_upgrade would be exercised on those objects. It's > possible that sqlsmith has different needs in this area, but hard to > say

Re: Guidelines on dropping objects in regression tests, sqlsmith

Peter Geoghegan wrote: > Commit 975ad4e6 fixed a nasty bug in BRIN that was > originally found by Andreas' fuzz testing. Perhaps that bug would > still be around if Alvaro had included any DROP statements within > brin.sql. Presumably his choice to not to do so was completely > arbitrary.

Re: Guidelines on dropping objects in regression tests, sqlsmith

Peter Geoghegan writes: > Andreas Seltenreich's sqlsmith tool has found an impressive number of > bugs. Indeed. > In light of that, it seems to me that it would be reasonable for > a contributor to write a regression test that avoids dropping database > objects specifically so

Guidelines on dropping objects in regression tests, sqlsmith

Andreas Seltenreich's sqlsmith tool has found an impressive number of bugs. In light of that, it seems to me that it would be reasonable for a contributor to write a regression test that avoids dropping database objects specifically so that sqlsmith had some chance of finding bugs after the fact,

Re: partitioning code reorganization

Amit Langote wrote: > On Sat, Apr 14, 2018 at 11:48 PM, Amit Langote > wrote: > > Hi. > > > > Thanks for taking care of few things I left like those PartitionKey > > accessors in rel.h. > > Forgot to mention -- there are some files that still include >

Re: Proposal: Adding json logging

I would suggest that the community consider whether postgres will log multidimensional data. That will weigh into the decision of json vs. another format quite significantly. I am a fan of the json5 spec (https://json5.org/), though adoption of this is quite poor. --- Jordan Deitch

Re: Proposal: Adding json logging

On Sat, Apr 14, 2018, 4:33 PM Andres Freund wrote: > On 2018-04-15 00:31:14 +0200, David Fetter wrote: > > On Sat, Apr 14, 2018 at 01:20:16PM -0700, Andres Freund wrote: > > > On 2018-04-14 18:05:18 +0200, David Fetter wrote: > > > > CSV is very poorly specified, which makes

Re: Proposal: Adding json logging

On 2018-04-15 00:31:14 +0200, David Fetter wrote: > On Sat, Apr 14, 2018 at 01:20:16PM -0700, Andres Freund wrote: > > On 2018-04-14 18:05:18 +0200, David Fetter wrote: > > > CSV is very poorly specified, which makes it at best complicated to > > > build correct parsing libraries. JSON, whatever

Re: Proposal: Adding json logging

On Sat, Apr 14, 2018 at 01:20:16PM -0700, Andres Freund wrote: > On 2018-04-14 18:05:18 +0200, David Fetter wrote: > > On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote: > > > David Fetter writes: > > > > I think a suite of json_to_* utilities would be a good bit more > >

Re: Setting rpath on llvmjit.so?

On 2018-04-14 17:10:21 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: > >> The project policy is to use exactly the GNU distribution of autoconf. > > > Fwiw, I see one copyright year related diff with

Re: Setting rpath on llvmjit.so?

Andres Freund writes: > On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: >> The project policy is to use exactly the GNU distribution of autoconf. > Fwiw, I see one copyright year related diff with unmodified upstream autoconf. Really? Where did you

Re: Proposal: Adding json logging

Andres Freund writes: > On 2018-04-14 18:05:18 +0200, David Fetter wrote: >> CSV is very poorly specified, which makes it at best complicated to >> build correct parsing libraries. JSON, whatever gripes I have about >> the format[1] is extremely well specified, and hence has

Re: Setting rpath on llvmjit.so?

On April 14, 2018 1:56:08 PM PDT, Tom Lane wrote: >Andres Freund writes: >> On 2018-04-14 12:32:35 -0700, Jeff Davis wrote: >>> PS: I also noticed that a autoconf run on master generates some >diffs >>> in configure. > >> I only see one copyright year

Re: Setting rpath on llvmjit.so?

Andres Freund writes: > On 2018-04-14 12:32:35 -0700, Jeff Davis wrote: >> PS: I also noticed that a autoconf run on master generates some diffs >> in configure. > I only see one copyright year related diff. Perhaps you're using a > patched distribution autoconf? The project

Re: Proposal: Adding json logging

On 2018-04-14 18:05:18 +0200, David Fetter wrote: > On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote: > > David Fetter writes: > > > I think a suite of json_to_* utilities would be a good bit more > > > helpful in this regard than changing our human-eye-consumable > > >

Re: Setting rpath on llvmjit.so?

Hi, On 2018-04-14 12:32:35 -0700, Jeff Davis wrote: > Currently, we don't set rpath for llvmjit.so to include `llvm-config -- > libdir`. That means you need to keep LD_LIBRARY_PATH set properly to > use any non-system installation of LLVM. Or pass in the appropriate flags to configure. My

Setting rpath on llvmjit.so?

Currently, we don't set rpath for llvmjit.so to include `llvm-config -- libdir`. That means you need to keep LD_LIBRARY_PATH set properly to use any non-system installation of LLVM. This isn't unique to LLVM (we only set rpath to the postgres $libdir), so I thought it might be project policy. But

Re: Proposal: Adding json logging

Given we have the following LOG_DESTIONATION... Source: https://github.com/postgres/postgres/blob/9d4649ca49416111aee2c84b7e4441a0b7aa2fac/src/include/utils/elog.h#L394-L398 /* Log destination bitmap */ #define LOG_DESTINATION_STDERR 1 #define LOG_DESTINATION_SYSLOG 2 #define

Re: MinIndexTupleSize seems slightly wrong

On Fri, Apr 13, 2018 at 10:45 AM, Tom Lane wrote: > As long as btree only has one no-data tuple per page, I think we are good, > because this calculation does not account for page special space. We might > be underestimating how many tuples can fit by one MAXALIGN quantum,

Re: Proposal: Adding json logging

>As to logfmt in particular, the fact that it's not standardized is probably a show-stopper. >Let's go with JSON. I Agree. Though I don't want to deprecate the idea of logfmt enterly, yet. In container infrastructure it's a defacto standard and it solves a real problem. But I'm in favor to step

Re: Proposal: Adding json logging

On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote: > David Fetter writes: > > I think a suite of json_to_* utilities would be a good bit more > > helpful in this regard than changing our human-eye-consumable > > logs. We already have human-eye-consumable logs by default.

Re: Proposal: Adding json logging

>I'm dubious that JSON is "easier on machines" than CSV. Under common paradigms you are right, but if we talk of line-by-line streaming with subsequent processing, then it's a show stopper. Of course, some log aggregators have buffers for that and can do Multiline parsing on that buffer, but 1.

Re: partitioning code reorganization

On Sat, Apr 14, 2018 at 11:48 PM, Amit Langote wrote: > Hi. > > Thanks for taking care of few things I left like those PartitionKey > accessors in rel.h. Forgot to mention -- there are some files that still include catalog/partition.h but no longer need to. Find a delta

Re: Proposal: Adding json logging

David Fetter writes: > I think a suite of json_to_* utilities would be a good bit more > helpful in this regard than changing our human-eye-consumable logs. We > already have human-eye-consumable logs by default. What we don't > have, and increasingly do want, is a log format

Re: Proposal: Adding json logging

On Sat, Apr 14, 2018 at 03:27:58PM +, David Arnold wrote: > > Plus it's likely only a short-lived interchange format, not something to be > retained for a long period. > > Absolutely. > > There might be an argument that it's not easy on the eyes in the case it > would be consumed by a pair

Re: missing support of named convention for procedures

2018-04-14 15:58 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 3/22/18 10:19, Pavel Stehule wrote: > > attached patch should to fix it > > Committed. > Thank you Pavel > > I had to make a small tweak to make INOUT + DEFAULT parameters work in > PL/pgSQL. > > -- > Peter

Re: partitioning code reorganization

Alvaro Herrera writes: > The one thing I don't like about this is having put > PartitionRangeDatumKind in partdefs.h, which forces us to #include that > file in parsenodes.h. I had to do this in order to avoid #including > parsenodes.h in partbounds.h. Now maybe that is

Re: Proposal: Adding json logging

> Plus it's likely only a short-lived interchange format, not something to be retained for a long period. Absolutely. There might be an argument that it's not easy on the eyes in the case it would be consumed by a pair of them. It's absolutely valid. Golang community has found a solution for

Re: partitioning code reorganization

Hi. Thanks for taking care of few things I left like those PartitionKey accessors in rel.h. On Sat, Apr 14, 2018 at 8:51 PM, Alvaro Herrera wrote: > Here's a final version. > > The one thing I don't like about this is having put > PartitionRangeDatumKind in partdefs.h,

Re: missing support of named convention for procedures

On 3/22/18 10:19, Pavel Stehule wrote: > attached patch should to fix it Committed. I had to make a small tweak to make INOUT + DEFAULT parameters work in PL/pgSQL. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: Proposal: Adding json logging

On 14 April 2018 at 11:24, Michael Paquier wrote: > "I proposed that a couple of years back, to be rejected as the key names > are too much repetitive and take too much place. gzip is astonishingly good at dealing with that, so I think that's actually a bit of a silly

Re: Postgres stucks in deadlock detection

пт, 13 апр. 2018 г., 21:10 Andres Freund : > Hi, > > On 2018-04-13 19:13:07 +0300, Konstantin Knizhnik wrote: > > On 13.04.2018 18:41, Andres Freund wrote: > > > On 2018-04-13 16:43:09 +0300, Konstantin Knizhnik wrote: > > > > Updated patch is attached. > > > > + /* > > > > +