From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> At Fri, 14 Sep 2018 18:22:33 +0900, Masahiko Sawada
> wrote in
>
> > On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier
> wrote:
> > > On Thu, Sep 13, 2018 at 01:14:12AM +, Tsunakawa, Takayuki wrote:
> > >> Some customer
> "Prabhat" == Prabhat Sahu writes:
Prabhat> postgres[114552]=# select to_timestamp('15-07-84 23:30:32','dd-mm-
Prabhat> hh24:mi:ss');
Prabhat> to_timestamp
Prabhat> --
Prabhat> 0084-07-15 23:30:32+05:53*:28*
Prabhat> (1 row)
Prabhat> My
> On 18. Sep 2018, at 03:18, Thomas Munro wrote:
>
> On Tue, Sep 18, 2018 at 1:15 AM Chris Travers
> wrote:
>> On Mon, Sep 17, 2018 at 2:59 PM Oleksii Kliukin wrote:
>>> With the patch applied, the posix_fallocate loop terminated right away
>>> (because
>>> of QueryCancelPending flag set
Hi,
Am Montag, den 17.09.2018, 14:09 -0400 schrieb Stephen Frost:
> > 5. There seems to be no consensus on whether the number of skipped pages
> > should be summarized at the end.
>
> I agree with printing the number of skipped pages, that does seem like
> a nice to have. I don’t know that
On Tue, Sep 18, 2018 at 01:06:09PM +0900, Kyotaro HORIGUCHI wrote:
> I was wrong here. It was handled in HandleStartupProcInterrupts
> called from StartupXLOG. So, it should be just removed from the
> set. Sorry for the bogus patch.
Thanks for confirming.
Still, it looks like a waste to abuse on
David Rowley wrote:
> I've attached an updated version of this patch.
Following are the findings from my review.
On the LATERAL references:
This query (proposed upthread by Tom and adjusted by me so it can be executed
on the your test tables)
select distinct t1.id from t1 left join t2 on
On Fri, Sep 14, 2018 at 04:30:37PM +0530, Amit Kapila wrote:
> On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier wrote:
>> So, I have been working on this problem again and I have reviewed the
>> thread, and there have been many things discussed in the last couple of
>> months:
>> 1) We do not
On Tue, Sep 18, 2018 at 8:44 AM Prabhat Sahu
wrote:
>
> I have found below difference in TO_TIMESTAMP results.
>
> postgres[114552]=# select to_timestamp('15-07-1984 23:30:32','dd-mm-
> hh24:mi:ss');
>to_timestamp
> ---
> 1984-07-15 23:30:32+05:30
> (1 row)
>
At Fri, 14 Sep 2018 16:30:37 +0530, Amit Kapila wrote
in
> On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier wrote:
> >
> > On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote:
> > > /*
> > > * Properly accept or ignore signals the postmaster might send us.
> > > */
> > > -
I reviewed 'pgbench-prp-func/pgbench-prp-func-4.patch'. [...] I thinks
this patch is fine.
Thanks!
You may consider turning it "ready" in the CF app, so as to see whether
some committer agrees with you.
--
Fabien.
Tomas Vondra has pointed out to me that there's an issue with triggers
not getting expanded tuples for columns with fast defaults. Here is an
example that shows the issue:
andrew=# create table blurfl (id int);
CREATE TABLE
andrew=# insert into blurfl select x from
Pavel Stehule writes:
> [ xml-xpath-default-ns-7.patch ]
At Andrew's prompting, I took a look over this patch. I don't know much
of anything about XML, so I have no idea as to standards compliance here,
but I do have some comments:
* I'm fairly uncomfortable with the idea that we're going to
On 9/13/18 12:51 PM, Jonathan S. Katz wrote:
> Hi,
>
> We are planning to have another release of PostgreSQL 11, either Beta 4
> or RC1, next week on Thursday, 2018-09-20. The version will be
> determined based on the state of the open items list[1] around the time
> of stamping.
PostgreSQL 11
Tom Lane wrote:
> Well, we have to do something. I have a report from EDB's packagers
> that in 11beta4, "initdb --pwfile" is failing on Windows (ie, one can't
> connect afterwards using the specified password). It seems nearly
> certain to me that the reason is that the file is read with
>
>
Greetings,
* Michael Banck (michael.ba...@credativ.de) wrote:
> please find attached version 2 of the patch.
>
> Am Donnerstag, den 26.07.2018, 13:59 +0200 schrieb Michael Banck:
> > I've now forward-ported this change to pg_verify_checksums, in order to
> > make this application useful for
Hi,
Am Freitag, den 31.08.2018, 14:50 +0200 schrieb Michael Banck:
> my colleague Bernd Helmle recently added progress reporting to our
> pg_checksums application[1]. I have now forward ported this to
> pg_verify_checksums for the September commitfest, please see the
> attached patch.
>
> Here's
On Tue, Sep 18, 2018 at 7:50 PM, Jinhua Luo wrote:
> I was testing PG10.
>
> Sorry, the example is not so proper. I just think even if it's a
> simple example, e.g. join two co-located tables, the planner should
> work out to push down it. Can you confirm the postgresql could detect
> co-located
Laurenz Albe writes:
> Would it be an option to have pgwin32_open default to text mode in
> frontend code and to binary mode in backend code?
Well, the question is why Michael's latest proposed patch doesn't
accomplish that.
regards, tom lane
Tom Lane wrote:
> Laurenz Albe writes:
> > Would it be an option to have pgwin32_open default to text mode in
> > frontend code and to binary mode in backend code?
>
> Well, the question is why Michael's latest proposed patch doesn't
> accomplish that.
I was thinking of something trivial like
On Tue, Sep 18, 2018 at 8:28 PM Jinhua Luo wrote:
>
> https://www.postgresql.org/docs/current/static/postgres-fdw.html#id-1.11.7.43.12
>
> As the doc said, the REPEATABLE READ isolation level is used to get
> snapshot-consistent results.
>
> But is it possible that postgres_fdw could get to know
>
> You may dislike the outcome, but it was not ignored.
I can accept that I don't like the outcome, but I can point to maybe a
dozen people in the last
exchange worried about the CoC being used to further political goals, and
the only response
was "well, the CoC Committee will handle it
Greetings,
* Chris Travers (chris.trav...@gmail.com) wrote:
> I said I would stand aside my objections after the last point I mentioned
> them but I did not feel that my particular objection and concern with
> regard to one specific sentence added got much of a hearing. This being
> said, it is
Hi Fabian-san,
I reviewed 'pgbench-prp-func/pgbench-prp-func-4.patch'.
I could apply it and did the TAP test successfully. I could not find
typo in the documentations and comments.
To make sure, I checked the new routine which contains the
__builtin_popcountll() function on Linux + gcc
On 9/18/18 11:45 AM, Stephen Frost wrote:
> * Michael Banck (michael.ba...@credativ.de) wrote:
>> I have added a retry for this as well now, without a pg_sleep() as well.
>
>> This catches around 80% of the half-reads, but a few slip through. At
>> that point we bail out with exit(1), and the
On Tue, Sep 18, 2018 at 4:35 PM Tomas Vondra
wrote:
> On 09/18/2018 01:47 PM, James Keener wrote:
> > > following a long consultation process
> >
> > It's not a consultation if any dissenting voice is simply ignored.
> > Don't sugar-coat or politicize it like this -- it was rammed down
> >
On Wed, Sep 19, 2018 at 12:48 AM Stephen Frost wrote:
> * Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> > So to be more concrete: pg_depend could have a new column
> > "refobjversion". Whenever indexes are created or rebuilt, we'd
> > capture the current version string in the pg_depend
Greetings,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Wed, Sep 19, 2018 at 12:48 AM Stephen Frost wrote:
> > * Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> > > So to be more concrete: pg_depend could have a new column
> > > "refobjversion". Whenever indexes are created
On Wed, Sep 19, 2018 at 10:09 AM Stephen Frost wrote:
> * Douglas Doole (dougdo...@gmail.com) wrote:
> > > The CHECK constraint doesn't need to directly track that information-
> > > it should have a dependency on the column in the table and that's where
> > > the information would be recorded
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> I didn't follow the first sentence of the above hunk. Is the
> wal_sender_timeout relevant with %q?
Ouch, that's a careless mistake. I copied the paragraph from another parameter
and failed to remove some sentence. Patch revised.
Regards
Hi,
I've been doing some testing today, and it seems heap_sync is somewhat
confused by partitioned tables. I'm doing a COPY into a partitioned
table (lineitem from TPC-H partitioned per month) like this:
-
BEGIN;
CREATE TABLE
>
> The CHECK constraint doesn't need to directly track that information-
> it should have a dependency on the column in the table and that's where
> the information would be recorded about the current collation version.
>
Just to have fun throwing odd cases out, how would something like this be
On Mon, Sep 17, 2018 at 12:42 PM Andrey Borodin wrote:
> > 17 сент. 2018 г., в 2:03, Alexander Korotkov
> > написал(а):
> >
> > Also, it appears to me that it's OK to be a single patch
>
> +1, ISTM that these 6 patches represent atomic unit of work.
Thank you, pushed.
--
Alexander
Greetings,
* Douglas Doole (dougdo...@gmail.com) wrote:
> > The CHECK constraint doesn't need to directly track that information-
> > it should have a dependency on the column in the table and that's where
> > the information would be recorded about the current collation version.
>
> Just to
On Tue, Sep 18, 2018 at 10:45:09AM -0400, Tom Lane wrote:
> In the meantime, we might be well advised to revert this patch in
> v11 and just continue to work on the problem in HEAD. I see now
> that this wasn't something to cram in during late beta ...
I can see that you have reverted the change
Greetings,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Wed, Sep 19, 2018 at 10:09 AM Stephen Frost wrote:
> > * Douglas Doole (dougdo...@gmail.com) wrote:
> > > > The CHECK constraint doesn't need to directly track that information-
> > > > it should have a dependency on the
While reviewing Amit's 0001 patch in [1] I noticed Amit pulled out the
code that inits the ResultRelInfos during InitPlan() but didn't update
the comment which says:
/*
* initialize result relation stuff, and open/lock the result rels.
*
* We must do this before initializing the plan tree, else
On Fri, Sep 7, 2018 at 2:17 AM Jesper Pedersen
wrote:
> > This needs a rebase again.
Done.
> Would it be of benefit to update these call sites
>
> * slru.c
>- SlruPhysicalReadPage
>- SlruPhysicalWritePage
> * xlogutils.c
>- XLogRead
> * pg_receivewal.c
>- FindStreamingStart
> *
On Tue, Jul 24, 2018 at 5:24 PM Thomas Munro
wrote:
> Here's a new version.
Bitrot, rebased.
--
Thomas Munro
http://www.enterprisedb.com
0001-Track-the-next-xid-using-64-bits-v6.patch
Description: Binary data
On Wed, Sep 19, 2018 at 01:14:10PM +1200, David Rowley wrote:
> On 19 September 2018 at 12:21, Tomas Vondra
> wrote:
>> So apparently CopyFrom() invokes heap_sync() on the partitioned
>> relation, which attempts to do mdimmedsync() only on the root. That
>> seems like a bug to me.
And the root
At Sat, 15 Sep 2018 19:26:39 +0900, Masahiko Sawada
wrote in
> >> To fix that maybe we can disable commitTs if
> >> controlFile->track_commit_timestamp == false and the
> >> track_commit_timestamp == true even in crash recovery.
> >
> > Hmm, so keep it off while crash recovery runs, and once
Thank you for finding and fixing this.
At Sat, 15 Sep 2018 18:21:52 -0400, Tom Lane wrote in
<1.1537050...@sss.pgh.pa.us>
> Noah Misch writes:
> > Usually, the first srandom() call happens early in PostmasterMain(). I plan
> > to add one to InitStandaloneProcess(), which substitutes for
On 19 September 2018 at 12:21, Tomas Vondra
wrote:
> So apparently CopyFrom() invokes heap_sync() on the partitioned
> relation, which attempts to do mdimmedsync() only on the root. That
> seems like a bug to me.
>
> Obviously this only applies to wal_level=minimal. There are multiple
> callers
On Wed, Sep 19, 2018 at 12:12:44PM +0900, Kyotaro HORIGUCHI wrote:
> The fix looks good to me. The TAP test works fine.
>
> In the TAP test:
>
>
> The test script lacks a general description about its objective.
That's always welcome. The patch looks sensible to me.
> The following
On Tue, Sep 18, 2018 at 06:04:58PM +0200, Laurenz Albe wrote:
> That wouldn't influence pipes, which was what Michael said was a
> problem for pg_dump.
Yeah, the authentication blows up badly on that.. You can see all the
tests using user and database names with all ASCII range turning red.
> I
On Fri, Sep 14, 2018 at 6:09 PM Kyotaro HORIGUCHI
wrote:
> At Sat, 4 Aug 2018 14:09:18 +1200, Thomas Munro
> wrote in
> > Does anyone know why StandbyReleaseLocks() releases all locks if
> > passed InvalidTransactionId? When would that happen?
>
> AFAICS, it used to be used at shutdown time
I wrote:
> Peter Eisentraut writes:
>> What is the status of this? Is performance on High Sierra still bad?
> I committed the fix at 643c27e36. If Apple have done anything about the
> underlying problem, you couldn't tell it from their non-response to my
> bug report.
So, after just about one
On Tue, Sep 18, 2018 at 04:15:42PM +0900, Kyotaro HORIGUCHI wrote:
> My latest patch tries to remove the window by imposing all
> responsibility to apply config file changes to the shared FPW
> flag on the checkpointer. RecoveryInProgress() is changed to be
> called prior to UpdateFullPageWrites
On Wed, Sep 19, 2018 at 12:14:57AM +, Tsunakawa, Takayuki wrote:
> From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> > I didn't follow the first sentence of the above hunk. Is the
> > wal_sender_timeout relevant with %q?
>
> Ouch, that's a careless mistake. I copied the paragraph from
On 19/09/2018 16:38, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
What is the status of this? Is performance on High Sierra still bad?
I committed the fix at 643c27e36. If Apple have done anything about the
underlying problem, you couldn't tell it from their non-response to my
bug
> "Jinhua" == Jinhua Luo writes:
Jinhua> Normally, EXPLAIN do not include the commands by stored
Jinhua> procedures, e.g. aggregated function, trigger, correct?
Jinhua> So how to review the plan by those extensions?
auto_explain with its log_nested_statements option
--
Andrew
Hi,
Patch applies and compiles, all included tests and building of the docs
pass.
I am using last version from more than two months ago in production
environment with real data and I didn't find any bugs,
so I'm marking this patch as ready for committer in the commitfest app.
На сб, 28.07.2018 г.
Hello.
At Fri, 14 Sep 2018 22:01:39 +0900, Etsuro Fujita
wrote in <5b9bb133.1060...@lab.ntt.co.jp>
> (2018/08/24 16:58), Kyotaro HORIGUCHI wrote:
> > At Tue, 21 Aug 2018 11:01:32 +0900 (Tokyo Standard Time), Kyotaro
> > HORIGUCHI wrote
> >
Hi.
Am Montag, den 17.09.2018, 20:45 -0400 schrieb Stephen Frost:
> > You're right it's not about the fsync, sorry for the confusion. My point
> > is that using the checkpoint LSN gives us a guarantee that write is no
> > longer in progress, and so we can't see a page torn because of it. And
> >
If the view definition is too complex to be automatic updateable, then
how postgresql defines OLD in INSTEAD OF trigger? It cannot bind any
column on any table directly then, right?
Unless postgresql refresh view as table source before executing
trigger? Then it may filter (WHERE sub-clause of
I was testing PG10.
Sorry, the example is not so proper. I just think even if it's a
simple example, e.g. join two co-located tables, the planner should
work out to push down it. Can you confirm the postgresql could detect
co-located tables on the same foreign server and push down queries on
On 09/18/2018 01:47 PM, James Keener wrote:
> following a long consultation process
It's not a consultation if any dissenting voice is simply ignored.
Don't sugar-coat or politicize it like this -- it was rammed down
everyone's throats. That is core's right, but don't act as everyone's
Hi,
please find attached version 2 of the patch.
Am Donnerstag, den 26.07.2018, 13:59 +0200 schrieb Michael Banck:
> I've now forward-ported this change to pg_verify_checksums, in order to
> make this application useful for online clusters, see attached patch.
>
> I've tested this in a tight
Michael Paquier writes:
> On Tue, Sep 18, 2018 at 09:11:43AM +0900, Michael Paquier wrote:
>> What I think I broke is that CreateFile ignores what _fmode uses, which
>> has caused the breakage, while calling directly open() or fopen() does
>> the work. There are also other things assuming that
The PostgreSQL Core team are pleased to announce that following a long
consultation process, the project’s Code of Conduct (CoC) has now been
finalised and published at https://www.postgresql.org/about/policies/coc/.
Please take time to read and understand the CoC, which is intended to
ensure
That is, if table `foo` and table `bar` are both tables on the same
remote server, then when I do `select * from foo, bar`, can it
delegate the whole query on the remote side, rather than fetching rows
from both servers one by one and do merging on the local side?
For example:
```
foo=> explain
Hi All,
Few more findings on to_timestamp() test with HEAD.
postgres[3493]=# select to_timestamp('15-07-1984 23:30:32',' dd- mm-
hh24: mi: ss');
to_timestamp
---
1984-07-15 23:30:32+05:30
(1 row)
postgres[3493]=# select to_timestamp('15-07-*1984*
Normally, EXPLAIN do not include the commands by stored procedures,
e.g. aggregated function, trigger, correct?
So how to review the plan by those extensions?
On Tue, Sep 18, 2018 at 5:27 PM, Tsunakawa, Takayuki
wrote:
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>> At Fri, 14 Sep 2018 18:22:33 +0900, Masahiko Sawada
>> wrote in
>>
>> > On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier
>> wrote:
>> > > On Thu, Sep 13, 2018 at
> following a long consultation process
It's not a consultation if any dissenting voice is simply ignored. Don't
sugar-coat or politicize it like this -- it was rammed down everyone's throats.
That is core's right, but don't act as everyone's opinions and concerns were
taken into
On Tue, Sep 18, 2018 at 9:25 PM Oleksii Kliukin wrote:
> > On 18. Sep 2018, at 03:18, Thomas Munro
> > wrote:
> > Here is a patch that I propose to commit and back-patch to 9.4. I
> > just wrote a suitable commit message, edited the comments lightly and
> > fixed some whitespace.
>
> Thanks!
>
On Tue, Sep 18, 2018 at 2:08 PM Prabhat Sahu
wrote:
>
> Few more findings on to_timestamp() test with HEAD.
>
> postgres[3493]=# select to_timestamp('15-07-1984 23:30:32',' dd- mm-
> hh24: mi: ss');
>to_timestamp
> ---
> 1984-07-15 23:30:32+05:30
> (1 row)
Jinhua Luo writes:
> That is, if table `foo` and table `bar` are both tables on the same
> remote server, then when I do `select * from foo, bar`, can it
> delegate the whole query on the remote side, rather than fetching rows
> from both servers one by one and do merging on the local side?
On Thu, 13 Sep 2018 17:03:28 +0900
Michael Paquier wrote:
> On Thu, Sep 13, 2018 at 03:47:26PM +0900, Tatsuo Ishii wrote:
> > Anyway, considering it's a static function, chance of breaking
> > backward compatibility is minimum, I think.
> >
> > So +1 to remove the unused argument.
>
> Same
Greetings,
* Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> On Mon, Sep 17, 2018 at 9:02 AM Stephen Frost wrote:
> > * Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> > > On Mon, Sep 17, 2018 at 6:13 AM Douglas Doole wrote:
> > > > On Sun, Sep 16, 2018 at 1:20 AM Thomas Munro
> >
https://www.postgresql.org/docs/current/static/postgres-fdw.html#id-1.11.7.43.12
As the doc said, the REPEATABLE READ isolation level is used to get
snapshot-consistent results.
But is it possible that postgres_fdw could get to know which remote
queries involved by each top outer command in the
70 matches
Mail list logo
