2017-09-08 23:09 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > personally I prefer syntax without FOR keyword - because following
> keyword
> > must be reserved keyword
>
> > SET x = .., y = .. SELECT ... ;
>
> Nope. Most of the statement-starting keywords are *not* fully reserved;
> they don
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Summary of patch contents: [...]
1. there are no any problem with compilation, patching
2. all tests passed
3. doc is ok
I'll mark this patch as ready for commiter
Ok. Thanks for the reviews.
--
Fa
On Sun, Sep 10, 2017 at 11:52 AM, Michael Paquier
wrote:
> On Sun, Sep 10, 2017 at 3:15 PM, Amit Kapila wrote:
>> On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane wrote:
>>> Michael Paquier writes:
On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane wrote:
> In short, this patch needs a significant rewr
On Sun, Sep 10, 2017 at 3:15 PM, Amit Kapila wrote:
> On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane wrote:
>> 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 t
On Sat, Sep 9, 2017 at 9:00 PM, Tom Lane wrote:
> 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
On Fri, Sep 8, 2017 at 1:54 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Sep 7, 2017 at 2:40 PM, Amit Langote
>> wrote:
>>> On 2017/09/07 13:09, Michael Paquier wrote:
pd_lower should remain at 0 on pre-10 servers.
>
>>> Doesn't PageInit(), which is where any page gets initializ
Hi
2017-09-09 11:02 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> 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.
>
On 30 August 2017 at 23:16, Peter Eisentraut
wrote:
> 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 a source of confusion whether
> th
On Sun, Sep 10, 2017 at 12:28 PM, Ashutosh Sharma wrote:
> On Tue, Jun 27, 2017 at 6:36 PM, Michael Paquier
> wrote:
>> On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma
>> wrote:
>>> I am still seeing the issue with the attached patch. I had a quick
>>> look into the patch. It seems to me like
On Tue, Jun 27, 2017 at 6:36 PM, Michael Paquier
wrote:
> On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma
> wrote:
>> 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 canonicalized the
>> tablespace path to convert win32 sla
On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote:
> On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
> wrote:
>>
>> On Wed, May 17, 2017 at 5:17 PM, Robert Haas
>> wrote:
>> > On Wed, May 17, 2017 at 6:29 AM, Amit Kapila
>> > wrote:
>> >> I think we can do this even without using an additional infom
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
argum
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
occasionally ...
I whacked this around quite a bit and had g
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
> "destination" field, so if particular extensi
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 sizes higher than
2
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 type,
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.
> In short, I'd still like to keep RecursiveCopy
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 worth messing with.
> I did some measurements of th
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
compare with string sorting
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 character
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),
>> +errmsg("column lists cannot hav
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 characters to
> work in, now it'
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
>> overflow
>> On pgsql-b...@postgresql.org
>
> On 07/06/2017 12:19 AM, Peter Geoghegan wr
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 directory is stable". Thoughts?
>
>> ... So making
Hello Pavel,
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 log
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 benefit, I think we'
On Fri, Sep 8, 2017 at 3:38 AM, Tomas Vondra
wrote:
> Hi,
>
> On 07/21/2017 03:40 PM, Alexander Korotkov wrote:
>> Hi, Alexey!
>>
>> On Fri, Jul 21, 2017 at 3:05 PM, Alexey Chernyshov
>> mailto:a.chernys...@postgrespro.ru>> wrote:
>>
>> the following patch transfers functionality from gevel mo
27 matches
Mail list logo
