On Mon, Mar 8, 2021 at 4:19 PM Amit Kapila wrote:
>
> On Mon, Mar 8, 2021 at 10:04 AM Peter Smith wrote:
> >
> > On Sun, Mar 7, 2021 at 3:00 PM Amit Kapila wrote:
> > >
> > > On Sun, Mar 7, 2021 at 7:35 AM Peter Smith wrote:
> > > >
> > > > Please find attached the latest patch set v51*
> > >
On Mon, Mar 8, 2021, at 07:28, Joel Jacobson wrote:
>Attached is a new patch with both pg_permissions and pg_ownerships in the same
>patch,
>based on HEAD (8a812e5106c5db50039336288d376a188844e2cc).
>
>Attachments:
>0001-pg_permissions-and-pg_ownerships.patch
I forgot to update
On Fri, Mar 5, 2021 at 5:00 AM Tom Lane wrote:
> Amit Langote writes:
> > Updated patch attached.
>
> This claim seems false on its face:
>
> > All child constraints of a given foreign key constraint can use the
> > same RI query and the resulting plan, that is, no need to create as
> > many
Dear Fujii-san, Miyake-san
> Isn't it better to accept even negative sleep time like currently pgbench
> does?
> Otherwise we always need to check the variable is a positive integer
> (for example, using \if command) when using it as the sleep time in \sleep
> command. That seems inconvenient.
On Sun, Mar 07, 2021 at 07:07:07PM -0600, Justin Pryzby wrote:
> This renames to use SET ACCESS METHOD (resolving a silly typo);
> And handles the tuple slots more directly;
> And adds docs and tab completion;
>
> Also, since 8586bf7ed8889f39a59dd99b292014b73be85342:
> |For now it's not
Hi Amit, Greg,
Sorry, I hadn't noticed last week that some questions were addressed to me.
On Sat, Mar 6, 2021 at 7:19 PM Amit Kapila wrote:
> Thanks, your changes look good to me. I went ahead and changed the
> patch to track the partitionOids once rather than in two separate
> lists and use
On 2021/03/08 14:58, kuroda.hay...@fujitsu.com wrote:
Dear Miyake-san,
Thank you for updating the patch.
When argc == 2, pgbench assumes that (1) argv[1] is just a number (e.g.
\sleep 10) or (2) argv[1] is a pair of a number and a time unit (e.g.
\sleep 10ms).
I see.
So I fixed the
On Fri, Mar 5, 2021 at 7:50 AM Ryan Lambert wrote:
> On Wed, Mar 3, 2021 at 11:03 PM Amit Langote wrote:
>>
>> Sorry, this seems to have totally slipped my mind.
>>
>> Attached is the patch I had promised.
>>
>> Also, I have updated the title of the CF entry to "Some cosmetic
>> improvements of
From: Amit Kapila
> For now, I have left 0005 and 0006 patches, we can come back to those once we
> are done with the first set of patches. The first patch looks good to me and I
> think we can commit it and then bikeshed about GUC/reloption patch.
Agreed, it looks good to me, too.
Regards
On Mon, Mar 8, 2021, at 02:09, David Fetter wrote:
> +1 for both this and the ownerships view.
>
> Best,
> David.
I'm glad you like it.
I've put some more effort into this patch, and developed a method to
mechanically verify its correctness.
Attached is a new patch with both pg_permissions
On Sat, Mar 6, 2021 at 9:19 PM Amit Kapila wrote:
>
> On Fri, Mar 5, 2021 at 6:34 PM Greg Nancarrow wrote:
> >
> > For the time being at least, I am posting an updated set of patches,
> > as I found that the additional parallel-safety checks on DOMAIN check
> > constraints to be somewhat
On Mon, Mar 8, 2021 at 7:17 AM Peter Smith wrote:
>
> Please find attached the latest patch set v52*
>
Few comments:
+logicalrep_read_begin_prepare(StringInfo in,
LogicalRepBeginPrepareData *begin_data)
+{
+ /* read fields */
+ begin_data->final_lsn = pq_getmsgint64(in);
+ if
Dear Miyake-san,
Thank you for updating the patch.
> When argc == 2, pgbench assumes that (1) argv[1] is just a number (e.g.
> \sleep 10) or (2) argv[1] is a pair of a number and a time unit (e.g.
> \sleep 10ms).
I see.
> So I fixed the problem as follows:
> 1) When argv[1] starts with a
On Tue, Feb 2, 2021 at 10:51 AM Euler Taveira wrote:
>
> On Fri, Jan 29, 2021, at 4:35 AM, Masahiko Sawada wrote:
>
> I agree to have autovacuum log more information, especially index
> vacuums. Currently, the log related to index vacuum is only the number
> of index scans. I think it would be
> On 2021.03.08. 01:30 Thomas Munro wrote:
>
>
> On Sun, Mar 7, 2021 at 3:21 AM Julien Rouhaud wrote:
> > On Sat, Mar 06, 2021 at 03:00:46PM +0100, e...@xs4all.nl wrote:
> > >
> > > I was looking at the 'Catalog version access' patch, by Vik Fearing. I
> > > saw a succesful build by the
Currently pgbench uses plain COPY to populate pgbench_accounts
table. With adding FREEZE option to COPY, the time to perform "pgbench
-i" will be significantly reduced.
Curent master:
pgbench -i -s 100
:
:
done in 70.78 s (drop tables 0.21 s, create tables 0.02 s, client-side generate
12.42 s,
On Tue, Feb 2, 2021 at 9:59 AM Tommy Li wrote:
>
> Hi Masahiko
>
> > If we set
> > it per-table basis, it’s useful when the user already knows which
> > tables are likely to take a long time for autovacuum
>
> I would assume that's the default case, most apps I've seen are designed
> around a
On Tue, Nov 17, 2020 at 6:56 PM Etsuro Fujita wrote:
> * I haven't yet added some planner/resowner changes from Horiguchi-san's
> patch.
The patch in [1] allocates, populates, frees a wait event set every
time when doing ExecAppendAsyncEventWait(), so it wouldn’t leak wait
event sets.
On Fri, Mar 5, 2021 at 6:00 AM Tom Lane wrote:
> Amit Langote writes:
> > Updated patch attached.
>
> This claim seems false on its face:
>
> > All child constraints of a given foreign key constraint can use the
> > same RI query and the resulting plan, that is, no need to create as
> > many
On Mon, Mar 8, 2021 at 10:04 AM Peter Smith wrote:
>
> On Sun, Mar 7, 2021 at 3:00 PM Amit Kapila wrote:
> >
> > On Sun, Mar 7, 2021 at 7:35 AM Peter Smith wrote:
> > >
> > > Please find attached the latest patch set v51*
> > >
> >
> > Few more comments on
On Fri, Mar 5, 2021 at 12:12 PM Thomas Munro wrote:
> On Fri, Feb 26, 2021 at 7:08 PM Thomas Munro wrote:
> > Back in 2016, Robert Haas proposed to replace I/O locks with condition
> > variables[1]. Condition variables went in and have found lots of
> > uses, but this patch to replace a bunch
On Thu, Mar 4, 2021 at 1:00 PM Etsuro Fujita wrote:
> To avoid that, how about 1) adding the
> table/server options to postgres_fdw that allow/disallow async
> execution, and 2) setting them to false by default?
There seems to be no objections, so I went ahead and added the
table/server option
On Tue, Mar 2, 2021 at 1:42 PM Peter Geoghegan wrote:
>
> On Mon, Mar 1, 2021 at 8:06 PM Masahiko Sawada wrote:
> > I think that removing vacuum_cleanup_index_scale_factor in the back
> > branches would affect the existing installation much. It would be
> > better to have btree indexes not use
On 2021/03/05 19:54, Masahiro Ikeda wrote:
On 2021-03-05 12:47, Fujii Masao wrote:
On 2021/03/05 8:38, Masahiro Ikeda wrote:
On 2021-03-05 01:02, Fujii Masao wrote:
On 2021/03/04 16:14, Masahiro Ikeda wrote:
On 2021-03-03 20:27, Masahiro Ikeda wrote:
On 2021-03-03 16:30, Fujii Masao
On Mon, Mar 08, 2021 at 10:49:20AM +0900, Masahiko Sawada wrote:
> On Fri, Mar 5, 2021 at 10:43 PM Masahiko Sawada wrote:
> >
> > On Fri, Mar 5, 2021 at 6:51 PM Julien Rouhaud wrote:
> > >
> > > On Fri, Mar 05, 2021 at 06:07:05PM +0900, Fujii Masao wrote:
> > > >
> > > > On 2021/03/05 15:59,
On Sun, Mar 7, 2021 at 3:00 PM Amit Kapila wrote:
>
> On Sun, Mar 7, 2021 at 7:35 AM Peter Smith wrote:
> >
> > Please find attached the latest patch set v51*
> >
>
> Few more comments on v51-0006-Fix-apply-worker-empty-prepare:
> ==
> 1.
> +/*
On Sun, Mar 7, 2021 at 10:13 PM Zhihong Yu wrote:
> Hi,
>
> +* EXPLAIN ANALYZE CREATE TABLE AS or REFRESH MATERIALIZED VIEW
> +* WITH NO DATA is weird.
>
> Maybe it is clearer to spell out WITH NO DATA for both statements, instead of
> sharing it.
Done that way.
> - if
On Thu, Mar 04, 2021 at 08:03:25PM +0530, Amit Kapila wrote:
> I think here we have a slight timing thing which is if the checkpoint
> happens before restart then the problem won't occur, not sure but
> maybe increase the checkpoint_timeout as well to make it reproducible.
Thanks for providing
Hi,
On 2/10/21 11:10 PM, Stephen Frost wrote:
> Greetings,
>
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 05/02/2021 23:22, Stephen Frost wrote:
>>> Unless there's anything else on this, I'll commit these sometime next
>>> week.
>>
>> One more thing: Instead of using
On Sun, Mar 7, 2021 3:48 AM Peter Eisentraut
wrote:
> On 28.01.21 01:44, osumi.takami...@fujitsu.com wrote:
> >> (1) writing the time or LSN in the control file to indicate
> >> when/where wal_level is changed to 'minimal'
> >> from upper level to invalidate the old backups or make alerts to
On Thu, Mar 4, 2021 at 1:40 PM Michael Paquier wrote:
>
> On Wed, Mar 03, 2021 at 09:06:11AM +0530, Amit Kapila wrote:
> > Michael, I want to push this patch soon unless you have any concerns.
>
> No concerns from me...
>
Pushed! I have tried but couldn't come up with a good way other than
On Fri, Mar 5, 2021 at 6:22 PM Thomas Munro wrote:
> On Thu, Mar 4, 2021 at 10:44 PM Thomas Munro wrote:
> > v10-0002-pgbench-Refactor-the-way-we-do-thread-portabilit.patch
>
> Here's a better version of that part. I don't yet know if it actually
> works on Windows...
David Rowley kindly
Thank you for your comments!
I fixed my patch based on your comment, and attached it to this mail.
2021-03-05 12:57, kuroda.hay...@fujitsu.com wrote:
* When the following line is input, the error message is not happy.
I think output should be " \sleep command argument must be an
On Fri, Mar 5, 2021 at 10:43 PM Masahiko Sawada wrote:
>
> On Fri, Mar 5, 2021 at 6:51 PM Julien Rouhaud wrote:
> >
> > On Fri, Mar 05, 2021 at 06:07:05PM +0900, Fujii Masao wrote:
> > >
> > > On 2021/03/05 15:59, Julien Rouhaud wrote:
> > > >
> > > > I don't especially want to defer autoanalyze
On Thu, 4 Mar 2021 at 22:07, Amit Langote wrote:
> * Or maybe have you considered generalizing what
> build_implied_pruning_quals() does so that other places like
> indxpath.c can use the facility?
I agree with doing it another way. There's plenty of other queries
which we could produce a
Thomas Munro writes:
> Thanks! I'm afraid I wouldn't get around to it for a few weeks, so if
> you have time, please do. (I'm not sure if it's strictly necessary to
> log *this* xid, if a higher xid has already been logged, considering
> that the goal is just to avoid getting confused about an
On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote:
> Hi,
>
> It's easy to answer the question...
>
>- What permissions are there on this specific object?
>
> ...but to answer the question...
>
>- What permissions are there for a specific role in the database?
>
> you need
On Mon, Mar 01, 2021 at 11:16:36AM +0900, Michael Paquier wrote:
> On Sun, Feb 28, 2021 at 04:25:30PM -0600, Justin Pryzby wrote:
> > I called this "set TABLE access method" rather than just "set access method"
> > for the reasons given on the LIKE thread:
> >
On Mon, Mar 8, 2021 at 1:39 PM Kyotaro Horiguchi
wrote:
> At Fri, 05 Mar 2021 11:16:55 -0500, Tom Lane wrote in
> > Kyotaro Horiguchi writes:
> > But, of course, first we need a fix for the bug we now know exists.
> > Was anyone volunteering to make the patch?
>
> Thomas' proposal sounds
At Fri, 05 Mar 2021 11:16:55 -0500, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > So I think we need to remove the shared_buffers setting for the
> > allows_streamig case in PostgresNode.pm
>
> That would have uncertain effects on other TAP tests, so I'm disinclined
> to do it that way.
At Sat, 6 Mar 2021 10:25:46 +0900, Michael Paquier wrote
in
> On Fri, Mar 05, 2021 at 11:16:55AM -0500, Tom Lane wrote:
> > That would have uncertain effects on other TAP tests, so I'm disinclined
> > to do it that way.
>
> +1. There may be tests out-of-core that rely on this value as
>
On Sun, Mar 7, 2021 at 3:21 AM Julien Rouhaud wrote:
> On Sat, Mar 06, 2021 at 03:00:46PM +0100, e...@xs4all.nl wrote:
> >
> > I was looking at the 'Catalog version access' patch, by Vik Fearing. I saw
> > a succesful build by the cfbot but I could not build one here. Only then
> > did I
> On 7 Mar 2021, at 09:43, Tharakan, Robins wrote:
> The patch (attached):
> - Applies cleanly on REL9_6_STABLE -
> c7a4fc3dd001646d5938687ad59ab84545d5d043
Did you target 9.6 because that's where you want to upgrade to, or is this not
a problem on HEAD? If it's still a problem on HEAD you
On Sun, 7 Mar 2021 at 23:24, Pavel Stehule wrote:
The mandatory ORDER BY clause should be necessary for operations when
the result depends on the order. You need an order for calculation of
median. And you don't need to know an order for average. More if the
result is one number and is not
On 3/7/21 2:35 PM, Zhihong Yu wrote:
> Joe:
> I don't seem to find attachment.
>
> Maybe attach again ?
Oops -- I did forget that, didn't I. This time patch is attached :-)
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open
Joe:
I don't seem to find attachment.
Maybe attach again ?
Thanks
On Sun, Mar 7, 2021 at 11:12 AM Joe Conway wrote:
> On 3/3/21 9:43 AM, Joe Conway wrote:
> > On 3/3/21 8:50 AM, David Steele wrote:
> >> On 1/29/21 4:56 AM, Joe Conway wrote:
> >>> On 1/29/21 12:13 AM, Ian Lawrence Barwick
On 3/3/21 9:43 AM, Joe Conway wrote:
> On 3/3/21 8:50 AM, David Steele wrote:
>> On 1/29/21 4:56 AM, Joe Conway wrote:
>>> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
2021年1月28日(木) 17:18 Peter Eisentraut:
I'm not convinced the current behavior is wrong. Is there some
The code in pg_stat_get_subscription() appears to believe that it
can return a set of rows, but its pg_proc entry does not have
proretset set. It may be that this somehow accidentally fails
to malfunction when the function is used via the system views,
but if you try to call it directly it falls
On Sun, Mar 7, 2021 at 3:39 PM Fujii Masao wrote:
>
>
>
> On 2021/03/06 5:37, Alvaro Herrera wrote:
> > On 2021-Mar-05, James Coleman wrote:
> >
> >> Do you have any thoughts on what you'd like to see the message be? I
> >> could change the PM_RECOVERY (without hot standby enabled) to return
> >>
Hi,
+* EXPLAIN ANALYZE CREATE TABLE AS or REFRESH MATERIALIZED VIEW
+* WITH NO DATA is weird.
Maybe it is clearer to spell out WITH NO DATA for both statements, instead
of sharing it.
- if (!stmt->skipData)
+ if (!stmt->skipData && !explainInfo)
...
+ else if (explainInfo)
Pavel Stehule writes:
> But this is offtopic in this discussion :)
The whole topic is off-topic. As a general rule, things that depend on
input order shouldn't be declared as aggregates --- they should be window
functions or ordered-set aggregates, for which the syntax forces you to
specify
On 2021/03/06 5:37, Alvaro Herrera wrote:
On 2021-Mar-05, James Coleman wrote:
Do you have any thoughts on what you'd like to see the message be? I
could change the PM_RECOVERY (without hot standby enabled) to return
CAC_RECOVERY which would give us the message "the database system is
in
On Sun, 07 Mar 2021 at 19:43, Bharath Rupireddy
wrote:
> I'm reading through the v6 patches again, here are some comments.
>
Thanks for your review again.
> 1) IMO, we can merge 0001 into 0002
> 2) A typo, it's "current" not "ccurrent" - + * Merge ccurrent
> subscription's publications and
On Sun, Mar 7, 2021 at 2:19 PM Justin Pryzby wrote:
>
> Earlier in this thread, I suggested to implement an option to pg_restore to
> avoid outputting compression, in order to allow restoring with a different
> compression (by using the default_toast_compression GUC). Now, it seems like
> that's
On Sun, 07 Mar 2021 at 17:33, Bharath Rupireddy
wrote:
> On Sun, Mar 7, 2021 at 12:13 PM Japin Li wrote:
>>
>> On Sun, 07 Mar 2021 at 14:25, Bharath Rupireddy
>> wrote:
>> > On Sun, Mar 7, 2021 at 11:49 AM Japin Li wrote:
>> >>
>> >> On Fri, 05 Mar 2021 at 19:48, Bharath Rupireddy
>> >>
ne 7. 3. 2021 v 12:39 odesílatel Vik Fearing
napsal:
> On 3/7/21 11:37 AM, Pavel Stehule wrote:
> > ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing
> > napsal:
> >
> >> On 3/7/21 11:24 AM, Pavel Stehule wrote:
>
> And so you are now mandating an ORDER BY on every query and in every
>
On Thu, Feb 18, 2021 at 8:01 AM japin wrote:
> On Tue, 16 Feb 2021 at 09:58, Bharath Rupireddy
> wrote:
> > On Mon, Feb 15, 2021 at 8:13 AM Bharath Rupireddy
> > wrote:
> >>
> >> On Sat, Feb 13, 2021 at 11:41 AM japin wrote:
> >> > > IIUC, with the current patch, the new ALTER SUBSCRIPTION
On 3/7/21 11:37 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing
> napsal:
>
>> On 3/7/21 11:24 AM, Pavel Stehule wrote:
And so you are now mandating an ORDER BY on every query and in every
aggregate and/or window function. Users will not like that at all.
On Fri, Mar 5, 2021 at 11:30 AM Michael Paquier wrote:
>
> On Thu, Mar 04, 2021 at 05:45:50PM +0100, Matthias van de Meent wrote:
> > Sure, I'm convinced. PFA the patchset with this change applied.
>
> 0002 looks fine to me, and in line with the discussion, so applied.
Thanks.
Attaching
ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing
napsal:
> On 3/7/21 11:24 AM, Pavel Stehule wrote:
> >>
> >> And so you are now mandating an ORDER BY on every query and in every
> >> aggregate and/or window function. Users will not like that at all. I
> >> certainly shan't.
> >>
> >
> > The
On 3/7/21 11:24 AM, Pavel Stehule wrote:
>>
>> And so you are now mandating an ORDER BY on every query and in every
>> aggregate and/or window function. Users will not like that at all. I
>> certainly shan't.
>>
>
> The mandatory ORDER BY clause should be necessary for operations when the
>
>
> And so you are now mandating an ORDER BY on every query and in every
> aggregate and/or window function. Users will not like that at all. I
> certainly shan't.
>
The mandatory ORDER BY clause should be necessary for operations when the
result depends on the order. You need an order for
On Fri, Feb 5, 2021 at 5:15 PM Bharath Rupireddy
wrote:
>
> pg_terminate_backend and pg_cancel_backend with postmaster PID produce
> "PID is not a PostgresSQL server process" warning [1], which
> basically implies that the postmaster is not a PostgreSQL process at
> all. This is a bit
On 3/7/21 11:05 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing
> napsal:
>
>> On 3/7/21 10:53 AM, Pavel Stehule wrote:
>>> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
>>> napsal:
>>>
On 3/6/21 9:06 PM, David G. Johnston wrote:
> On Saturday, March 6, 2021,
ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing
napsal:
> On 3/7/21 10:53 AM, Pavel Stehule wrote:
> > ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
> > napsal:
> >
> >> On 3/6/21 9:06 PM, David G. Johnston wrote:
> >>> On Saturday, March 6, 2021, David Fetter wrote:
> >>>
>
> >>
On 3/7/21 10:53 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
> napsal:
>
>> On 3/6/21 9:06 PM, David G. Johnston wrote:
>>> On Saturday, March 6, 2021, David Fetter wrote:
>>>
>> SELECT BIT_XOR(b ORDER BY a, c).../* works */
>> SELECT
ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
napsal:
> On 3/6/21 9:06 PM, David G. Johnston wrote:
> > On Saturday, March 6, 2021, David Fetter wrote:
> >
> >>
> SELECT BIT_XOR(b ORDER BY a, c).../* works */
> SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
>
On 3/6/21 9:06 PM, David G. Johnston wrote:
> On Saturday, March 6, 2021, David Fetter wrote:
>
>>
SELECT BIT_XOR(b ORDER BY a, c).../* works */
SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
SELECT BIT_XOR(b) FROM... /* errors out */
>>>
On Sun, Mar 7, 2021 at 12:13 PM Japin Li wrote:
>
> On Sun, 07 Mar 2021 at 14:25, Bharath Rupireddy
> wrote:
> > On Sun, Mar 7, 2021 at 11:49 AM Japin Li wrote:
> >>
> >> On Fri, 05 Mar 2021 at 19:48, Bharath Rupireddy
> >> wrote:
> >> > Attaching v5 patch set for further review.
> >> >
> >>
On Sat, Mar 6, 2021 at 10:36 PM Magnus Hagander wrote:
>
> > Attaching v6 patch. Please have a look.
>
> Taking another look at this patch. Here are a few more comments:
Thanks for the review comments.
> For pg_terminate_backend, wouldn't it be easier to just create one
> function that has a
On Sun, Mar 07, 2021 at 01:36:50PM +0530, Dilip Kumar wrote:
> On Sun, Mar 7, 2021 at 12:47 PM Justin Pryzby wrote:
> > > IMHO we can always allow creating the table with lz4 and only error
> > > out when we really need to compress/decompress the data. I like this
> > > behavior because it is
On Sun, Mar 7, 2021 at 12:47 PM Justin Pryzby wrote:
> > IMHO we can always allow creating the table with lz4 and only error
> > out when we really need to compress/decompress the data. I like this
> > behavior because it is the same as libxml. But I am fine with
> > allowing it only in binary
> What'd be better, if we could do it, is to ship the clause in
> the form
> WHERE foreigncol = 'one'
> that is, instead of plastering a cast on the Var, try to not put
> any explicit cast on the constant. That fixes your original use
> case better than what you've proposed, and I think it might
73 matches
Mail list logo
