I am seeing below warnings (on Win7) in dshash.c
1> dshash.c
1>src/backend/lib/dshash.c(318): warning C4334: '<<' : result of
32-bit shift implicitly converted to 64 bits (was 64-bit shift
intended?)
1>src/backend/lib/dshash.c(679): warning C4334: '<<' : result of
32-bit shift implicitly converte
Hi,
On 2017-08-31 23:41:31 -0700, Andres Freund wrote:
> I previously had an early prototype of JITing [1] expression evaluation
> and tuple deforming. I've since then worked a lot on this.
>
> Here's an initial, not really pretty but functional, submission.
One of the things I'm not really happ
On 2017-09-02 18:31:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't quite see how you'd get corruption from a physical slot being
> > forwarded? I mean you surely can get into the situation that there's
> > missing WAL from wherever a standby is receiving its WAL, but that'll
> > "ju
Andres Freund writes:
> I don't quite see how you'd get corruption from a physical slot being
> forwarded? I mean you surely can get into the situation that there's
> missing WAL from wherever a standby is receiving its WAL, but that'll
> "just" break replication.
Um, doesn't advancing a slot cor
On 2017-09-01 23:37:07 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 8/31/17 08:19, Magnus Hagander wrote:
> >> I think that, in the end, covered all the comments?
>
> > I didn't see any explanation of what this would actually be useful for.
> > I suppose you could skip over some chang
On Sat, Sep 2, 2017 at 2:51 AM, Noah Misch wrote:
> [Action required within three days. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item. Robert,
> since you committed the patch believed to have created it, you own this open
> item. If some o
On Fri, Sep 1, 2017 at 11:30 PM, Peter Eisentraut
wrote:
> On 8/31/17 08:19, Magnus Hagander wrote:
>> Rebased. Now named pg_advance_replication_slot. ERROR on logical slots.
>> Forward only.
>>
>> I think that, in the end, covered all the comments?
>
> I didn't see any explanation of what this wo
> On 01 Sep 2017, at 15:40, Robert Haas wrote:
>
> On Fri, Sep 1, 2017 at 4:26 AM, Alvaro Herrera
> wrote:
>> Erik Rijkers wrote:
>>> Would it be possible to change the commitfest a bit and make it possible to
>>> add the commit (or commit-message, or hash) to the thread in the
>>> commitfest-a
I wrote:
> My thought is that what we need to do is find a way for isTopLevel
> to be false if we're processing a multi-command string.
Nah, that's backwards, the problem is exactly that isTopLevel is
false if we're processing a multi-command string. That allows
DefineSavepoint to think that it's
Hello Fabien,
Thank you for detailed review. I hope I have fixed all the issues you mentioned
in your letter.
pgbench-zipf-08v.patch
Description: Binary data
—
Thanks and Regards,
Alik Khilazhev
Postgres Professional:
http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsq
Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Aug 31, 2017 at 1:52 PM, Andreas Karlsson wrote:
> >> There are currently two failing SSL tests which at least to me seems more
> >> like they test specific OpenSSL behaviors rather than something which need
> >> to be true for all SSL libraries.
Hackers,
The cache in pg_internal.init was reused in days of yore but has been
rebuilt on postmaster startup since v8.1. It appears there is no reason
for this file to be backed up.
I also moved the RELCACHE_INIT_FILENAME constant to relcache.h to avoid
duplicating the string.
I'll add this to
On 09/02/2017 06:44 AM, Thomas Munro wrote:
On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik
wrote:
postgres=# explain select * from bt where k between 1 and 2 and v = 100;
QUERY PLAN
--
On Sat, Sep 2, 2017 at 12:21 PM, Noah Misch wrote:
> On Thu, Aug 31, 2017 at 03:11:10PM -0400, Robert Haas wrote:
>> On Wed, Aug 30, 2017 at 11:19 AM, Robert Haas wrote:
>> > But since that's an established design fl^H^Hprinciple, maybe that
>> > means we should go with the approach of teaching S
On Wed, Aug 30, 2017 at 8:49 PM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 9:58 AM, Tom Lane wrote:
>> The problem here is exactly that we cannot transmit the leader's
>> state to the worker. You can't blame it on SET ROLE, because
>> I didn't do one.
>
> Hmm, that's a good reason for holding
On Fri, Sep 1, 2017 at 7:17 PM, Thomas Munro
wrote:
> On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote:
>> On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote:
>>> On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote:
Thanks, marked as ready for committer, as the code is good and Alexander
On 9/1/17 7:53 PM, Michael Paquier wrote:
> On Sat, Sep 2, 2017 at 3:06 AM, Robert Haas wrote:
>> I don't think this really buys us anything. If we'd applied it to v10
>> maybe, but what do we get out of whacking it around now?
>>
>> "Consistency", I hear you cry! Fair point. But we never had a
2017-09-02 13:28 GMT+02:00 Devrim Gündüz :
>
> Hi,
>
> On Sat, 2017-09-02 at 06:52 +0200, Pavel Stehule wrote:
> > but looks so it is Fedora26 issue - I see these lines elsewhere too.
>
> I cannot reproduce it on my F26 box.
>
I have to do deep research
Thank you for info
Pavel
>
> Regards,
>
Hi,
On Sat, 2017-09-02 at 06:52 +0200, Pavel Stehule wrote:
> but looks so it is Fedora26 issue - I see these lines elsewhere too.
I cannot reproduce it on my F26 box.
Regards,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engine
Jeff Janes wrote:
> On Fri, Sep 1, 2017 at 1:32 PM, Jeff Janes wrote:
>
> The "-r" option to pg_basebackup is supposed to throttle the rate of the
> backup. But it only works properly if the server is mostly idle.
>
> Every non-trivial call to XLogFlush or XLogBackgroundFlush will wake up t
20 matches
Mail list logo