On 30 August 2017 at 23:16, Peter Eisentraut
> Here is another attempt to implement generated columns. This is a
> well-known SQL-standard feature, also available for instance in DB2,
> MySQL, Oracle.
> In previous discussions, it has often been
On Sun, Sep 10, 2017 at 12:28 PM, Ashutosh Sharma wrote:
> On Tue, Jun 27, 2017 at 6:36 PM, Michael Paquier
>> On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma
>>> I am still seeing the issue with the
On Tue, Jun 27, 2017 at 6:36 PM, Michael Paquier
> On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma
>> I am still seeing the issue with the attached patch. I had a quick
>> look into the patch. It seems to me like you have
On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote:
> On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
>> On Wed, May 17, 2017 at 5:17 PM, Robert Haas
>> > On Wed, May 17, 2017 at 6:29 AM, Amit Kapila
There is quite a bit of code in src/backend/lib/rbtree.c that is currently
dead according to the code coverage report, but we're hanging onto it
with the thought that somebody might use it later. That's fine as long as
there is a plausible use-case for it ... but I have to wonder what is the
Victor Drobny writes:
> On 2017-09-08 15:23, Thomas Munro wrote:
>> It's trying to call rb->combiner which is null.
> Thank you for pointing on it. Here is a fixed version.
Actually, I think we *do* want the tests to call the combiner
I whacked this
On 08/28/2017 11:23 AM, Antonin Houska wrote:
> Craig Ringer wrote:
>> On 25 August 2017 at 15:12, Antonin Houska wrote:
>> How will this play with syslog? csvlog? etc?
> There's nothing special about csvlog: the LogStream structure has a
On 08/30/2017 03:16 AM, Andres Freund wrote:
> On 2017-08-30 10:14:22 +0900, Michael Paquier wrote:
>> On Wed, Aug 30, 2017 at 10:06 AM, Andres Freund wrote:
>>> On 2017-08-30 09:49:14 +0900, Michael Paquier wrote:
Do you think that we should worry about wal segment
On Thu, Sep 07, 2017 at 10:49:54PM +0200, Dmitry Dolgov wrote:
> On 29 August 2017 at 22:42, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > To make a review little bit easier I've divided the patch into a few
> smaller parts.
> Apparently I forgot about subscripting for the name data
Michael Paquier writes:
> On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane wrote:
>> Yeah, even if we fixed this particular call site, I'm sure the issue
>> would come up again. Certainly we expect hot backups to work with
>> a changing source directory.
Michael Paquier writes:
> On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane wrote:
>> In short, this patch needs a significant rewrite, and more analysis than
>> you've done so far on whether there's actually any benefit to be gained.
>> It might not be
On 8 September 2017 at 18:06, Peter Geoghegan wrote:
> * It's still faster with int4/int8 comparisons on modern hardware, and
> I think that most ordered inputs will be of those types in practice.
This may be a bit "how long is a piece of string" but how do those two
Tomas Vondra wrote:
> That's not what I meant. I've never felt a strong urge to avoid wrapping
> at 80 chars when translating strings - simply translate in the most
> meaningful way, if it gets longer than 80 chars and can't be easily
> shortened, just wrap. If there are 60 or 80
On Sat, Sep 9, 2017 at 2:05 AM, Bossart, Nathan wrote:
> On 9/8/17, 1:27 AM, "Michael Paquier" wrote:
>> Thanks. This looks now correct to me. Except that:
>> + ereport(ERROR,
>> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
On 09/09/2017 01:24 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> The translator has exactly the same context in both cases, and the
>> struggle to wrap it at 80 characters will be pretty much the same too.
> Really? With the old way, you had something under 60
On 07/13/2017 04:36 PM, Adrien Nayrat wrote:
> Hello hackers,
> From: Peter Geoghegan
>> Date: Wed, 5 Jul 2017 15:19:57 -0700
>> Subject: Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit
>> On pgsql-b...@postgresql.org
> On 07/06/2017 12:19 AM,
On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane wrote:
> Michael Paquier writes:
>>> I'm not real sure if the appropriate answer to this is "we need to fix
>>> RecursiveCopy" or "we need to fix the callers to not call RecursiveCopy
>>> until the source
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Summary of patch contents:
This patch extends pgbench expressions syntax while keeping
compatibility with SQL expressions.
It adds support for NULL and BOOLEAN, as well as assorted
On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane wrote:
> This means that the premise of this patch is wrong. Adjusting pd_lower,
> by itself, would accomplish precisely zip for WAL compression, because
> we'd still not be telling the WAL code to compress out the hole.
> To get any
On Fri, Sep 8, 2017 at 3:38 AM, Tomas Vondra
> On 07/21/2017 03:40 PM, Alexander Korotkov wrote:
>> Hi, Alexey!
>> On Fri, Jul 21, 2017 at 3:05 PM, Alexey Chernyshov
>> > wrote:
2017-09-09 1:24 GMT+02:00 Tom Lane :
> Tomas Vondra writes:
> > The translator has exactly the same context in both cases, and the
> > struggle to wrap it at 80 characters will be pretty much the same too.
> Really? With the old way, you
2017-09-08 9:36 GMT+02:00 Jeevan Chalke :
> Hi Pavel,
> On Sat, May 20, 2017 at 11:55 AM, Pavel Stehule
>> 2017-05-19 5:48 GMT+02:00 Pavel Stehule :
>>> 2017-05-19 3:14
Mail list logo