On Tue, Dec 29, 2020 at 02:26:19PM -0600, Paul Martinez wrote:
> The checks for whether the current user can create a user with the SUPERUSER,
> REPLICATION, or BYPASSRLS attributes are chained together using if/else-if,
> before finally checking whether the user has CREATEROLE privileges in a
> fi
On Tue, Dec 29, 2020 at 04:16:06PM -0500, Tom Lane wrote:
> Hmph, no, a look at explain.c shows that the "Execution Time" is just
> based on the difference of INSTR_TIME_SET_CURRENT measurements taken
> within the current process. It's difficult to conclude anything except
> that the clock went ba
On 29.12.2020 16:20, Hou, Zhijie wrote:
see new version in attachment.
I took a look into the patch, and have some comments.
1.
+ PG_FINALLY();
+ {
+ copy_fmstate = NULL; /* Detect problems */
I don't quite understand this comment,
does it means we want to detect some
On Wed, Dec 23, 2020 at 8:43 PM Amit Kapila wrote:
>
> 1.
> + * Rarely, the DropSubscription may be issued when a tablesync still
> + * is in SYNCDONE but not yet in READY state. If this happens then
> + * the drop slot could fail because it is already dropped.
> + * In this case suppress and drop
On Wed, Dec 23, 2020 at 9:07 PM Amit Kapila wrote:
>
> On Tue, Dec 22, 2020 at 4:58 PM Peter Smith wrote:
> >
> > On Mon, Dec 21, 2020 at 11:36 PM Amit Kapila
> > wrote:
> > >
> > > On Mon, Dec 21, 2020 at 3:17 PM Peter Smith wrote:
> > > >
> > > > On Mon, Dec 21, 2020 at 4:23 PM Amit Kapila
Hi,
I'm posting a v4-0001 patch for the new functions
postgres_fdw_get_connections() and postgres_fdw_disconnect(). In this
patch, I tried to address the review comments provided upthread.
At a high level, the changes include:
1) Storing the foreign server id in the cache entry which will help t
Hi Amit.
PSA my v9 WIP patch for the Solution1 which addresses some recent
review comments, and other minor changes.
Features:
* tablesync slot is now permanent instead of temporary. The tablesync
slot name is no longer tied to the Subscription slot na
* the tablesync slot cleanup (drop)
Hi Amit,
In last
mail(https://www.postgresql.org/message-id/66851e198f6b41eda59e6257182564b6%40G08CNEXMBPEKD05.g08.fujitsu.local),
I've sent you the performance test results(run only 1 time) on single table.
Here is my the retested results(average by 15 times) which I think is more
accurate.
I
On Wed, 30 Dec 2020 at 10:47 AM, Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Wed, Dec 30, 2020 at 10:32 AM Dilip Kumar
> wrote:
> > I have completed reviewing 0001, I don't have more comments, just one
> > question. Soon I will review the remaining patches.
>
> Thanks
On Wed, Dec 30, 2020 at 10:32 AM Dilip Kumar wrote:
> I have completed reviewing 0001, I don't have more comments, just one
> question. Soon I will review the remaining patches.
Thanks.
> +/* If parallel inserts are to be allowed, set a few extra information. */
> +if (myState->is_paral
On Mon, Dec 28, 2020 at 10:45 AM Dilip Kumar wrote:
>
> On Sun, Dec 27, 2020 at 2:20 PM Bharath Rupireddy
> wrote:
> >
> > On Sat, Dec 26, 2020 at 11:11 AM Dilip Kumar wrote:
> > > I have reviewed part of v15-0001 patch, I have a few comments, I will
> > > continue to review this.
> >
> > Thanks
On Wed, Dec 30, 2020 at 5:52 PM Thomas Munro wrote:
> and requires it on retry
s/requires/reacquires/
On Wed, Dec 30, 2020 at 4:13 AM 陈佳昕(步真) wrote:
> I found some other problems which I want to share my change with you to make
> you confirm.
> <1> I changed the code in smgr_alloc_sr to avoid dead lock.
>
> LWLockAcquire(mapping_lock, LW_EXCLUSIVE);
> flags = smgr_lock_sr(sr);
> Assert(flag
On Mon, Dec 28, 2020 at 5:24 PM Andy Fan wrote:
> lseek(..., SEEK_END) = 9670656
> write(...) = 8192
> lseek(..., SEEK_END) = 9678848
> fsync(...) = -1
> lseek(..., SEEK_END) = 9670656
>
> I got 2 information from above. a) before the fsync, the lseek(fd, 0,
> SEEK_END)
> returns a correct valu
On Sat, Dec 26, 2020 at 12:06:59PM +0500, Andrey Borodin wrote:
> > 12 дек. 2020 г., в 22:47, Andrey Borodin написал(а):
> I've cleaned up comments, checked that memory alignment stuff actually make
> sense for 32-bit ARM (according to Godbolt) and did some more code cleanup.
> PFA v2 patch.
Hi,
On 2020-11-19 18:01:14 +1300, Thomas Munro wrote:
> From ac3c61926bf947a3288724bd02cf8439ff5c14bc Mon Sep 17 00:00:00 2001
> From: Thomas Munro
> Date: Fri, 13 Nov 2020 14:38:41 +1300
> Subject: [PATCH v2 1/2] WIP: Track relation sizes in shared memory.
>
> Introduce a fixed size pool of SMgr
Hi,
On 2020-12-24 16:06:38 +1300, Thomas Munro wrote:
> From 85187ee6a1dd4c68ba70cfbce002a8fa66c99925 Mon Sep 17 00:00:00 2001
> From: Thomas Munro
> Date: Sat, 28 Mar 2020 11:42:59 +1300
> Subject: [PATCH v15 1/6] Add pg_atomic_unlocked_add_fetch_XXX().
>
> Add a variant of pg_atomic_add_fetch_
On Wed, Dec 30, 2020 at 8:03 AM Hou, Zhijie wrote:
> > Yeah without explain analyze we can not show whether the parallelism is
> > picked in the test cases. What we could do is that we can add a plain RMV
> > test case in write_parallel.sql after CMV so that at least we can be ensured
> > that the
On Tue, Dec 29, 2020 at 05:06:20PM -0500, Tom Lane wrote:
> 629b3af2 just moved around the existing -I switch in adminpack/Makefile.
> AFAICS that switch goes back to adminpack's introduction, fe59e5666.
> It was probably just copied-and-pasted from some other contrib Makefile;
> since this Makefil
Hi,
This started as a reply to
https://postgr.es/m/CAH2-WzkbCvgKrmw%2Bf%2B1hwgXhmiv%2BUNRihotALXftUiNr%3D3VUKA%40mail.gmail.com
but after typing for a while I decided that it's large and unrelated
enough to be better handled as a new thread.
On 2020-11-27 11:08:49 -0800, Peter Geoghegan wrote:
>
> Yeah without explain analyze we can not show whether the parallelism is
> picked in the test cases. What we could do is that we can add a plain RMV
> test case in write_parallel.sql after CMV so that at least we can be ensured
> that the parallelism will be picked because of the enforcement there
Hi,
On 2020-11-27 20:22:41 +0200, Heikki Linnakangas wrote:
> On 26/11/2020 04:50, Tom Lane wrote:
> > Craig Ringer writes:
> > > On Wed, Nov 25, 2020 at 9:23 PM Ashutosh Bapat
> > >
> > > wrote:
> > > > I'd prefer to make the lock self deadlock check run for production
> > > > builds, not just
Hi,
Great to see work in this area!
On 2020-12-28 09:44:26 +0100, Luc Vlaming wrote:
> I would like to propose a small patch to the JIT machinery which makes the
> IR code generation lazy. The reason for postponing the generation of the IR
> code is that with partitions we get an explosion in the
w.r.t. v17-0004-Enable-CTAS-Parallel-Inserts-For-Append.patch
+ * Push the dest receiver to Gather node when it is either at the top of
the
+ * plan or under top Append node unless it does not have any projections
to do.
I think the 'unless' should be 'if'. As can be seen from the body of the
met
On Fri, Dec 25, 2020 at 03:41:46PM +0900, Michael Paquier wrote:
> On Wed, Dec 09, 2020 at 02:13:29PM -0600, Justin Pryzby wrote:
> > I thought this was a good idea, but didn't hear back when I raised it
> > before.
> >
> > Failing to preserve access method is arguably a bug, reminiscent of CREAT
I wrote:
> I had a thought while looking at elog.c: we could further reduce the risk
> of quickdie() crashing if we make it do what elog.c does when it gets into
> error recursion trouble:
> error_context_stack = NULL;
> debug_query_string = NULL;
On closer inspection, ther
David Rowley writes:
> On Wed, 23 Dec 2020 at 18:07, Michael Paquier wrote:
>> adminpack and old_snapshot have no need for those references as they
>> don't use libpq. Any objections to a small-ish cleanup that removes
>> those references, as per the attached?
> I think these can be safely remo
On Wed, 23 Dec 2020 at 18:07, Michael Paquier wrote:
> While looking at a patch from David, I have noticed $subject:
> https://www.postgresql.org/message-id/CAApHDvpgB+vxk=w6opkidwzzeo6knifqidnomzr8p4rotyk...@mail.gmail.com
>
> adminpack and old_snapshot have no need for those references as they
>
Thomas Munro writes:
> On Wed, Dec 30, 2020 at 5:45 AM Tom Lane wrote:
> +/* We assume the error must be "out of memory" */
> +ereport(LOG,
> +(errcode(ERRCODE_OUT_OF_MEMORY),
> + errmsg("out of memory")));
> Wouldn't it be better t
I wrote:
> ... so my guess is that something messed up in transmitting or combining a
> parallel worker's execution time.
Hmph, no, a look at explain.c shows that the "Execution Time" is just
based on the difference of INSTR_TIME_SET_CURRENT measurements taken
within the current process. It's dif
On Wed, 30 Dec 2020 at 10:03, David Rowley wrote:
>
> On Wed, 23 Dec 2020 at 18:46, Michael Paquier wrote:
> > I have tested your patch, and this is causing compilation failures for
> > hstore_plpython, jsonb_plpython and ltree_plpython. So
> > AddTransformModule is missing something here when c
On Wed, 23 Dec 2020 at 18:46, Michael Paquier wrote:
> I have begun a new thread about this point as that's a separate
> topic. I did not see other places in need of a similar cleanup:
> https://www.postgresql.org/message-id/x+lqpflyk7jgz...@paquier.xyz
Thanks. I'll look at that shortly.
> > I
Hey, hackers,
As part of building Postgres for a managed environment in Google Cloud SQL,
we've made various small changes to permission checks to carefully limit what
customers have access to.
We were making some changes in src/backend/commands/user.c and noticed some
clunky logic related to ver
On Wed, Dec 30, 2020 at 5:45 AM Tom Lane wrote:
> Since the cfbot seems happy with v1, here's a v2 that runs around
> and converts all putenv() uses to setenv(). In some places there's
> no notational savings, but it seems to me that standardizing
> on just one way to do it is beneficial.
+
> 28 дек. 2020 г., в 11:14, Andrey Borodin написал(а):
>
>> Thanks for the patch. Maybe we can allow setting custom compression
>> methods for wal compression as well.
>
> No, unfortunately, we can't use truly custom methods. Custom compression
> handlers are WAL-logged. So we can use only s
Since the cfbot seems happy with v1, here's a v2 that runs around
and converts all putenv() uses to setenv(). In some places there's
no notational savings, but it seems to me that standardizing
on just one way to do it is beneficial.
I'm not sure if there would be any value in revising win32env.c
Michael Paquier writes:
> Buildfarm member gombessa just had an interesting failure:
> - Execution Time: N.N ms
> + Execution Time: -N.N ms
> Not sure what to think about that, as this implies the calculation of
> a negative execution time.
Yeah, I saw that. I notice that gombessa uses
Hi Thomas
I found some other problems which I want to share my change with you to make
you confirm.
<1> I changed the code in smgr_alloc_sr to avoid dead lock.
LWLockAcquire(mapping_lock, LW_EXCLUSIVE);
flags = smgr_lock_sr(sr);
Assert(flags & SR_SYNCING(forknum));
+ flags &= ~SR_SYNCING
Magnus Hagander writes:
> On Tue, Dec 29, 2020 at 1:37 AM Michael Paquier wrote:
>> Magnus, do I have an access to that? This is the second time I am
>> crossing an issue with this issue, but I don't really know if I should
>> act on it or not :)
> No, at this point it's just Tom (who has all t
https://postgr.es/m/20201031163518.gb4039...@rfd.leadboat.com gave $SUBJECT as
one of the constituent projects for changing the public schema default ACL.
This ended up being simple. Attached. I chose to omit the "ALTER SCHEMA
public OWNER TO" when the owner is the bootstrap superuser, like how w
Hi
> see new version in attachment.
I took a look into the patch, and have some comments.
1.
+ PG_FINALLY();
+ {
+ copy_fmstate = NULL; /* Detect problems */
I don't quite understand this comment,
does it means we want to detect something like Null reference ?
2.
+
On Tue, Dec 29, 2020 at 1:37 AM Michael Paquier wrote:
> On Mon, Dec 28, 2020 at 11:42:03AM +0100, Magnus Hagander wrote:
> > Not as much "tightly controlled" as "nobody's really bothered to grant
> any
> > permissions".
>
> Magnus, do I have an access to that? This is the second time I am
> cro
Hello Peter,
My 0.02€:
So strictly speaking this SQL code is nonstandard anyway. But our
lexer has always been forgiving about not requiring space if it's
not logically necessary to separate tokens. I doubt trying to
change that would improve matters.
Well, the idea is to diagnose potentia
Hi Sawada-san,
I think Amit has a plan to commit this patch-set in phases. I will
leave it to him to decide because I think he has a plan.
I took time to refactor the test_decoding isolation test for
consistent snapshot so that it uses just 3 sessions rather than 4.
Posting an updated patch-0009
Hi all,
Buildfarm member gombessa just had an interesting failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gombessa&dt=2020-12-29%2000%3A16%3A49
Seq Scan on int8_tbl i8 (cost=N.N..N.N rows=N width=N) (actual
time=N.N..N.N rows=N loops=N)
Planning Time: N.N ms
- Execution Tim
On Sun, Dec 27, 2020 at 02:26:05PM -0600, Justin Pryzby wrote:
> I think a couple of these should be backpatched.
> doc/src/sgml/ref/pg_dump.sgml
This part can go down to 9.5.
> doc/src/sgml/sources.sgml
Yes, I have done an extra effort on those fixes where needed. On top
of that, I have includ
On 2020-12-28 21:54, Tom Lane wrote:
Peter Eisentraut writes:
I was surprised to find that this doesn't error:
=> select 100a;
a
-
100
I suspect this and similar cases used to error before aliases without AS
were introduced. But now this seems possibly problematic. Should we
try
> On 28 Dec 2020, at 13:04, Masahiko Sawada wrote:
> if you want your patch to be reviewed as part of the
> upcoming CommitFest, then you need to add it yourself before
> 2021-01-01 AoE[2]. Thanks for your contributions.
I thought I had added it but clearly I had missed doing so, fixed now. Tha
Hi Önder,
On Thu, Dec 17, 2020 at 3:43 PM Önder Kalacı wrote:
>
> Hi all,
>
> I'm also interested in this patch. I rebased the changes to the current
> master branch and attached. The rebase had two issues. First, patch-8 was
> conflicting, and that seems only helpful for debugging purposes dur
Hi Konstantin,
On Sat, Dec 19, 2020 at 9:50 PM Konstantin Knizhnik
wrote:
>
>
>
> On 19.12.2020 10:53, Zhihong Yu wrote:
> > Hi,
> > w.r.t. the code in BufferAlloc(), the pointers are compared.
> >
> > Should we instead compare the tranche Id of the two LWLock ?
> >
> > Cheers
>
> As far as LWloc
50 matches
Mail list logo
