Bonjour Michaël,
The query cancellation added to pgbench is different than the actual
refactoring, and it is a result of the refactoring, so I would rather
split that into two different commits for clarity. The split is easy
enough, so that's fine not to send two different patches.
Yep,
I propose to change the default of ssl_min_protocol_version to TLSv1.2
(from TLSv1, which means 1.0). Older versions would still be supported,
just not by default.
The reason is that TLS 1.0 and 1.1 are either already discouraged or
deprecated or will be by the time PostgreSQL 13 comes out.
On Fri, 29 Nov 2019 15:45:13 +0900
Yugo Nagata wrote:
> The following review on our patch was posted on another thread,
> so I quote here. The tab completion is Hoshiai-san's work, so
> he will handle this issue.
>
> Regards,
> Yugo Nagata.
>
> On Thu, 28 Nov 2019 13:00:05 +0900
> nuko
Hi all,
Since commit d6c55de1, we support %m in the in-core port for printf
and such. And it seems to me that we could do better for the frontend
code by reducing the dependency to strerror().
One advantage of doing a switch, or at least reduce the use of
strerror(), would be to ease the work
Hello nuko-san,
Thank you for your review!
As Michael commentted, we would like to discuss this on the thread
of the patch, so I quote your review in the following post.
https://www.postgresql.org/message-id/20191129154513.943f4ef05896d7b9d3fed69f%40sraoss.co.jp
Regards,
Yugo Nagata
On Thu,
The following review on our patch was posted on another thread,
so I quote here. The tab completion is Hoshiai-san's work, so
he will handle this issue.
Regards,
Yugo Nagata.
On Thu, 28 Nov 2019 13:00:05 +0900
nuko yokohama wrote:
> Hi.
>
> I'm using the "Incremental Materialized View
Hello,
Thanks a lot for working on this. It's a great (and big!) feature and
I can see that a lot of work has been put into writing this patch. I
started looking at the patch (v8), but as it's quite big:
34 files changed, 5444 insertions(+), 69 deletions(-)
I'm having a bit of trouble
On Thu, Nov 28, 2019 at 08:53:56AM +0530, Amit Kapila wrote:
> I have pushed the refactoring patch. In the second patch, I have a
> few more comments. I am not completely sure if it is a good idea to
> write a new test file 060_dropdb_force.pl when we already have an
> existing file
On Fri, Nov 29, 2019 at 03:19:49PM +0900, Michael Paquier wrote:
> On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote:
>> I'd really like to have the queryid function available through SQL,
>> but I think that this specific case wouldn't work very well for
>> pg_stat_statements'
On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote:
> I'd really like to have the queryid function available through SQL,
> but I think that this specific case wouldn't work very well for
> pg_stat_statements' approach as it's working with oid. The query
> string in pg_stat_activity
On Mon, Aug 19, 2019 at 01:15:19AM +0300, Alexander Korotkov wrote:
> The revised patch seems to fix all of above.
The latest patch is failing to apply. Please provide a rebase.
--
Michael
signature.asc
Description: PGP signature
On Sun, Sep 29, 2019 at 01:00:49AM +0200, Tomas Vondra wrote:
> OK. I'll try extending the set of synthetic queries in [1] to also do
> soemthing like this and generate similar plans.
Any progress on that?
Please note that the latest patch does not apply anymore, so a rebase
is needed. I am
On Thu, Aug 15, 2019 at 06:30:13PM +, Ibrar Ahmed wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:not
This patch is a rather hacky implementation of the basic idea for
implementing FETCH ... WITH TIES, and potentially also PERCENT, by using
a window function expression to compute a stopping point.
Large chunks of this (the parser/ruleutils changes, docs, tests) are
taken from Surafel Temesgen's
Hi, Michael-san.
Sorry, I have missed your e-mail...
> From: Michael Paquier
> On Wed, Jun 26, 2019 at 11:56:28AM +, nagaura.ryo...@fujitsu.com wrote:
> > It seems that you did not think so at that time.
> > # Please refer to [1]
> >
> > I don't think all the reviewers are completely
> "Alvaro" == Alvaro Herrera writes:
Alvaro> First, I noticed that there's a significant unanswered issue
Alvaro> from Andrew Gierth about this using a completely different
Alvaro> mechanism, namely an implicit window function. Robert was
Alvaro> concerned about the performance of
> 29 нояб. 2019 г., в 3:43, Tomas Vondra
> написал(а):
>
> OK, pushed, with some minor cosmetic tweaks on the comments (essentially
> using the formatting trick pointed out by Alvaro), and removing one
> unnecessary change in pglz_maximum_compressed_size.
Cool, thanks!
>
>> But if we introduce IMV, IVM would be used in much less places in the
>> doc and source code, so less confusion would happen, I guess.
>
> Make senses. However, we came to think that "Incrementally Maintainable
> Materialized Views" (IMMs) would be good. So, how about using this for now?
>
On Fri, 29 Nov 2019 07:19:44 +0900 (JST)
Tatsuo Ishii wrote:
> >> As promised, I have created the doc (CREATE MATERIALIZED VIEW manual)
> >> patch.
> >
> > - because the triggers will be invoked.
> > + because the triggers will be invoked. We call this form of
> > materialized
> > +
On Fri, Nov 22, 2019 at 10:08 PM Etsuro Fujita wrote:
> Done. I modified compare_range_partitions() as well to match its the
> variable names with others. Attached is a new version of the patch.
>
> I reviewed the rest of the partbounds.c changes. Here are my review comments:
>
> * I don't
On Fri, Nov 29, 2019 at 12:08 PM Richard Guo wrote:
> On Fri, Nov 29, 2019 at 11:03 AM Michael Paquier wrote:
>> On Tue, Nov 26, 2019 at 08:35:33PM +0900, Etsuro Fujita wrote:
>> > I've just started reviewing this patch. One comment I have for now
>> > is: this is categorized into Bug Fixes,
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, failed
Hi Andrew,
I've reviewed your "libpq sslpassword parameter
On Fri, Nov 29, 2019 at 11:03 AM Michael Paquier
wrote:
> On Tue, Nov 26, 2019 at 08:35:33PM +0900, Etsuro Fujita wrote:
> > I've just started reviewing this patch. One comment I have for now
> > is: this is categorized into Bug Fixes, but we have a workaround at
> > least to the regression
On Tue, Nov 26, 2019 at 08:35:33PM +0900, Etsuro Fujita wrote:
> I've just started reviewing this patch. One comment I have for now
> is: this is categorized into Bug Fixes, but we have a workaround at
> least to the regression test case in the patch (ie, just reorder join
> clauses), so this
On Thu, Oct 03, 2019 at 05:54:40PM +0900, Fujii Masao wrote:
> On Thu, Oct 3, 2019 at 1:57 PM Michael Paquier wrote:
> >
> > On Thu, Oct 03, 2019 at 01:49:34PM +0900, Fujii Masao wrote:
> > > But this can cause subsequent recovery to always fail with invalid-pages
> > > error
> > > and the
On Fri, Sep 20, 2019 at 01:05:06PM -0700, Andres Freund wrote:
> I don't think we should have yet another copy of logic determining
> visibility. It has repeatedly proven hard to get right in the past, and
> it'll not get better by having yet another copy. Especially not because
> we've basically
On Mon, Nov 11, 2019 at 03:44:54PM +0100, Nino Floris wrote:
> Alright, as usual life got in the way. I've attached a new version of
> the patch with pgindent changes.
>
> > What do you think about writing patch for ALTER TYPE?
> I'd rather not :$
>
> > 1) Write migration script, which directly
On Wed, Nov 27, 2019 at 12:23:33PM +, Smith, Peter wrote:
> * That is beyond the scope for what I wanted my patch to achieve; my
> * use-cases are C code only.
Well, FWIW, I do have some extensions using __cplusplus and I am
pretty sure that I am not the only one with that. The thing is that
Hi Michael,
On 2019/11/27 13:25, Michael Paquier wrote:
On Wed, Nov 27, 2019 at 12:45:41PM +0900, Tatsuro Yamada wrote:
Fixed.
Patch was waiting on input from author, so I have switched it back to
"Needs review", and moved it to next CF while on it as you are working
on it.
Thanks for your
On Fri, 29 Nov 2019 09:50:49 +0900 (JST)
Tatsuo Ishii wrote:
> > Hi,
> >
> > Attached is the latest patch (v8) to add support for Incremental View
> > Maintenance (IVM). This patch adds OUTER join support in addition
> > to the patch (v7) submitted last week in the following post.
>
> There's
Hi Alvaro!
Hmmm... I understand your opinion but I'd like to get more opinions too. :)
Do you prefer these column names? See below:
Here's my take on it:
pid
datid
datname
relid
phase
sample_blks_total
sample_blks_scanned
ext_stats_total
ext_stats_computed
> Hi,
>
> Attached is the latest patch (v8) to add support for Incremental View
> Maintenance (IVM). This patch adds OUTER join support in addition
> to the patch (v7) submitted last week in the following post.
There's a compiler warning:
matview.c: In function ‘getRteListCell’:
On Fri, Nov 29, 2019 at 11:14 AM Justin Pryzby wrote:
> On Fri, Nov 29, 2019 at 10:50:36AM +1300, Thomas Munro wrote:
> > On Fri, Nov 29, 2019 at 3:13 AM Thomas Munro wrote:
> > > On Wed, Nov 27, 2019 at 7:53 PM Justin Pryzby
> > > wrote:
> > > > 2019-11-26 23:41:50.009-05 | could not fsync
On Wed, Nov 27, 2019 at 11:27:49PM +0500, Andrey Borodin wrote:
27 нояб. 2019 г., в 20:28, Tomas Vondra
написал(а):
6) I'm pretty sure the comment in the 'while (off < len)' branch will be
badly mangled by pgindent.
I think I can just write it without line limit and then run pgindent.
On Thu, Nov 28, 2019 at 09:35:08PM +0900, Kyotaro Horiguchi wrote:
> I measured the performance with the latest patch set.
>
> > 1. Determine $DDL_COUNT, a number of DDL transactions that take about one
> >minute when done via syncs.
> > 2. Start "pgbench -rP1 --progress-timestamp -T180 -c10
>> As promised, I have created the doc (CREATE MATERIALIZED VIEW manual)
>> patch.
>
> - because the triggers will be invoked.
> + because the triggers will be invoked. We call this form of materialized
> + view as "Incremantal materialized View Maintenance" (IVM).
>
> This part
On Fri, Nov 29, 2019 at 10:50:36AM +1300, Thomas Munro wrote:
> On Fri, Nov 29, 2019 at 3:13 AM Thomas Munro wrote:
> > On Wed, Nov 27, 2019 at 7:53 PM Justin Pryzby wrote:
> > > 2019-11-26 23:41:50.009-05 | could not fsync file
> > > "pg_tblspc/16401/PG_12_201909212/16460/973123799.10": No
On Fri, Nov 29, 2019 at 3:13 AM Thomas Munro wrote:
> On Wed, Nov 27, 2019 at 7:53 PM Justin Pryzby wrote:
> > 2019-11-26 23:41:50.009-05 | could not fsync file
> > "pg_tblspc/16401/PG_12_201909212/16460/973123799.10": No such file or
> > directory
>
> I managed to reproduce this (see below).
Mark Dilger writes:
> While working on the problem of XID wraparound within the LISTEN/NOTIFY
> system, I tried to increment XIDs by more than one per transaction.
> This leads to a number of test failures, many which look like:
IIRC, the XID-creation logic is designed to initialize the next
28.11.2019 23:25, Thomas Munro пишет:
> On Fri, Nov 29, 2019 at 9:08 AM Alexander Lakhin wrote:
>> So for now it seems dangerous to use predefined collations as their old
>> versions are not preserved by pg_upgrade and the user doesn't know which
>> indexes affected by the actual ICU collation
On Fri, Nov 29, 2019 at 9:08 AM Alexander Lakhin wrote:
> So for now it seems dangerous to use predefined collations as their old
> versions are not preserved by pg_upgrade and the user doesn't know which
> indexes affected by the actual ICU collation changes.
Yeah, we noticed this while working
Hello hackers,
When dealing with an OS upgrade, a some kind of anomaly related to
collations was found.
Suppose, we have Debian 8 with postgresql 12 installed.
Then we create a custom collation:
CREATE COLLATION russian (provider=icu, locale='ru_RU');
and
SELECT oid, collname, collnamespace,
Hackers,
While working on the problem of XID wraparound within the LISTEN/NOTIFY
system, I tried to increment XIDs by more than one per transaction.
This leads to a number of test failures, many which look like:
+ERROR: could not access status of transaction 7485
+DETAIL: Could not read
čt 28. 11. 2019 v 15:51 odesílatel Laurenz Albe
napsal:
> On Wed, 2019-11-27 at 08:47 +0100, Pavel Stehule wrote:
> > The most significant issue was missing correct estimation for coalesce
> function.
> > He had to rewrite coalesce(var, X) = X to "var IS NULL or var = X".
> > Then the result was
On Wed, Nov 27, 2019 at 02:58:04PM -0800, Jeff Davis wrote:
On Wed, 2019-08-28 at 12:52 -0700, Taylor Vesely wrote:
Right now the patch always initializes 32 spill partitions. Have you
given
any thought into how to intelligently pick an optimal number of
partitions yet?
Attached a new patch
Marco wrote:
> One interesting thing is the prepared transaction name generated by
> the coordinator, which follows the form: citus_ id>___ number in session>. The server-wide transaction number is a 64-bit
> counter that is kept in shared memory and starts at 1. That means that
> over 4 billion
Peter Eisentraut writes:
> On 2019-11-27 09:26, Michael Paquier wrote:
>> Peter, are you planning to look at that again? Note: the patch has no
>> reviewers registered.
> Here is an updated patch series.
> After re-reading the discussion again, I have kept the existing name of
> the option.
On 28.11.2019 12:23, Hubert Zhang wrote:
Hi hackers,
We just want to introduce another POC for vectorized execution engine
https://github.com/zhangh43/vectorize_engine and want to get some
feedback on the idea.
The basic idea is to extend the TupleTableSlot and introduce
Alvaro Herrera writes:
> Here's a silly insomnia-inspired little patch that removes useless
> "return;" lines from some routines.
+1, I always thought that was poor style.
regards, tom lane
On Thu, Nov 28, 2019 at 7:19 PM Jinbao Chen wrote:
> Hi Andy,
>
> I just test the query on 12.1. But pg use big_table as inner.
>
> demo=# explain (costs off) select * from t_small, t_big where a = b;
> QUERY PLAN
>
> Hash Join
>Hash Cond:
On Wed, 2019-11-27 at 08:47 +0100, Pavel Stehule wrote:
> The most significant issue was missing correct estimation for coalesce
> function.
> He had to rewrite coalesce(var, X) = X to "var IS NULL or var = X".
> Then the result was very satisfactory.
>
> postgres=# explain analyze select * from
On 2019-Nov-28, Surafel Temesgen wrote:
> On Thu, Nov 28, 2019 at 12:36 AM Alvaro Herrera
> wrote:
>
> > I think you should add a /* fall-though */ comment after changing state.
> > Like this (this flow seems clearer; also DRY):
> >
> > if (!node->noCount &&
> >
Here's a silly insomnia-inspired little patch that removes useless
"return;" lines from some routines. (I left some alone, because they
seemed to be there more for documentation purposes, such as the ones in
from_char_set_mode and from_char_set_int; also regcomp.c since the
pedigree there is
On 2019-Nov-12, Luis Carril wrote:
> The nitpicks have been addressed. However, it seems that the new file
> containing the test FDW seems missing from the new version of the patch. Did
> you forget to git add the file?
>
> Yes, I forgot, thanks for noticing. New patch attached again.
Luis,
On Wed, Nov 27, 2019 at 7:53 PM Justin Pryzby wrote:
> 2019-11-26 23:41:50.009-05 | could not fsync file
> "pg_tblspc/16401/PG_12_201909212/16460/973123799.10": No such file or
> directory
I managed to reproduce this (see below). I think I know what the
problem is: mdsyncfiletag() uses
One thing pending in this development line is how to catalogue aggregate
functions that can be used in incrementally-maintainable views.
I saw a brief mention somewhere that the devels knew it needed to be
done, but I don't see in the thread that they got around to doing it.
Did you guys have any
On Thu, Nov 28, 2019 at 12:36 AM Alvaro Herrera
wrote:
> Thanks.
>
> (I would suggest renaming the new state LIMIT_WINDOWEND_TIES, because it
> seems to convey what it does a little better.)
>
> I think you should add a /* fall-though */ comment after changing state.
> Like this (this flow seems
On 2019-Nov-28, Tatsuro Yamada wrote:
> Hmmm... I understand your opinion but I'd like to get more opinions too. :)
> Do you prefer these column names? See below:
Here's my take on it:
pid
datid
datname
relid
phase
sample_blks_total
sample_blks_scanned
ext_stats_total
On Wed, 27 Nov 2019 at 12:33, Konstantin Knizhnik
wrote:
> Hi hackers,
>
> I wonder how it is possible to prohibit parallel scan for the external
> storage accessed through tableam?
> For example if I want to implement specialized tableam for fast access
> to temp tables, how can I inform
On Thu, Nov 28, 2019 at 5:50 AM Michael Paquier wrote:
>
> On Wed, Nov 27, 2019 at 04:09:57PM -0500, Robert Haas wrote:
> > Yeah, I like #3 too. If we're going to the trouble to build all of
> > this mechanism, it seems worth it to build the additional machinery to
> > be precise about the
At Wed, 27 Nov 2019 01:11:40 -0300, Alvaro Herrera
wrote in
> On 2019-Nov-27, Kyotaro Horiguchi wrote:
>
> > At Thu, 24 Oct 2019 14:51:01 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> > > Rebased.
> >
> > 0dc8ead463 hit this. Rebased.
>
> Please review the pg_waldump.c hunks in 0001; they
I measured the performance with the latest patch set.
> 1. Determine $DDL_COUNT, a number of DDL transactions that take about one
>minute when done via syncs.
> 2. Start "pgbench -rP1 --progress-timestamp -T180 -c10 -j10".
> 3. Wait 10s.
> 4. Start one DDL backend that runs $DDL_COUNT
At Tue, 26 Nov 2019 21:37:52 +0900 (JST), Kyotaro Horiguchi
Is is not fully checked. I didn't merged and mesured
performance yet,
> but I post the status-quo patch for now.
It was actually inconsistency caused by swap_relation_files.
1. rd_createSubid of relcache for r2 is not turned off.
Hi Andy,
I just test the query on 12.1. But pg use big_table as inner.
demo=# explain (costs off) select * from t_small, t_big where a = b;
QUERY PLAN
Hash Join
Hash Cond: (t_small.a = t_big.b)
-> Seq Scan on t_small
-> Hash
Hi Hackers,
Richard pointed out that he get incorrect results with the patch I
attached, there are bugs somewhere,
I fixed them now and attached the newest version, please refer to [1] for
the fix.
Thanks,
Pengzhou
References:
[1]
On Thu, Nov 28, 2019 at 4:10 PM Mahendra Singh wrote:
>
> On Thu, 28 Nov 2019 at 13:32, Masahiko Sawada
> wrote:
>>
>> On Wed, 27 Nov 2019 at 19:21, Mahendra Singh wrote:
>> >
>> >
>> > Thanks for the re-based patches.
>> >
>> > On the top of v35 patch, I can see one compilation warning.
>> >>
Hi Amit-san,
On 2019/11/28 10:59, Amit Langote wrote:
Yamada-san,
Thank you for updating the patch.
On Wed, Nov 27, 2019 at 12:46 PM Tatsuro Yamada
wrote:
But I just remembered I replaced column name "*_table" with "*_relid"
based on Robert's comment three months ago, see below:
/me
On Thu, 28 Nov 2019 at 13:32, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Wed, 27 Nov 2019 at 19:21, Mahendra Singh wrote:
> >
> >
> > Thanks for the re-based patches.
> >
> > On the top of v35 patch, I can see one compilation warning.
> >>
> >> parallel.c: In function
On Fri, Nov 22, 2019 at 6:51 PM Jinbao Chen wrote:
> Hi hackers,
>
> I have made a patch to fix the problem.
>
> Added the selection rate of the inner table non-empty bucket
>
> The planner will use big table as inner table in hash join
> if small table have fewer unique values. But this plan is
Hi,
On 28.11.2019 10:36, guangnan he wrote:
Hi,
you mean if we don't add new compiler options the compiler will do the
loop unrolling using SIMD automatically?
Yes, most of modern compiler are doing it.
GCC requires -O3 option (-O2 is not enough), but clang is using them
even with -O2.
Hi hackers,
We just want to introduce another POC for vectorized execution engine
https://github.com/zhangh43/vectorize_engine and want to get some feedback
on the idea.
The basic idea is to extend the TupleTableSlot and introduce
VectorTupleTableSlot, which is an array of datums organized by
Hi Marco,
On Thu, Nov 28, 2019 at 5:02 PM Marco Slot wrote:
>
> On Thu, Nov 28, 2019 at 6:18 AM Amit Langote wrote:
> > Interesting. Still, I think you'd be in better position than anyone
> > else to come up with reproduction steps for vanilla PostgreSQL by
> > analyzing the stack trace if and
> On 28 Nov 2019, at 02:26, Bruce Momjian wrote:
> I have applied the patch, with improved wording. I only applied this to
> PG 13 since I was worried old tools might be checking for the old error
> text. Should this be backpatched more?
I don't think it's unreasonable to assume that there
On Thu, 28 Nov 2019 11:26:40 +0900 (JST)
Tatsuo Ishii wrote:
> > Note that this is the last patch in the series of IVM patches: now we
> > would like focus on blushing up the patches, rather than adding new
> > SQL support to IVM, so that the patch is merged into PostgreSQL 13
> > (hopefully).
On Thu, Nov 28, 2019 at 6:18 AM Amit Langote wrote:
> Interesting. Still, I think you'd be in better position than anyone
> else to come up with reproduction steps for vanilla PostgreSQL by
> analyzing the stack trace if and when the crash next occurs (or using
> the existing core dump). It's
On Wed, 27 Nov 2019 at 19:21, Mahendra Singh wrote:
>
>
> Thanks for the re-based patches.
>
> On the top of v35 patch, I can see one compilation warning.
>>
>> parallel.c: In function ‘LaunchParallelWorkers’:
>> parallel.c:502:2: warning: ISO C90 forbids mixed declarations and code
>>
76 matches
Mail list logo
