Hello, thank you for the comment.
At Fri, 8 Jul 2016 14:42:20 -0400, Alvaro Herrera
wrote in <20160708184220.GA733807@alvherre.pgsql>
> Kyotaro HORIGUCHI wrote:
>
> > At Fri, 10 Jun 2016 17:39:59 +0900, Michael Paquier
> > wrote in
> >
> > > On Thu, Jun 9, 2016 at 9:55 PM, Kyotaro HORIGUCHI
On Mon, Jul 11, 2016 at 4:40 PM, Kyotaro HORIGUCHI
wrote:
> That's true, but we don't always have a perfectly comprehensive
> test suite, consciously or unconsciously. The sentence was
> inattentive but the "bug" was just the negative comparable to
> "feature" in my mind. My point was the comparis
Hello,
At Thu, 7 Jul 2016 13:59:54 -0400, Robert Haas wrote in
> On Wed, Jul 6, 2016 at 3:29 AM, Kyotaro HORIGUCHI
> wrote:
> > This seems to be a good opportunity to show this patch. The
> > attched patch set does async execution of foreignscan
> > (postgres_fdw) on the Robert's first infrast
--On 11. Juli 2016 13:25:51 +0800 Craig Ringer
wrote:
> Perhaps by uid threshold in login.defs?
systemd's configure.ac has this:
AC_ARG_WITH(system-uid-max,
AS_HELP_STRING([--with-system-uid-max=UID]
[Maximum UID for system users]),
[SYSTEM_UID_MAX="$withval"],
On Thu, Jul 7, 2016 at 8:38 AM, Michael Paquier
wrote:
> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
> wrote:
> > After further analysis, the issue is that we retrieve the starttli from
> > the ControlFile structure, but it was using ThisTimeLineID when writing
> > the backup label.
> >
>
At Mon, 11 Jul 2016 17:10:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160711.171011.133133724.horiguchi.kyot...@lab.ntt.co.jp>
> > Two things:
> >
> > 1. That's not the scenario I'm talking about. I'm concerned about
> > making sure that query plans that don't use asynchronou
On Mon, Jul 11, 2016 at 3:31 PM, Magnus Hagander wrote:
>
>
> On Thu, Jul 7, 2016 at 8:38 AM, Michael Paquier
> wrote:
>>
>> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
>> wrote:
>> > After further analysis, the issue is that we retrieve the starttli from
>> > the ControlFile structure, bu
When you don't specify a start segment to pg_xlogdump, you get:
pg_xlogdump: no start log position given in range mode.
What is "range mode", and is there any other mode for pg_xlogdump? Should
it not just be "no start log position or segment given" or something like
that?
--
Magnus Hagander
On 7/9/16 4:00 PM, Andrew Gierth wrote:
How about
Time: 1234567.666 ms (20m 34.6s)
That's similar to what I had in mind, so I'd be happy with that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
On 11 July 2016 at 19:14, Netanel Katzburg wrote:
> Hi,
>
> You were right, the method you described worked well. Thanks you!
>
> But so far, could not get any noticeable improvement in Number of
> transactions / latency.
>
>
What are you comparing to?
To start with, compare with:
- an unpatch
On 11 July 2016 at 17:49, Bernd Helmle wrote:
>
>
> --On 11. Juli 2016 13:25:51 +0800 Craig Ringer
> wrote:
>
> > Perhaps by uid threshold in login.defs?
>
> systemd's configure.ac has this:
>
> AC_ARG_WITH(system-uid-max,
> AS_HELP_STRING([--with-system-uid-max=UID]
> [M
On Mon, Jul 11, 2016 at 7:01 PM, Magnus Hagander wrote:
> But isn't this also a pre-existing bug in 9.5? Or did we change something
> else that suddenly made it visible?
What has been patched here is a defect caused by pg_start_backup(),
and not pg_basebackup. In the case of the latter, ThisTimel
On Mon, Jul 11, 2016 at 3:05 PM, Michael Paquier
wrote:
> On Mon, Jul 11, 2016 at 7:01 PM, Magnus Hagander
> wrote:
> > But isn't this also a pre-existing bug in 9.5? Or did we change something
> > else that suddenly made it visible?
>
> What has been patched here is a defect caused by pg_start_
Hi,
You were right, the method you described worked well. Thanks you!
But so far, could not get any noticeable improvement in Number of
transactions / latency.
I have tried:
1. At xlog.c, CopyXLogRecordToWAL(int write_len, bool isLogSwitch,
XLogRecData *rdata,
XLogRecPtr StartPos, XLogRecPtr En
Haribabu Kommi writes:
> On Sat, Apr 9, 2016 at 6:36 AM, Tom Lane wrote:
>> More generally, I'm not convinced about the use-case for this patch.
>> What problem is it supposed to help in dealing with, exactly? Not syntax
>> errors in the hba file, evidently, since it doesn't make any attempt to
I looked into the problem reported in bug #14238,
https://www.postgresql.org/message-id/20160708151747.1426.60...@wrigleys.postgresql.org
The submitter was kind enough to give me a copy of the problem data,
and it turns out that the issue is that a few of the boxes contain
NaN coordinates. Armed w
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
> > in November 2002 when we didn't have any logging of checkpointing at
> > all. I propose to remove it: surely anyone who cares about analyzing
> > checkp
On Thu, Jun 23, 2016 at 1:50 AM, Bruce Momjian wrote:
> On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote:
> > However, if this is the expected behavior, the documentation
> at https://
> > www.postgresql.org/docs/current/static/libpq-ssl.html should be
> updated to
> >
Michael Paquier writes:
> On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote:
>> (Of course, if we were to get rid of "Source code", the point
>> would be moot ...)
> I still think that having source code is useful for debugging, so I
> left it out. Note for the committer who will perhaps pick up
On Fri, Jul 8, 2016 at 10:24 PM, Amit Kapila wrote:
> On Thu, Jul 7, 2016 at 12:34 PM, Masahiko Sawada
> wrote:
>> Than you for reviewing!
>>
>> On Thu, Jul 7, 2016 at 7:06 AM, Andres Freund wrote:
>>> On 2016-07-05 23:37:59 +0900, Masahiko Sawada wrote:
diff --git a/src/backend/access/hea
On 2016-07-11 13:36:37 +0200, Magnus Hagander wrote:
> When you don't specify a start segment to pg_xlogdump, you get:
>
> pg_xlogdump: no start log position given in range mode.
>
>
> What is "range mode", and is there any other mode for pg_xlogdump? Should
> it not just be "no start log positi
Hello,
I am Srinivas and have been working inside PostgreSQL (mostly in the
optimizer module and few times in the executor module). I would like to
change PostgreSQL code such that it also returns the cost of the optimizer
chosen plan to the Java program (through JDBC) as part of the result set.
Michael Paquier writes:
> On Sun, Jul 10, 2016 at 11:52 PM, Tom Lane wrote:
>> Yes, please --- I thought it'd all gotten done.
> OK, here are patches for 9.1, 9.2 and 9.3.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Srinivas Karthik V writes:
> Specifically, I have a Java program which calls
> ResultSet rs = statement.executeQuery("explain select * from table");
> I would like to change PostgreSQL such that ResultSet rs should contain a
> field that contains also the cost of the optimizer chosen plan.
Why do
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote:
> >> (Of course, if we were to get rid of "Source code", the point
> >> would be moot ...)
>
> > I still think that having source code is useful for debugging, so I
> > left it
Stephen Frost writes:
> I agree with removing the source code field, though I did like the
> suggestion mentioned elsewhere for having it shown when it's just a C
> symbol but not otherwise. If we can find a way to have the C symbol
> shown when it's a C or internal function, I'm fine with that,
On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote:
>> Or in short, this may be a fine change to make, but I don't like your
>> argument for it.
>
> I don't agree that it's sensible to get rid of. Having just
> log_checkpoints will have the logs filled with checkpoints starting
> because of XLO
On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote:
> On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote:
> >> Or in short, this may be a fine change to make, but I don't like your
> >> argument for it.
> >
> > I don't agree that it's sensible to get rid of. Having just
> > log_checkpoints wil
On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg wrote:
> Hi All,
>
> As part of my masters at TAU, I'm currently conducting some research
> regarding new persistent memory technology.
> I'm using PG for this research and would like to better understand some of
> the performance bottlenecks.
> For
Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
SCHEMA as INTO variable. I estimate this to be minor oversight in
pl/pgsql parsing with respect to the introduction of this statement.
Assuming it's easily fixed, would a patch to fix pl/pgsql parsing be
accepted?
merlin
--
Sen
Merlin Moncure writes:
> Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN
> SCHEMA as INTO variable.
Ugh, that's definitely a bug.
> I estimate this to be minor oversight in
> pl/pgsql parsing with respect to the introduction of this statement.
While we can certainly hack it b
> I think that probably the most reasonable answer is to replace all the
> raw "double" comparisons in this code with float8_cmp_internal() or
> something that's the moral equivalent of that. Does anyone want to
> propose something else?
We can probably get away by changing the comparison on the
Emre Hasegeli writes:
>> I think that probably the most reasonable answer is to replace all the
>> raw "double" comparisons in this code with float8_cmp_internal() or
>> something that's the moral equivalent of that. Does anyone want to
>> propose something else?
> We can probably get away by ch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I agree with removing the source code field, though I did like the
> > suggestion mentioned elsewhere for having it shown when it's just a C
> > symbol but not otherwise. If we can find a way to have the C symbol
> > shown when it
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote:
> > On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote:
> > >> Or in short, this may be a fine change to make, but I don't like your
> > >> argument for it.
> > >
> > > I don't agree that it's sens
On 11 July 2016 at 23:29, Tom Lane wrote:
> Srinivas Karthik V writes:
> > Specifically, I have a Java program which calls
> > ResultSet rs = statement.executeQuery("explain select * from table");
> > I would like to change PostgreSQL such that ResultSet rs should contain a
> > field that contai
On 11 July 2016 at 22:25, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Alvaro Herrera writes:
> > > the checkpoint_warning feature was added by commit
> 2986aa6a668bce3cfb836
> > > in November 2002 when we didn't have any logging of checkpointing at
> > > all. I propose to
btree_gin uses SEQ_MINVALUE as a way to get the smallest int64 value.
This is actually wrong because the smallest int64 value is
SEQ_MINVALUE-1, so this might be slightly broken.
The whole thing was done as a convenience when INT64_IS_BUSTED had to be
considered, but I think we can get rid of that
Cooled down then measured performance again.
I show you the true result briefly for now.
At Mon, 11 Jul 2016 19:07:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160711.190722.145849861.horiguchi.kyot...@lab.ntt.co.jp>
> Anyway I need some time to cool down..
I recalled that I
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > It would certainly be easy enough to do that, as long as you don't mind
> > hard-wiring into psql the knowledge that "internal" and "C" are the
> > languages to show prosrc for. "Source code" would no longer be a very
> > appropria
I forgot to mention.
At Tue, 12 Jul 2016 11:04:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160712.110417.145469826.horiguchi.kyot...@lab.ntt.co.jp>
> Cooled down then measured performance again.
>
> I show you the true result briefly for now.
>
> At Mon, 11 Jul 2016 19:07:22
On Thu, Jun 23, 2016 at 12:20 PM, Michael Paquier
wrote:
> On Wed, Jun 15, 2016 at 4:52 PM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>
> Sorry for the late reply, Horiguchi-san. I have finally been able to
> put some mind power into that.
>
>> This is somewhat artificial but the same situation could
On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
wrote:
> Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>
>> > It would certainly be easy enough to do that, as long as you don't mind
>> > hard-wiring into psql the knowledge that "internal" and "C" are the
>> > languages to show pr
Michael Paquier writes:
> On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> wrote:
>> So prosrc for internal/C and NULL for others? WFM.
> And so we'd remove "Language" at the same time? That does not sound bad to me.
Hm, I wasn't thinking of that step. The main knock on "Source code" is
tha
44 matches
Mail list logo