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
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 quick look at the
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 you think the following CF entry is good to be closed
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
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 without more thought.
Clea
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. Actually
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 that sqlsmith had
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, b
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
> catalog/partition.h but no longer need to.
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
https://i
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 it at best complicate
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 gr
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
> > > > helpful in thi
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 unmodified upstream
> > autoconf.
>
> R
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 get autoconf from? My archived copy of
aut
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 excellent
>> parsing l
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 related diff. Perhaps you're using a
>> pat
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 policy is to use exa
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
> > > logs. We already ha
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 configu
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
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 LOG_DESTINATION_EVEN
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, but
> the special space
>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 ba
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. What
> > we don't
>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. No
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 patch
attached that appli
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 that's really easy o
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 of
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 Ei
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 not so bad, since that
>
> 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 that
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, which forces us to #includ
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 & Services
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 reason to block it.
Plus i
пт, 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.
> > > > + /*
> > > > + * Ensure that only o
36 matches
Mail list logo
