On Fri, Aug 24, 2018 at 06:41:07PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-24 18:21:48 -0400, Bruce Momjian wrote:
> >> Since no one else was seeing this problem, I started digging, and I have
> >> found it. I narrowed it to down to this line in Makefile.custom
> >> CC=ccach
Andres Freund writes:
> On 2018-08-24 18:21:48 -0400, Bruce Momjian wrote:
>> Since no one else was seeing this problem, I started digging, and I have
>> found it. I narrowed it to down to this line in Makefile.custom
>> CC=ccache gcc
> Yea, that's a bad idea. You should instead pass CC='ccache
On 2018-08-24 18:21:48 -0400, Bruce Momjian wrote:
> On Fri, Aug 24, 2018 at 02:46:07PM -0700, Andres Freund wrote:
> > On 2018-08-24 14:35:18 -0700, Peter Geoghegan wrote:
> > > On Fri, Aug 24, 2018 at 2:15 PM, Andres Freund wrote:
> > > > Do they persist after you do re-configure? If so, could y
On Fri, Aug 24, 2018 at 02:46:07PM -0700, Andres Freund wrote:
> On 2018-08-24 14:35:18 -0700, Peter Geoghegan wrote:
> > On Fri, Aug 24, 2018 at 2:15 PM, Andres Freund wrote:
> > > Do they persist after you do re-configure? If so, could you send your
> > > config.log?
> >
> > I should point out
Alvaro,
I have previously posted ZFS numbers for SmartOS and FreeBSD to this
thread, although not with the exact same benchmark runs that Tomas did.
I think the main purpose of running the benchmarks is to demonstrate that
there is no significant performance regression with wal recycling disabled
I notice that the cfbot thinks that *none* of your pending patches apply
successfully. I tried this one locally and what I get is
Hmmm. :-(
I've reverted to sending MIME conformant "text/x-diff" CRLF attachements,
as "text/plain" did the same and you complained rightfully that
"applicatio
On 2018-08-24 14:35:18 -0700, Peter Geoghegan wrote:
> On Fri, Aug 24, 2018 at 2:15 PM, Andres Freund wrote:
> > Do they persist after you do re-configure? If so, could you send your
> > config.log?
>
> I should point out to Bruce that this is clearly related to commit
> 143290efd0795b61ed2c8358
On Fri, Aug 24, 2018 at 2:15 PM, Andres Freund wrote:
> Do they persist after you do re-configure? If so, could you send your
> config.log?
I should point out to Bruce that this is clearly related to commit
143290efd0795b61ed2c8358fc1767e799140047.
--
Peter Geoghegan
On August 24, 2018 2:13:24 PM PDT, Bruce Momjian wrote:
>I started seeing the following compile failures in head today on
>current
>Debian Jessie using the default gcc version 4.9.2 (Debian
>4.9.2-10+deb8u1):
>
> postgres.c: In function ‘exec_parse_message’:
> postgres.c:1368:3: err
I started seeing the following compile failures in head today on current
Debian Jessie using the default gcc version 4.9.2 (Debian
4.9.2-10+deb8u1):
postgres.c: In function ‘exec_parse_message’:
postgres.c:1368:3: error: ‘for’ loop initial declarations are only
allowed in C99 or C
On Fri, Aug 17, 2018 at 2:07 AM Shinoda, Noriyoshi (PN Japan GCS Delivery) <
noriyoshi.shin...@hpe.com> wrote:
> The attached patch adds a new option work_mem to postgres_fdw contrib
> module.
>
> Previously, it was impossible to change the setting of work_mem for remote
> session with connection
Andres Freund writes:
> The point is not where you can cause trouble by explicitly deleting
> files - that'll always screw up things - but where you encountered this
> in the wild.
Actually, I think the main point is given that we've somehow got into
a situation like that, how do we get out again
Alvaro Herrera writes:
> On 2018-Aug-25, Pavan Deolasee wrote:
>> Now of course, the file is really missing. But the user was quite surprised
>> that they couldn't connect to any database, even though mishap happened to
>> a user table in one of their reporting databases.
> Hmm, that sounds like
On 08/24/2018 02:38 PM, Tom Lane wrote:
Andres Freund writes:
On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
we should consider backpatching support for those down to 9.3.
Hm, I have no strong objections to th
Hi,
On 2018-08-25 00:56:17 +0530, Pavan Deolasee wrote:
> > Oh, and what PG version are we talking about?
> >
>
> I think this is reproducible on all versions I have tested so far,
> including master.
The point is not where you can cause trouble by explicitly deleting
files - that'll always scre
On 2018-Aug-25, Pavan Deolasee wrote:
> The errors were simply about about the missing file. See attached
> reproduction script that I created while studying this complaint. It will
> throw errors such as:
>
> psql: FATAL: could not open file "base/12669/16387": No such file or
> directory
> CON
On Sat, Aug 25, 2018 at 12:16 AM Tom Lane wrote:
> Pavan Deolasee writes:
> > 1. The user soon found out that they can no longer connect to any
> database
> > in the cluster. Not just the one to which the affected table belonged,
> but
> > no other database in the cluster. The affected table is
Fabien COELHO writes:
> Attached is a rebase after 5ca00774.
I notice that the cfbot thinks that *none* of your pending patches apply
successfully. I tried this one locally and what I get is
$ patch -p1 <~/libpq-host-ip-2.patch
(Stripping trailing CRs from patch.)
patching file doc/src/sgml/lib
On 08/24/2018 02:36 PM, Tom Lane wrote:
Andrew Dunstan writes:
I saw Tom's answer, and it will work as far as it goes. But maybe we
should look at doing that in configure instead of putting the onus on
all buildfarm owners? It already knows if it's using a GNU compiler, not
sure how ubiquito
Pavan Deolasee writes:
> 1. The user soon found out that they can no longer connect to any database
> in the cluster. Not just the one to which the affected table belonged, but
> no other database in the cluster. The affected table is a regular user
> table (actually a toast table).
Please define
Andres Freund writes:
> On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
>> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
>> we should consider backpatching support for those down to 9.3.
> Hm, I have no strong objections to that. I don't think it's strictly
> n
Andrew Dunstan writes:
> I saw Tom's answer, and it will work as far as it goes. But maybe we
> should look at doing that in configure instead of putting the onus on
> all buildfarm owners? It already knows if it's using a GNU compiler, not
> sure how ubiquitous the -ansi and -std=c99 flags are
Commit 8ecdefc26 reminded me of something I'd intended to whine about
and forgot. port.h has this in its USE_REPL_SNPRINTF stanza:
/*
*The GCC-specific code below prevents the pg_attribute_printf above from
*being replaced, and this is required because gcc doesn't know anything
*ab
Hello All,
One of our customers reported a situation where one of the many segments
backing a table went missing. They don't know why that happened and we
couldn't determine if this could be a PostgreSQL bug or FS bug or simply an
operator error.
The very first errors seen in the logs were:
WARN
Hi,
On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
> I have installed VS2017 on bowerbird and a test is currently running. It's
> got past the make phase so I assume everything is kosher.
Cool, thanks.
> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
> we should
On 08/24/2018 11:46 AM, Andres Freund wrote:
Hi,
On 2018-08-23 18:44:34 -0700, Andres Freund wrote:
Pushed the first two.
Seems to have worked like expected.
I'll send the presumably affected buildfarm owners an email, asking
them whether they want to update.
Did that.
I have install
On 8/23/18, 9:16 PM, "Michael Paquier" wrote:
> Thanks, I have pushed the new test series, and reused it to check the
> new version of the main patch, which is attached. I have added a commit
> message and I have indented the thing.
Thanks for the new version!
> After pondering about it, I have
On 2018-08-24 12:10:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'd like to change it so it doesn't enforce C89 compliance across the
> > board, but instead enforces the relevant standard. For that I'd need to
> > change CFLAGS per-branch in the buildfarm. Is that possible already? Do
>
On Fri, Aug 24, 2018 at 9:06 PM, Tom Lane wrote:
> Ashutosh Sharma writes:
>> Currently, table_privileges view in information_schema.sql doesn't
>> show privileges on materialized views for currently enabled roles. As
>> per the documentation-[1], it should be showing the all privileges
>> grante
On August 24, 2018 9:16:27 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2018-08-24 11:47:43 -0400, Tom Lane wrote:
>>> Um ... this would be enough to document that we don't think there's
>a
>>> *read* hazard, but Andres was claiming that there's also a *write*
>hazard.
>
>> Right. The
Andres Freund writes:
> On 2018-08-24 11:47:43 -0400, Tom Lane wrote:
>> Um ... this would be enough to document that we don't think there's a
>> *read* hazard, but Andres was claiming that there's also a *write* hazard.
> Right. The relevant standardese, in C11 (C99 very similar), is:
> 6.2.6.1
I feel strongly that eliminating the entire DISTINCT or GROUP BY clause (when
there are no aggs) is an important optimization, especially when the
incremental cost to test for it is so tiny. I'm happy to submit that as a
separate thread.
My goal here was to move the original proposal along and
Andres Freund writes:
> I'd like to change it so it doesn't enforce C89 compliance across the
> board, but instead enforces the relevant standard. For that I'd need to
> change CFLAGS per-branch in the buildfarm. Is that possible already? Do
> I need two different config files?
I just did that on
Hi,
On 2018-08-24 11:47:43 -0400, Tom Lane wrote:
> Um ... this would be enough to document that we don't think there's a
> *read* hazard, but Andres was claiming that there's also a *write* hazard.
> That is, if you store into (say) a bool in the last declared column,
> the compiler will think it
I'm curious about this option:
-r RELFILENODE check only relation with specified relfilenode
but there is no facility to specify a database.
Also, referring to the relfilenode of a mapped relation seems a bit
inaccurate.
Maybe reframing this in terms of the file name of the file you w
On Tue, Aug 21, 2018 at 4:10 PM Alexander Korotkov
wrote:
> After reading [1] and [2] I got that there are at least 3 different
> issues with heap truncation:
> 1) Data corruption on file truncation error (explained in [1]).
> 2) Expensive scanning of the whole shared buffers before file truncatio
On Fri, Aug 24, 2018 at 1:13 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov
> > wrote:
> >> The key point of the patch is to process stopwords the same way as
> >> others at the level of the PostgreSQL internals and give users an
> >> instr
Peter Eisentraut writes:
> On 21/08/2018 17:38, Peter Eisentraut wrote:
>> On 20/08/2018 15:14, Tom Lane wrote:
>>> I agree this is all moot as long as there's no pad bytes. What I'm
>>> trying to figure out is if we need to put in place some provisions
>>> to prevent there from being pad bytes a
Hi,
On 2018-08-23 18:44:34 -0700, Andres Freund wrote:
> Pushed the first two.
Seems to have worked like expected.
> I'll send the presumably affected buildfarm owners an email, asking
> them whether they want to update.
Did that.
Andrew, as expected my buildfarm animal mylodon, which uses co
Hi,
In a recent commit [1] I added a static inline which castoroides
dislikes:
cc -D_STDC_C99= -Xa -g -m64 -xarch=native -xdepend -xO4
-xprefetch=auto,explicit pg_waldump.o compat.o xlogreader.o rmgrdesc.o
brindesc.o clogdesc.o committsdesc.o dbasedesc.o genericdesc.o gindesc.o
gistdesc.o hashd
On 22.08.2018 07:54, Yamaji, Ryo wrote:
On Tuesday, August 7, 2018 at 0:36 AM, Konstantin Knizhnik wrote:
I have registered the patch for next commitfest.
For some reasons it doesn't find the latest autoprepare-10.patch and still
refer to autoprepare-6.patch as the latest attachement.
I am s
Ashutosh Sharma writes:
> Currently, table_privileges view in information_schema.sql doesn't
> show privileges on materialized views for currently enabled roles. As
> per the documentation-[1], it should be showing the all privileges
> granted on tables and views (the documentation doesn't says it
On 21/08/2018 17:38, Peter Eisentraut wrote:
> On 20/08/2018 15:14, Tom Lane wrote:
>> I agree this is all moot as long as there's no pad bytes. What I'm
>> trying to figure out is if we need to put in place some provisions
>> to prevent there from being pad bytes at the end of any catalog struct.
On Thu, Aug 23, 2018 at 9:12 AM Michael Paquier wrote:
> On Tue, Aug 21, 2018 at 05:48:49PM +0100, Alexandra Ryzhevich wrote:
> > Just to check if changes broke something. I haven't find these checks in
> > other regress tests. In other way we get only positive tests. If this
> > is not needed th
On Fri, Aug 24, 2018 at 01:29:32PM +0900, Amit Langote wrote:
> Attached patch fixes that.
Good catch! Committed.
--
Michael
signature.asc
Description: PGP signature
"Iwata, Aya" writes:
> I'm going to propose libpq debug log for analysis of queries on the
> application side.
> I think that it is useful to determine whether the cause is on the
> application side or the server side when a slow query occurs.
Hm, how will you tell that really? And what's the
(2018/08/21 11:01), Kyotaro HORIGUCHI wrote:
At Tue, 14 Aug 2018 20:49:02 +0900, Etsuro Fujita wrote
in<5b72c1ae.8010...@lab.ntt.co.jp>
(2018/08/09 22:04), Etsuro Fujita wrote:
(2018/08/08 17:30), Kyotaro HORIGUCHI wrote:
I spent more time looking at the patch. ISTM that the patch well
su
(2018/08/24 11:47), Michael Paquier wrote:
On Thu, Aug 23, 2018 at 10:00:49PM +0900, Etsuro Fujita wrote:
I tried this today, but doing git behind the corporate firewall doesn't
work. I don't know the clear cause of that, so I'll investigate that
tomorrow.
You may be able to tweak that by usi
Hi All,
Currently, table_privileges view in information_schema.sql doesn't
show privileges on materialized views for currently enabled roles. As
per the documentation-[1], it should be showing the all privileges
granted on tables and views (the documentation doesn't says it has to
be normal view).
Hi All,
The redirect link for applicable_roles view is missing in the
documentation page for enabled_roles view. Attached is the patch that
adds the same. Please refer to the following URL for details.
https://www.postgresql.org/docs/devel/static/infoschema-enabled-roles.html
--
With Regards,
A
Hi,
When working on other patch[1], I found there are almost same
functions, texttoQualifiedNameList() and stringToQualifiedNameList().
The only difference is the argument type, text or char*. I don't know
why these functions are defined seperately, but I think the former
function can be rewritte
On 08/24/2018 05:18 AM, Michael Paquier wrote:
On Thu, Aug 23, 2018 at 02:24:25PM +0300, Maksim Milyutin wrote:
I want to add patch that prints hint to set required owner for the
tablespace directory if this is the cause of the problem (*errno == EPERM*
after calling *chmod*).
Please do not fo
Hi,
I updated the patch to support other has_*_privilege functions with some
refactoring, but tests for theses fixes are not included yet.
But, while running the regression test after this patch is applied, I found
that my patch doesn't pass privilege test. One of different behaviours
is as bell
The attached patch does 1-3 (2 without renaming, though).
Attached is a rebase after 5ca00774.
--
Fabien.diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 5e7931ba90..086172d4f0 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -964,22 +964,28 @@ postgre
Sorry, I sent older version, which is logically same but contains
some whitespace problems. I resend only 0003 by this mail.
At Fri, 24 Aug 2018 16:51:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180824.165131.45788857.horiguchi.kyot...@lab.ntt.co.jp>
> Hello.
>
> At Tue, 21 A
Hello.
At Tue, 21 Aug 2018 11:01:32 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180821.110132.261184472.horiguchi.kyot...@lab.ntt.co.jp>
> > You wrote:
> > >Several places seems to be assuming that fdw_scan_tlist may be
> > >used foreign scan on simple relation but I didn
56 matches
Mail list logo
