On Wed, Nov 24, 2021 at 7:46 PM John Naylor
wrote:
>
> On Wed, Nov 17, 2021 at 7:28 AM Amit Kapila wrote:
> >
> > > The patch looks good to me. But I can't come up with a stable test for
> > > this. It seems to be hard without stopping and resuming parallel
&g
. To allow non-superusers
owners, I thought it might be better to first try to detect the change
of ownership as soon as possible instead of at the transaction
boundary.
--
With Regards,
Amit Kapila.
you think that we
can change it just before committing that patch? I thought it might be
better to do it that way now itself.
[1] -
https://www.postgresql.org/message-id/CAD21AoCQ8z5goy3BCqfk2gn5p8NVH5B-uxO3Xc-dXN-MXVfnKg%40mail.gmail.com
--
With Regards,
Amit Kapila.
On Thu, Nov 25, 2021 at 1:30 PM Amit Langote wrote:
>
> On Wed, Nov 24, 2021 at 5:44 PM Amit Kapila wrote:
> > On Wed, Nov 24, 2021 at 12:02 PM Amit Langote
> > wrote:
> > > So yeah, documenting the ATTACH issue as a limitation sounds like the
> > > best
idea to document
it.
[1] - https://elephanttamer.net/?p=58
[2] -
https://www.postgresql.org/message-id/CALDaNm2-SRGHK0rqJQu7rGiS4hDAb7Nib5HbojEN5ubaXGs2CA%40mail.gmail.com
--
With Regards,
Amit Kapila.
case, before following any of these, I suggest creating a dummy
setup that mimics your original setup, perform the above steps and
ensure everything is fine, then only try the same steps in your main
setup.
--
With Regards,
Amit Kapila.
On Fri, Nov 26, 2021 at 7:10 AM houzj.f...@fujitsu.com
wrote:
>
> On Thursday, November 25, 2021 4:57 PM Amit Kapila
> wrote:
> > On Thu, Nov 25, 2021 at 1:30 PM Amit Langote
> > >
> > > I agree with backpatching the doc fix. I've attached a diff agains
-up patch and I also think this
is the right behavior.
--
With Regards,
Amit Kapila.
(country = 'NZ') with
> (publish='insert')
>
> Should it be possible to UPDATE for country 'NZ' or not?
> Is this the same as your question Hou-san?
>
I am not sure if it is the same because in Hou-San's example
publications refer to different columns where one of the columns was
part of PK and another was not whereas in your example both refer to
the same column. I think in your example the error will happen at the
time of update/delete whereas in Hou-San's example it won't happen at
the time of update/delete.
With Regards,
Amit Kapila.
nd we
were not sending it again, changed the test case file name to
026_stats as we can add more subscription-related stats in this test
file itself (c) added/edited multiple comments, (d) updated
PGSTAT_FILE_FORMAT_ID.
Do let me know what you think of the attached?
--
With Regards,
Amit Kapila.
the worker is synchronizing; null for the
> + main apply worker
>
> Should we modify it to "OID of the relation that the worker was synchronizing
> ..."?
>
I don't think this change is required, see the description of the
similar column in pg_stat_subscription.
--
With Regards,
Amit Kapila.
or records, this problem has nothing to do with any changes
in PG-14, the same behavior exists in the previous versions as well.
[1] - https://www.postgresql.org/docs/devel/app-pgdump.html
--
With Regards,
Amit Kapila.
changes between pg_upgrade and now should be
directly copied from tables, so probably older WAL won't be required.
--
With Regards,
Amit Kapila.
On Mon, Nov 29, 2021 at 7:12 AM Masahiko Sawada wrote:
>
> On Sat, Nov 27, 2021 at 7:56 PM Amit Kapila wrote:
> >
>
> Thank you for updating the patch!
>
> > I have made a number of changes in the attached patch which includes
> > (a) the patch was trying to re
pect when exactly the privilege change will be reflected and
it won't depend on the number of changes in the transaction.
--
With Regards,
Amit Kapila.
ync for rls
enabled tables. (c) evaluate/analyze what is required to allow Copy
>From to start respecting RLS policies. (d) reject replicating any
changes to tables that have RLS enabled.
I see that you are favoring (d) which clearly has merits like lesser
code/design change but not sure if that is the best way forward or we
can do something better than that either by following one of (a), (b),
(c), or something less restrictive than (d).
--
With Regards,
Amit Kapila.
27;d properly know the answer as to whether the old row value had been
> published and it would have correctly performed an UPDATE instead of
> an INSERT in this case.
>
I don't think it is a good idea to combine the row-filter from the
publication that publishes just 'insert' with the row-filter that
publishes 'updates'. We shouldn't apply the 'insert' filter for
'update' and similarly for publication operations. We can combine the
filters when the published operations are the same. So, this means
that we might need to cache multiple row-filters but I think that is
better than having another restriction that publish operation 'insert'
should also honor RI columns restriction.
--
With Regards,
Amit Kapila.
n’t know if this
> > will be very user friendly. It means now sometimes you can
> > successfully CREATE a PUBLICATION even though it will fail as soon as
> > you try to use it.
>
> I am not sure, the initial idea here is to make the check of replica identity
> consistent.
>
> Currently, if user create a publication which publish "update" but the
> relation
> in the publication didn't mark as replica identity, then user can create the
> publication successfully. but the later UPDATE will report an error.
>
Yeah, I think giving an error on Update/Delete should be okay.
--
With Regards,
Amit Kapila.
t to be
> clarified in the function comment, and/or perhaps also rename the
> function so that the return meaning is more obvious.
>
+1 to rename the function in this case.
--
With Regards,
Amit Kapila.
On Mon, Nov 29, 2021 at 4:36 PM Dilip Kumar wrote:
>
> On Mon, Nov 29, 2021 at 3:41 PM Amit Kapila wrote:
>
> > > Publisher:
> > > INSERT INTO tbl1 VALUES (1,1);
> > > UPDATE tbl1 SET a = 2;
> > >
> > > Prior to the UPDATE above:
>
me information like trigger functions was not there in
your previous emails.
--
With Regards,
Amit Kapila.
On Mon, Nov 29, 2021 at 8:40 PM Euler Taveira wrote:
>
> On Mon, Nov 29, 2021, at 7:11 AM, Amit Kapila wrote:
>
> I don't think it is a good idea to combine the row-filter from the
> publication that publishes just 'insert' with the row-filter that
> publishes
implementation, (c) move the parallel vacuum
related code to a separate file?
I think if we can split the patch, it will be easier to review and
reduce the chances of introducing any bugs in this area.
--
With Regards,
Amit Kapila.
l fix the reported failure but there is another race
condition in the test. Isn't it possible that for table test_tab2, we
get an error "replication origin with OID ..." or some other error
before copy, in that case also, we will proceed from the second call
of test_subscription_error() which is not w
On Tue, Nov 30, 2021 at 11:37 AM Dilip Kumar wrote:
>
> On Tue, Nov 30, 2021 at 10:26 AM Amit Kapila wrote:
> >
> > On Mon, Nov 29, 2021 at 8:40 PM Euler Taveira wrote:
> > >
> > > On Mon, Nov 29, 2021, at 7:11 AM, Amit Kapila wrote:
> > >
> &g
ue iff the subscription owner is
> bypassrls or superuser. And then enforce RLS+WCO during
> insert/update/delete.
>
Yeah, that sounds reasonable to me.
> I don't think it's a big change (correct me if I'm wrong),
>
Yeah, I also don't think it should be a big change.
--
With Regards,
Amit Kapila.
On Tue, Nov 30, 2021 at 12:56 AM Jeff Davis wrote:
>
> On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote:
> > The first reason is that way it would be consistent with what we can
> > see while doing the operations from the backend.
>
> Logical replication is not interac
On Wed, Dec 1, 2021 at 6:55 AM Euler Taveira wrote:
>
> On Tue, Nov 30, 2021, at 7:25 AM, Amit Kapila wrote:
>
> On Tue, Nov 30, 2021 at 11:37 AM Dilip Kumar wrote:
> >
> > What about the initial table sync? during that, we are going to
> > combine all the filters
rigin ...") and then the test fail ?
>
Once we get the "duplicate key violation ..." error before * [1] * via
apply_worker then we shouldn't get replication origin-specific error
because the origin set up is done before starting to apply changes.
Also, even if that or some other happens after * [1] * because of
errmsg_prefix check it should still succeed. Does that make sense?
--
With Regards,
Amit Kapila.
On Wed, Dec 1, 2021 at 9:12 AM Masahiko Sawada wrote:
>
> On Wed, Dec 1, 2021 at 12:22 PM Amit Kapila wrote:
> >
> > On Wed, Dec 1, 2021 at 8:24 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > I have a question about the testcase (I could be wrong
On Fri, Nov 26, 2021 at 8:38 AM Amit Kapila wrote:
>
> On Fri, Nov 26, 2021 at 7:10 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Thursday, November 25, 2021 4:57 PM Amit Kapila
> > wrote:
> > > On Thu, Nov 25, 2021 at 1:30 PM Amit Langote
> > > &g
On Mon, Nov 29, 2021 at 2:37 PM houzj.f...@fujitsu.com
wrote:
>
> On Wed, Nov 24, 2021 4:48 PM Amit Kapila
> > On Mon, Nov 22, 2021 at 12:55 PM Amit Langote
> > wrote:
> > >
> > > On Fri, Nov 19, 2021 at 2:28 PM Amit Kapila
> > wrote:
> >
would do like
that and she might face some problems like what we are trying to solve
here.
Thoughts?
--
With Regards,
Amit Kapila.
v7-0001-Fix-double-publish-of-child-table-s-data.patch
Description: Binary data
tch when applied to the PG,
> which is possible to make other reviewers stop reviewing.
>
Vignesh seems to be suggesting just changing the commit message, not
the actual code. This is sort of a reminder to the committer to change
the catversion before pushing the patch. So that shouldn't caus
On Wed, Dec 1, 2021 at 2:12 AM Jeff Davis wrote:
>
> On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote:
> > I think it would be better to do it before we allow subscription
> > owners to be non-superusers.
>
> There are a couple other things to consider before allow
On Tue, Mar 20, 2018 at 1:23 AM, Robert Haas wrote:
> On Sat, Mar 17, 2018 at 1:16 AM, Amit Kapila wrote:
>> Test-1
>> --
>> DO $$
>> DECLARE count integer;
>> BEGIN
>> For count In 1..100 Loop
>> Execute 'explain Select ten from tenk
actionId));
}
It is not clear why you want to change this in RestoreSnapshot when
nothing related is changed in SerializeSnapshot? Can you please add
some comments to clarify it?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
ge-toast.html
Note - Please don't top post, try to reply inline. That is what all
of the people follow here and it is much more convenient that top
posting.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Sat, Mar 24, 2018 at 8:41 AM, Robert Haas wrote:
> On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote:
>> Yeah, sometimes that kind of stuff change performance characteristics,
>> but I think what is going on here is that create_projection_plan is
>> causing the lower n
th the part
> that's been vacuumed.
>
> This approach would also offer a less arbitrary way to decide how often
> to do the updates: choose a distance that has something to do with the
> FSM's structure, so that we don't waste effort reconsidering fragments
> of an upper tree page.
>
+1.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, Mar 27, 2018 at 3:08 AM, Robert Haas wrote:
> On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila wrote:
>> For me, it is equivalent to the master. The average of ten runs on
>> the master is 20664.3683 and with all the patches applied it is
>> 20590.4734. I think the
On Tue, Mar 27, 2018 at 10:59 PM, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote:
>> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote:
>>> If we don't want to go with the upperrel logic, then maybe we should
>>> consider just merging s
On Thu, Mar 29, 2018 at 2:31 AM, Robert Haas wrote:
> On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote:
>>
>> The above block takes 43700.0289 ms on Head and 45025.3779 ms with the
>> patch which is approximately 3% regression.
>
> Thanks for the analysis -- the obse
>sock == PGINVALID_SOCKET
>
- if (slot->sock < 0)
+ if (slot->sock == PGINVALID_SOCKET || slot->sock < 0)
If you are checking for PGINVALID_SOCKET, why do you need the second
part of check (slot->sock < 0)?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
gt; but if original code want to check (sock < -1)
>
If you see the code of PQsocket, then that won't be possible.
> I think it is better to leave that condition.
>
> but I think slot->sock == PGINVALID_SOCKET is enough
>
It is up to you, but I don't see any reason
tached old patch.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
at it has received the sighup, it will call
UpdateFullPageWrites which will log the record if required.
In general, I was wondering why in the first place this variable
(full_page_writes) is a SIGHUP variable? I think if the user tries to
switch it to 'on' from 'off', it won
On Sat, Mar 31, 2018 at 6:08 PM, CharSyam wrote:
> Thanks Amit.
> I had a mistake. Thank you again to point it out :)
>
Thanks, your new patch looks good.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
m
> gets this same information about which xids are actually vacuums that
> can be ignored when building a snapshot.
>
I think the vacuum assigns xids only if it needs to truncate some of
the pages in the relation which happens towards the end of vacuum.
So, it shouldn't hold back the xmin horizon for long.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
get serialized.
>
I think it would have been better if this code would have found the
free_slot before preparing the command and then used the connection
from free slot.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Sun, Apr 1, 2018 at 8:59 AM, Amit Kapila wrote:
> On Sat, Mar 31, 2018 at 11:33 PM, Tom Lane wrote:
>> ... Oh, just to make things even more fun, PQsocket() returns int, not
>> pgsocket; see its header comment. Therefore, that test is correctly
>> coded as-is (though it&
On Fri, Mar 30, 2018 at 1:41 AM, Robert Haas wrote:
> On Thu, Mar 29, 2018 at 12:55 AM, Amit Kapila wrote:
>> I think that is under acceptable range. I am seeing few regression
>> failures with the patch series. The order of targetlist seems to have
>> changed for Remote
On Sun, Apr 1, 2018 at 3:30 PM, Simon Riggs wrote:
> On 31 March 2018 at 14:21, Amit Kapila wrote:
>>
>> I think the vacuum assigns xids only if it needs to truncate some of
>> the pages in the relation which happens towards the end of vacuum.
>> So, it shouldn'
On Wed, Apr 4, 2018 at 4:31 AM, Andres Freund wrote:
> On 2018-03-06 19:57:03 +0530, Amit Kapila wrote:
>> On Tue, Mar 6, 2018 at 4:53 AM, Andres Freund wrote:
>> > Hi,
>> >
>> >> diff --git a/src/backend/executor/nodeLockRows.c
>> >> b/src/bac
c test files with
> number postfixes. Can't we combine them into a single file?
+1 for doing so.
> - as remarked elsewhere on this thread, I think the used errcode should
> be a serialization failure
>
No problem. I was telling up thread that the used error code has
On Thu, Apr 5, 2018 at 10:40 AM, David G. Johnston
wrote:
> On Wednesday, April 4, 2018, Amit Kapila wrote:
>>
>> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote:
>> >
>>
>> > Questions:
>> >
>> > - I'm not perfectly happ
On Fri, Apr 6, 2018 at 1:13 AM, Andres Freund wrote:
> On 2018-04-05 10:17:59 +0530, Amit Kapila wrote:
>> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote:
>> Why? tid is both an input and output parameter. The input tid is
>> valid and is verified at the top of the fu
due to concurrent update")));
As suggested by Andres, I think you should change the error code to
serialization failure i.e ERRCODE_T_R_SERIALIZATION_FAILURE.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
because this
would mean that we are defining the new scope for a GUC variable. I
guess we should take the input of others as well. I am not sure what
is the right way to do that, but maybe we can start a new thread with
a proper subject and description rather than discussing this under
some related bug fix patch discussion. I guess we can try that after
CF unless some other people pitch in and share their feedback.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
nk it is somewhat close to what you have mentioned in (b).
Basically, it will help executor to use that snapshot for tuple
visibility.
> I haven't yet gone to track down the code that assigns a snapshot to
> queryDesc->snapshot.
>
See CreateQueryDesc().
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
t; 4. bms_first_member() eats its input. Need to use bms_next_member() instead.
>
Won't in the success case, you need to delete each member (by
something like bms_del_member) rather than just using bms_free?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Sat, Apr 7, 2018 at 7:47 PM, Teodor Sigaev wrote:
> Thanks to everyone, pushed
>
Thanks!
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
s false for a rel, it's partial
path list should also be NULL.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Mon, Apr 9, 2018 at 5:52 PM, Amit Kapila wrote:
> On Sun, Apr 8, 2018 at 1:04 PM, Jeevan Chalke
> wrote:
>> Hi,
>>
>> At some places, I have observed that we are adding a partial path even when
>> rel's consider_parallel is false. Due to this, the partial
ctive snapshot, so any time
during execution, if you get the active snapshot via
GetActiveSnapshot(), you can access it. So, I think during a function
execution, if you use GetActiveSnapshot, you should get the snapshot
used by enclosing query.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
appens until the next checkpoint then it
> exposes itself to torn pages anyway as it chose to disable
> full_page_writes.
>
I think this means that is will be difficult for end users to predict
unless they track the next checkpoint which isn't too bad, but won't
be convenient either.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
provide some workable solution which can
help users.
[1] -
https://www.postgresql.org/message-id/CAA4eK1JPLGjpMeJ5YLNE7bpNBhP2EQe_rDR%2BAw3atNfj9WkAGg%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
n has the drawback that even after the user has
enabled it, there is a risk of torn pages.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
gt; would need to be issued after the configuration comes back again.
>
Why a second checkpoint? One checkpoint either manual or automatic
should be enough to make the setting effective.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
u have correctly spotted the problem and your fix looks good
to me. As this is a separate problem and fix is different from what
we are discussing here, I think this can be committed it separately.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
kwards or write a new API
similar to it which doesn't allow OldestXmin to move backwards and use
that for the purpose of vacuum.
Any better ideas?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Sat, Apr 21, 2018 at 1:26 AM, Andrew Gierth
wrote:
>>>>>> "Amit" == Amit Kapila writes:
>
> Amit> I haven't tried to reproduce it, but I can see the possibility of
> Amit> the problem described by you. What should we do next? I could see
>
On Mon, Apr 23, 2018 at 1:55 AM, Andrew Gierth
wrote:
>>>>>> "Amit" == Amit Kapila writes:
>
> Amit> by computing it before scanning the main heap (lazy_vacuum_rel)
> Amit> and then pass it down. I have tried it and came up with the
> Amit>
On Mon, Apr 23, 2018 at 1:34 PM, Andrew Gierth
wrote:
>>>>>> "Amit" == Amit Kapila writes:
>
> >> Your patch would actually be needed if (and only if) autovacuum was
> >> changed back to its old behavior of never vacuuming toast tables
> &g
ait_policy parameter to heap_lock_updated_tuple and
do the same handling as we do in the caller (heap_lock_tuple)?
Basically, whenever we need to wait on any tuple version do the same
as we do in heap_lock_tuple for 'require_sleep' case.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Mon, Sep 2, 2019 at 4:51 PM Amit Kapila wrote:
>
> On Fri, Aug 9, 2019 at 6:29 PM Robert Haas wrote:
> >
> >
> > But beyond that, the issue here is that the Limit node is shutting
> > down the Gather node too early, and the right fix must be to stop
>
s set, you can use true/false terminology as that
is what we use for this parameter. See explanation of "do_detoast"
that is used in function tuple_data_split in the same doc
(pageinspect.sgml) for reference.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Sun, Sep 8, 2019 at 1:06 PM Amit Kapila wrote:
>
> On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada wrote:
> >
> > Thanks. I hope the attached new patch fixes this issue.
> >
>
Some more comments:
*
+SELECT t_infomask, t_infomask2, flags
+FROM heap_page_ite
doesn't
seem to be addressed or at least not all of them are addressed. It is
possible that you would have already addressed those, but in that
case, it would be good if you respond to his email as well. If those
are not addressed, then it will be good to address those.
[1] -
https://
are not using
Asserts enabled build, but there could be some other reason as well.
I have marked this CF entry as "Waiting on Author".
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant
wrote:
>
> On 2019-Sep-08, Amit Kapila wrote:
>
> > On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada
> > wrote:
> > >
> > > Thanks. I hope the attached new patch fixes this issue.
> > *
&g
On Tue, Sep 10, 2019 at 8:03 AM Masahiko Sawada wrote:
>
> On Tue, Sep 10, 2019 at 10:21 AM Amit Kapila wrote:
> >
> > On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant
> > wrote:
> > > I think that other table AMs are not necessarily going to use
sizeof(ff));
+
+ fprintf(stderr, "creating %d partitions...\n", partitions);
+
+ for (int p = 1; p <= partitions; p++)
+ {
+ char query[256];
+
+ if (partition_method == PART_RANGE)
+ {
part_size can be defined inside "if (partition_method == PART_RANGE)"
as it is used here. In general, this part of the code can use some
comments.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
ing machinery. I don't think this is
limited to append-only tables, but
rather those are just the ones that are affected the most."?
This thread seems to be stalled for the reason that we don't have a
clear consensus on what is the right solution for the problem being
discussed. Alva
On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila wrote:
>
> The current example shows the usage of looping in plpgsql, so as such
> there is no correctness issue, but OTOH there is no harm in updating
> the example as proposed by Ian Barwick. Does anyone else see any
> problem with th
On Wed, Sep 11, 2019 at 11:40 AM Pavel Stehule wrote:
>
> st 11. 9. 2019 v 7:45 odesílatel Amit Kapila napsal:
>>
>> On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila wrote:
>> >
>> > The current example shows the usage of looping in plpgsql, so as such
>>
s are handled in the same way as heap
> pages are.
>
I haven't studied this patch in detail, but while glancing I observed
that this doesn't try to sync the vm pages as we do for heap pages in
the end (during end_heap_rewrite). Am I missing something?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
27;decode_combined'. It is
not clear from the name what it means and I think it doesn't even
match with what we are actually doing here. How about raw_flags,
raw_tuple_flags or something like that?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
ase we need to change
the version as well, but I might be wrong and maybe the parameter name
as committed is good enough in which case we should be good.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
>
> On Thu, Sep 12, 2019 at 05:34:08PM +0800, Masahiko Sawada wrote:
> > On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
> >> I think it is better to use a message like "must be superuser to use
> >
On Thu, Sep 5, 2019 at 7:53 PM Amit Kapila wrote:
>
> On Mon, Sep 2, 2019 at 4:51 PM Amit Kapila wrote:
> >
> > On Fri, Aug 9, 2019 at 6:29 PM Robert Haas wrote:
> > >
> > >
> > > But beyond that, the issue here is that the Limit node is shutting
On Fri, Sep 13, 2019 at 8:52 AM Masahiko Sawada wrote:
> On Tue, Sep 10, 2019 at 8:19 PM Amit Kapila wrote:
> >
> >
> > Generally speaking, having more guc's for autovacuum and that too
> > which are in some way dependent on existing guc's sounds bit scary,
On Fri, Sep 13, 2019 at 9:00 AM Michael Paquier wrote:
>
> On Thu, Sep 12, 2019 at 05:24:17PM +0530, Amit Kapila wrote:
> > On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
> > Hmm, I thought when decode_combined flag is set to false means we will
> > display the ra
serve by using left join?
> > *
> > +enum { PART_NONE, PART_RANGE, PART_HASH }
> > + partition_method = PART_NONE;
> > +
> >
> > I think it is better to follow the style of QueryMode enum by using
> > typedef here, that will make look code in sync with nearby code.
>
> Hmmm. Why not. This means inventing a used-once type name for
> partition_method. My great creativity lead to partition_method_t.
>
+partition_method_t partition_method = PART_NONE;
It is better to make this static.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
s is hidden
> in the display anyway.
>
Sure, but I feel the code will be simplified. I see no reason for
using left join here.
> > +partition_method_t partition_method = PART_NONE;
> >
> > It is better to make this static.
>
> I do agree, but this would depart from all other global variables around
> which are currently not static.
>
Check QueryMode.
> Maybe a separate patch could turn them all
> as static, but ISTM that this patch should not change the current style.
>
No need to change others, but we can do it for this one.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
>
Yeah, but I am not sure if we want to do display LOCK_UPGRADED stuff
in the compound column as that is not directly comparable to other
flags we want to display there like HEAP_XMIN_FROZEN,
HEAP_XMAX_SHR_LOCK.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Fri, Sep 13, 2019 at 10:42 AM Michael Paquier wrote:
>
> On Fri, Sep 13, 2019 at 09:59:40AM +0530, Amit Kapila wrote:
> > I think that is what we have not done in one of the cases pointed by me.
>
> Thinking more about it, I see your point now. HEAP_LOCKED_UPGRADED
On Fri, Sep 13, 2019 at 6:36 PM Alvaro Herrera wrote:
>
> On 2019-Sep-13, Amit Kapila wrote:
>
> > I would like to take inputs from others as well for the display part
> > of this patch. After this patch, for a simple-update pgbench test,
> > the changed outp
On Sat, Sep 14, 2019 at 10:10 AM Michael Paquier wrote:
>
> On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote:
> > On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera
> > wrote:
> >> A thought I had as I fell asleep last night is to include the derivate
>
nch scale 1 initialization with options');
Similar to the above, it is not clear to me why we need to change this?
*pgbench(
-
# given the expected rate and the 2 ms tx duration, at most one is executed
'-t 10 --rate=10 --latency-limit=1 -n -r',
0,
The above appears to be a spurious line change.
* I think we need to change the docs [1] to indicate the new step for
partitioning. See section --init-steps=init_steps
[1] - https://www.postgresql.org/docs/devel/pgbench.html
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
delta-pgbench-init-partitioned-7.patch
Description: Binary data
1101 - 1200 of 6827 matches
Mail list logo