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.
> > > */
> > > - p
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)
>
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 t1.i
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 wants
> "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 doubt
> 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 t
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 actua
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
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
> > i
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 s
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 UPD
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* 23:30:32','
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 01
> 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 consideration.
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!
>
> "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 (irc:Rhod
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
> > in<20180821.110132.261184472.horiguchi.kyot...@lab.ntt.c
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 г.
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 opin
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
> > >
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?
Reaso
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
them?
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
opinions
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 loo
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 bi
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 l
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
>
>
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 ma
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
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 onlin
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
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 th
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
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 t
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 wa
>
> 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 reasona
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
> > every
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 g
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 7.3.1
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 use
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 generate_series
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 ro
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 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 o
>
> 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
r
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 have
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 Korotkov
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 abo
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
T
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 li
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 we
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 of
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 column
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
> * r
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 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 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 sh
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 it'
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 error
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 se
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 sin
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
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 repo
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 an
On Mon, 17 Sep 2018 at 23:21, David Rowley wrote:
> On 15 August 2018 at 11:11, Edmund Horner wrote:
>> So we'd extend that to:
>> - Include in the OR-list "range" subquals of the form (ctid > ? AND
>> ctid < ?) (either side could be optional, and we have to deal with >=
>> and <= and having ct
On Wed, Sep 19, 2018 at 02:40:31PM +0900, Michael Paquier wrote:
> Parameters classified as PGC_BACKEND can be updated by any users, and
> those marked as PGC_SU_BACKEND can only be updated by superusers.
> Replication users are not superusers, which is why PGC_BACKEND is most
> adapted. Your desc
From: Michael Paquier [mailto:mich...@paquier.xyz]
> Parameters classified as PGC_BACKEND can be updated by any users, and those
> marked as PGC_SU_BACKEND can only be updated by superusers.
> Replication users are not superusers, which is why PGC_BACKEND is most
> adapted. Your description should
On Tue, Sep 18, 2018 at 12:15:45PM -0400, Jonathan S. Katz wrote:
> On 9/13/18 12:51 PM, Jonathan S. Katz wrote:
> > 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 op
On 19 September 2018 at 18:04, Edmund Horner wrote:
> I have been generally following this approach (handling more kinds of
> TID comparisons), and have found myself doing things like pairing up >
> with <, estimating how much of a table is covered by some set of >, <,
> or "> AND <" quals, etc.
73 matches
Mail list logo
