On Wed, Mar 31, 2021 at 6:42 AM Ajin Cherian wrote:
>
> Updated.
>
I have slightly adjusted the comments, docs, and commit message. What
do you think about the attached?
--
With Regards,
Amit Kapila.
v4-0001-Ensure-to-send-a-prepare-after-we-detect-concurre.patch
Description: Binary data
On Wed, Mar 31, 2021 at 6:39 AM Peter Smith wrote:
>
> On Tue, Mar 30, 2021 at 8:14 PM Amit Kapila wrote:
> >
> > On Tue, Mar 30, 2021 at 2:21 PM Peter Smith wrote:
> > >
> > > Hi,
> > >
> > > The logical replication tablesync worker create
On Wed, Mar 31, 2021 at 9:47 AM Amit Kapila wrote:
>
> On Wed, Mar 31, 2021 at 9:35 AM Michael Paquier wrote:
> >
> > On Tue, Mar 30, 2021 at 05:00:53PM +0530, Amit Kapila wrote:
> > > Looks good to me as well but I think one can choose not to backpatch
> > >
On Wed, Mar 31, 2021 at 7:17 AM Euler Taveira wrote:
>
> On Tue, Mar 30, 2021, at 8:23 AM, Amit Kapila wrote:
>
> On Mon, Mar 29, 2021 at 6:47 PM Euler Taveira wrote:
> >
> Few comments:
> ==
> 1. How can we specify row filters for multiple tables for a
>
On Wed, Mar 31, 2021 at 11:55 AM Markus Wanner
wrote:
>
> On 31.03.21 06:39, Amit Kapila wrote:
> > I have slightly adjusted the comments, docs, and commit message. What
> > do you think about the attached?
>
> Thank you both, Amit and Ajin. This looks good to me.
on and do something
about empty prepare transactions to reduce the need for users to set a
much higher value for max_prepared_xacts on subscribers. So, I propose
to move it to the next CF, what do you think?
--
With Regards,
Amit Kapila.
On Wed, Mar 31, 2021 at 7:20 PM Markus Wanner
wrote:
>
> On 31.03.21 15:18, Amit Kapila wrote:
> > On Wed, Mar 31, 2021 at 11:55 AM Markus Wanner
> >> The last sentences there now seems to relate to just the setting of
> >> "concurrent_abort", ra
ated set of patches with these changes...
>
I have marked this as Returned with Feedback. There is a lot of work
to do for this patch as per the feedback given on pgsql-committers
[1].
[1] -
https://www.postgresql.org/message-id/E1lMiB9-0001c3-SY%40gemulon.postgresql.org
--
With Regards,
Amit Kapila.
really useful for
> replication
> scenarios. Supporting this feature means that you don't need to use a table to
> pass messages from one node to another one. Here are a few comments/ideas.
>
Your ideas/suggestions look good to me. Don't we need to provide a
read function corresponding to logicalrep_write_message? We have it
for other write functions. Can you please combine all of your changes
into one patch?
--
With Regards,
Amit Kapila.
te shutdown or server going down abruptly can occur or not with
> the shared stats patch.
>
I don't think it is easy to simulate a scenario where the 'drop'
message is dropped and I think that is why the test contains the step
to manually remove the slot. At this stage, you can probably provide a
test patch and a code-fix patch where it just drops the extra slots
from the stats file. That will allow us to test it with a shared
memory stats patch on which Andres and Horiguchi-San are working. If
we still continue to pursue with current approach then as Andres
suggested we might send additional information from
RestoreSlotFromDisk to keep it in sync.
--
With Regards,
Amit Kapila.
logical_decoding_work_mem.
> ---
>
> It can surely be used to allow tuning logical_decoding_work_mem but it
> could not be true for gauging the network I/O which occurred during
> logical decoding.
>
Agreed. I think we can adjust the wording accordingly.
--
With Regards,
Amit Kapila.
On Sat, Apr 3, 2021 at 5:26 AM Euler Taveira wrote:
>
> On Thu, Apr 1, 2021, at 7:19 AM, Amit Kapila wrote:
>
> This new patch set version has 2 patches that is because there are 2 separate
> changes: parse_output_parameters() refactor and logical decoding message
> support.
better to use the same for pgstat purposes as well. In
other words, I also agree with this decision and I see that Vignesh
has already used NameData for slot_name in his recent patch.
--
With Regards,
Amit Kapila.
to pg_logical_slot_get_changes if
we create table before creating the slots in this test.
0003
-
6. In the tests/code, publisher is used at multiple places. I think
that is not required because this can happen via plugin as well.
7.
+ if (max_replication_slots == nReplSlotStats)
+ {
+ ereport(pgStatRunningInCollector ? LOG : WARNING,
+ (errmsg("skipping \"%s\" replication slot statistics as
pg_stat_replication_slots does not have enough slots",
+ NameStr(replSlotStats[nReplSlotStats].slotname;
+ memset(&replSlotStats[nReplSlotStats], 0, sizeof(PgStat_ReplSlotStats));
Do we need memset here? Isn't this location is past the max location?
--
With Regards,
Amit Kapila.
On Mon, Apr 5, 2021 at 5:45 PM Euler Taveira wrote:
>
> On Mon, Apr 5, 2021, at 4:06 AM, Amit Kapila wrote:
>
> I have made few minor changes in the attached. (a) Initialize the
> streaming message callback API, (b) update docs to reflect that XID
> can be sent for stream
not introduced any bug in PG-14.
--
With Regards,
Amit Kapila.
both approaches for PG-13 are attached.
Thoughts?
[1] -
https://www.postgresql.org/message-id/CAH2-Wz%3Dgf6FXW-jPVRdeCZk0QjhduCqH_XD3QbES9wPmhircuA%40mail.gmail.com
--
With Regards,
Amit Kapila.
fix_access_strategy_workers_1.patch
Description: Binary data
fix_access_strategy_workers_11.
than I first suspected.
>
I have started a separate thread [1] to fix this in PG-13.
[1] -
https://www.postgresql.org/message-id/CAA4eK1KbmJgRV2W3BbzRnKUSrukN7SbqBBriC4RDB5KBhopkGQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
e needs to be added or any
> comments on this change.
>
Thanks, this mostly looks good to me. I have slightly modified it.
See, what do you think of the attached?
--
With Regards,
Amit Kapila.
v2-0001-doc-Update-information-of-new-messages-for-logica.patch
Description: Binary data
On Thu, Apr 8, 2021 at 3:49 AM Peter Smith wrote:
>
> On Wed, Apr 7, 2021 at 10:15 PM Amit Kapila wrote:
> >
> > On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
>
> 3.
> There is inconsistent wording for what seems to be the same condition.
> e.g.1 The existing
On Wed, Apr 7, 2021 at 7:12 PM Bharath Rupireddy
wrote:
>
> On Wed, Apr 7, 2021 at 3:30 PM Amit Kapila wrote:
> >
> > During recent developments in the vacuum, it has been noticed [1] that
> > parallel vacuum workers don't use any buffer access strategy. I thin
On Wed, Apr 7, 2021 at 5:11 PM Masahiko Sawada wrote:
>
> On Wed, Apr 7, 2021 at 7:00 PM Amit Kapila wrote:
> >
> > During recent developments in the vacuum, it has been noticed [1] that
> > parallel vacuum workers don't use any buffer access strategy. I thin
On Thu, Apr 8, 2021 at 8:52 AM Masahiko Sawada wrote:
>
> On Thu, Apr 8, 2021 at 12:17 PM Amit Kapila wrote:
> >
> > On Wed, Apr 7, 2021 at 5:11 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Apr 7, 2021 at 7:00 PM Amit Kapila
> > > wrote
On Thu, Apr 8, 2021 at 9:42 AM Bharath Rupireddy
wrote:
>
> On Thu, Apr 8, 2021 at 8:44 AM Amit Kapila wrote:
> >
> > On Wed, Apr 7, 2021 at 7:12 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Wed, Apr 7, 2021 at 3:30 PM Amit Kapila
> > > w
reading we
can allocate memory based on the required number of slots. Later when
startup process sends the slots, we can remove the already dropped
slots from this array. What do you think?
--
With Regards,
Amit Kapila.
orried about needing to check for interrupts, more
> work is needed.
>
>
> Sketch for a fix attached. I did leave the odd
> ConditionVariableTimedSleep(10ms) in, because I wasn't sure why it's
> there...
>
I haven't tested the patch but I couldn't spot any problems while
reading it. A minor point, don't we need to use
ConditionVariableCancelSleep() at some point after doing
ConditionVariableTimedSleep?
--
With Regards,
Amit Kapila.
t_report_queryid(queryDesc->plannedstmt->queryId, false);
Below lines down in ParallelQueryMain, we call ExecutorStart which
will report queryid, so do we need it here?
--
With Regards,
Amit Kapila.
rences too.
>
>
> Updated.
>
I don't like repeating the same thing for all new messages. So added
separate para for the same and few other changes. See what do you
think of the attached?
--
With Regards,
Amit Kapila.
v5-0001-doc-Update-information-of-new-messages-for-logica.patch
Description: Binary data
On Fri, Apr 9, 2021 at 9:58 AM Justin Pryzby wrote:
>
> On Wed, Apr 07, 2021 at 05:45:16PM +0530, Amit Kapila wrote:
> > On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
> > >
> > > Found that some documentation hasn't been updated for the changes made as
On Fri, Apr 9, 2021 at 12:33 PM Peter Smith wrote:
>
> On Mon, Dec 14, 2020 at 8:27 PM Amit Kapila wrote:
> >
> > 2.
> > + /*
> > + * Flags are determined from the state of the transaction. We know we
> > + * always get PREPARE first and then [COMMIT|RO
include-xids', '0', 'skip-empty-xacts', '1')");
+$node->safe_psql('postgres',
+"SELECT data FROM
pg_logical_slot_get_changes('regression_slot3', NULL, NULL,
'include-xids', '0', 'skip-empty-xacts', '1')");
The indentation of the second SELECT seems to bit off.
--
With Regards,
Amit Kapila.
On Fri, Apr 9, 2021 at 4:13 PM Amit Kapila wrote:
>
> 2.
> @@ -2051,6 +2054,17 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
> ReorderBufferTXN *txn,
> rb->begin(rb, txn);
> }
>
> + /*
> + * Update total transaction count and total transaction bytes, if
&g
On Sat, Apr 10, 2021 at 9:50 AM Amit Kapila wrote:
>
> On Fri, Apr 9, 2021 at 4:13 PM Amit Kapila wrote:
> >
> > 2.
> > @@ -2051,6 +2054,17 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
> > ReorderBufferTXN *txn,
> > rb->begin(rb, txn);
> > }
rop message is lost. To deal with this problem
> I think we would need to use something unique identifier for each slot
> instead of slot name.
>
Right, we can probably write it in comments and or docs about this
caveat and the user can probably use pg_stat_reset_replication_slot
for such slots.
--
With Regards,
Amit Kapila.
r m_total_bytes;
} PgStat_MsgReplSlot;
..
..
+ PgStat_Counter total_txns;
+ PgStat_Counter total_bytes;
TimestampTz stat_reset_timestamp;
} PgStat_ReplSlotStats;
Doesn't this change belong to the second patch?
--
With Regards,
Amit Kapila.
On Thu, Apr 8, 2021 at 12:37 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 8, 2021 at 11:22 AM Amit Kapila wrote:
> > Yeah, I will change that before commit unless there are more suggestions.
>
> I have no further comments on the patch
> fix_access_strategy_workers_11.patc
On Fri, Apr 9, 2021 at 9:39 AM Amit Kapila wrote:
>
>
> I don't like repeating the same thing for all new messages. So added
> separate para for the same and few other changes. See what do you
> think of the attached?
>
Pushed.
--
With Regards,
Amit Kapila.
ir views as this seems to be an
old problem (since the decoding of Truncate operation is introduced).
--
With Regards,
Amit Kapila.
On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada wrote:
>
> On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila wrote:
> >
> >
> > It seems Vignesh has changed patches based on the latest set of
> > comments so you might want to rebase.
>
> I've merged my patc
On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada wrote:
>
> On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote:
> >
> > On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada
> > wrote:
> > >
> > > On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila
> > >
WAL for this slot. This can be used to
+gauge the total amount of data sent during logical decoding.
Can we slightly extend it to say something like: Note that this
includes the bytes streamed and or spilled. Similarly, we can extend
it for total_txns.
--
With Regards,
Amit Kapila.
On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada wrote:
>
> On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila wrote:
> >
> > On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila
> > > w
) and above.
>
> I am definitely missing something. Perhaps I think I could not understand why
> there's no
> I/O difference between the Master and Patched (V2). Or has it been already
> improved
> even without this patch?
>
I don't think it is strange that you are not seeing much difference
because as per the initial email by Thomas this patch is not supposed
to give benefits on all systems. I think we wanted to check that the
patch should not regress performance in cases where it doesn't give
benefits. I think it might be okay to run with a higher number of
workers than you have CPUs in the system as we wanted to check if such
cases regress as shown by Soumyadeep above [1]. Can you once try with
8 and or 10 workers as well?
[1] -
https://www.postgresql.org/message-id/CADwEdoqirzK3H8bB%3DxyJ192EZCNwGfcCa_WJ5GHVM7Sv8oenuA%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
input data, as well as when there are no available splitted
chunks so it doesn't seem like a good idea to have the leader do other
work. This is backed by the performance data where we have seen that
with 1 worker there is just a 5-10% (or whatever percentage difference
you have seen) performance difference)".
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 21, 2020 at 3:08 PM k.jami...@fujitsu.com
wrote:
>
> On Tuesday, July 21, 2020 12:18 PM, Amit Kapila wrote:
> > On Tue, Jul 21, 2020 at 8:06 AM k.jami...@fujitsu.com
> >
> > wrote:
> > >
> > > I am definitely missing something. Perhap
combined_flags
FROM heap_page_items(get_raw_page('pg_class', 0)),
LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2)
WHERE t_infomask IS NOT NULL OR t_infomask2 IS NOT NULL;
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
oing the
same way in DecodeCommit where even though we skip adding
invalidations for fast-forward cases but we do set the flag to
indicate that this txn has catalog changes. Is there any reason to do
things differently here?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jul 22, 2020 at 5:25 AM David Rowley wrote:
>
> I understand that Amit wrote:
>
> On Fri, 17 Jul 2020 at 21:18, Amit Kapila wrote:
> > I think recreating the database and restarting the server after each
> > run might help in getting consistent results. Also, yo
On Wed, Jul 22, 2020 at 10:20 AM Dilip Kumar wrote:
>
> On Wed, Jul 22, 2020 at 9:18 AM Amit Kapila wrote:
> >
> > On Mon, Jul 20, 2020 at 6:46 PM Dilip Kumar wrote:
> > >
> > > There was one warning in release mode in the last version in 0
e cases - results are similar to that of non
> partitioned cases[1].
>
I could see the gain up to 10-11 times for non-partitioned cases [1], can
we use similar test case here as well (with one of the indexes on text
column or having gist index) to see its impact?
[1] -
https://www.postgresql.org/message-id/CALj2ACVR4WE98Per1H7ajosW8vafN16548O2UV8bG3p4D3XnPg%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
wned/created by B.I tool
and instead they use some Copy Unlogged sort of syntax provided by
other databases to load the data at a faster speed and now they expect
PG to also have a similar alternative. If that is true, then it is
possible that those database doesn't have 'Create Unlogged Table ...'
types of syntax which PG has and that is why they have provided such
an alternative for Copy kind of commands.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
h Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Wed, Jul 22, 2020 at 10:03 AM Thomas Munro wrote:
>
> On Wed, Jul 22, 2020 at 3:57 PM Amit Kapila wrote:
> > Yeah, that is true but every time before the test the same amount of
> > data should be present in shared buffers (or OS cache) if any which
> > will help in ge
On Fri, Jul 17, 2020 at 11:24 AM Amit Kapila wrote:
>
> Do you have something else in mind?
>
I am planning to commit the comments change patch attached in the
above email [1] next week sometime (probably Monday or Tuesday) unless
you have something more to add?
[1]
r) the patch as well but don't see any non-ASCII
characters. How can I verify that?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
am_start/start_stop are used to demarcate a
chunk of changes streamed for a particular toplevel transaction.
This commit simply adds these new APIs and the upcoming patch to
"allow the streaming mode in ReorderBuffer" will use these APIs.
--
With Regards,
Amit Kapila.
On Sat, Jul 25, 2020 at 8:42 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Jul 24, 2020 at 7:36 PM Tom Lane wrote:
> >> Yeah, the proposed comment changes don't actually add much. Also
> >> please try to avoid inserting non-ASCII into the source co
On Sun, Jul 26, 2020 at 4:54 PM Amit Kapila wrote:
>
> On Sat, Jul 25, 2020 at 8:42 PM Tom Lane wrote:
> >
>
> No, "git diff --check" doesn't help. I have tried pgindent but that
> also doesn't help neither was I expecting it to help. I am still not
o demarcate a
> > chunk of changes streamed for a particular toplevel transaction.
> >
> > This commit simply adds these new APIs and the upcoming patch to
> > "allow the streaming mode in ReorderBuffer" will use these APIs.
>
> LGTM
>
Pushed. Feel free to submit the remaining patches.
--
With Regards,
Amit Kapila.
therwise;
>
I am talking about the former case and I know that as per current
design it is not possible that two worker processes try to operate on
the same page but I was trying to be pessimistic so that we can ensure
that via some form of Assert. I don't know whether it is important to
mention this case or not but for the sake of extra safety, I have
mentioned it.
--
With Regards,
Amit Kapila.
they will be simply skipped.
Basically, it will try to stream such transactions and will skip them
as they are not required to be sent.
[1] -
https://www.postgresql.org/message-id/5f5143cc-9f73-3909-3ef7-d3895cc6cc90%40postgrespro.ru
--
With Regards,
Amit Kapila.
On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila wrote:
>
> On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> >
> > I still don't agree with this as proposed.
> >
> > + * For now, we don't allow parallel inserts of any form not even where the
>
* streamed.
/speculative then/speculative insert then
4. I think we can explain the problems (like we can see the wrong
tuple or see two versions of the same tuple or whatever else wrong can
happen, if possible with some example) related to concurrent aborts
somewhere in comments.
--
With Regards,
Amit Kapila.
On Tue, Aug 4, 2020 at 12:42 PM Dilip Kumar wrote:
>
> On Tue, Aug 4, 2020 at 10:12 AM Amit Kapila wrote:
> >
>
> > 4. I think we can explain the problems (like we can see the wrong
> > tuple or see two versions of the same tuple or whatever else wrong can
> &
n to ensure that the
current phase is VACUUM_ERRCB_PHASE_SCAN_HEAP.
--
With Regards,
Amit Kapila.
;invalid index offnum: %u", offnum);
..
}
hash_desc
{
..
case XLOG_HASH_INSERT:
{
xl_hash_insert *xlrec = (xl_hash_insert *) rec;
appendStringInfo(buf, "off %u", xlrec->offnum);
break;
}
Similarly in other desc functions, we have used off or offnum.
I find the message in your initial patch better.
--
With Regards,
Amit Kapila.
On Thu, Aug 6, 2020 at 7:51 PM Justin Pryzby wrote:
>
> On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> > On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby wrote:
> > >
> > >
> > > lazy_check_needs_freeze iterates over blocks and this patch cha
ed_buffers, the flag
> would be updated.
> We could do it during recovery, then release it as recovery completes.
>
> I haven't looked deeply yet into the source code but we maybe can modify the
> REDO
> (main redo do-while loop) in StartupXLOG() once the read-only connections are
> consistent.
> It would also be beneficial to construct this local hash when
> DropRefFileNodeBuffers()
> is called for the first time, so the whole share buffers is scanned
> initially, then as
> you mentioned subsequent dropping will be fast. (similar behavior to what the
> patch does)
>
> Do you think this is feasible to be implemented? Or should we explore another
> approach?
>
I think we should try what Andres is suggesting as that seems like a
promising idea and can address most of the common problems in this
area but if you feel otherwise, then do let us know.
--
With Regards,
Amit Kapila.
directly call BufTableLookup (similar to how we
do in BufferAlloc) to find the buf_id in function
DropRelFileNodeBuffers and then invalidate the required buffers. And,
we need to do this when the size of the relation is less than some
threshold. So, I think the crux would be to reliably get the number of
blocks information. So, probably relation size cache stuff might help.
--
With Regards,
Amit Kapila.
nvalidate
all the buffers? Basically, I think we need to perform BufTableLookup
for all the blocks in the relation and then Invalidate all buffers.
--
With Regards,
Amit Kapila.
On Fri, Aug 7, 2020 at 8:10 AM Masahiko Sawada
wrote:
>
> On Fri, 7 Aug 2020 at 10:49, Amit Kapila wrote:
> >
> > On Thu, Aug 6, 2020 at 7:51 PM Justin Pryzby wrote:
> > >
> > > On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> > > &g
On Fri, Aug 7, 2020 at 9:33 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Aug 1, 2020 at 1:53 AM Andres Freund wrote:
> >> We could also just use pg_class.relpages. It'll probably mostly be
> >> accurate enough?
>
> > Don't we n
has other merits
which are that such buffers might get invalidated faster but not sure
we can retain the benefit of another approach which is to perform all
such invalidation of buffers before unlinking the relation's first
segment.
--
With Regards,
Amit Kapila.
On Thu, Aug 13, 2020 at 12:08 PM Amit Kapila wrote:
>
> On Fri, Aug 7, 2020 at 2:04 PM Dilip Kumar wrote:
> >
> > On Thu, Aug 6, 2020 at 2:43 PM Amit Kapila wrote:
> > >
> ..
> > > This patch's functionality can be independently verified by S
On Fri, Aug 14, 2020 at 10:11 AM Thomas Munro wrote:
>
> On Thu, Aug 13, 2020 at 6:38 PM Amit Kapila wrote:
> > I have pushed that patch last week and attached are the remaining
> > patches. I have made a few changes in the next patch
> > 0001-Extend-the-BufFile-inter
ixed all the comments raised by me in the attached patch. One thing
we need to think is do we want to set offset during heap_page_prune
when called from lazy_scan_heap? I think the code path for
heap_prune_chain is quite deep, so an error can occur in that path.
What do you think?
--
With Regar
On Fri, Aug 7, 2020 at 7:18 AM Amit Kapila wrote:
>
> On Thu, Aug 6, 2020 at 7:51 PM Justin Pryzby wrote:
> >
> > On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> > > On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby
> > > wrote:
> > &
On Thu, Aug 6, 2020 at 7:41 PM Amit Kapila wrote:
>
> On Wed, Aug 5, 2020 at 12:47 AM Mahendra Singh Thalor
> wrote:
> >
> > Apart from these, I fixed Justin's comment of extra brackets(That was
> > due to "patch -p 1 < file", as 002_fix was not
On Fri, Aug 14, 2020 at 4:06 PM Amit Kapila wrote:
>
> On Mon, Aug 10, 2020 at 10:24 AM Masahiko Sawada
> wrote:
> >
> > It's true that heap_page_is_all_visible() is called from only
> > lazy_vacuum_page() but I'm concerned it would lead misleading since
>
t;). If we want we can maintain all the required
versions of pg_bsd_indent but as of now, I am not doing so and thought
that following some approximation rule (do it for HEAD and try my best
to maintain the layout for back-branches) is good enough.
[1] - https://www.postgresql.org/message-id/397020.1597291716%40sss.pgh.pa.us
--
With Regards,
Amit Kapila.
On Sat, Aug 15, 2020 at 4:14 AM Thomas Munro wrote:
>
> On Fri, Aug 14, 2020 at 6:14 PM Amit Kapila wrote:
> > Yeah, that makes sense. I will take care of that later today or
> > tomorrow. We have not noticed that because currently none of the
> > extensions is using
nd handled it even without the flag reminding about it. Fixing
> it in master ought to be enough.
>
+1 for doing it in master only. Even if someone comes up with such a
scenario for back-branches, we can revisit our decision to backport
this but like you, I also don't see any pressing need to do it now.
--
With Regards,
Amit Kapila.
On Mon, Aug 17, 2020 at 11:38 AM Masahiko Sawada
wrote:
>
> On Sat, 15 Aug 2020 at 12:19, Amit Kapila wrote:
> >
> > The reason why I have not included heap_page_prune related change in
> > the patch is that I don't want to sprinkle this in every possible
> &
On Fri, Aug 7, 2020 at 9:33 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Aug 1, 2020 at 1:53 AM Andres Freund wrote:
> >> We could also just use pg_class.relpages. It'll probably mostly be
> >> accurate enough?
>
> > Don't we n
On Tue, Aug 18, 2020 at 1:37 PM Bharath Rupireddy
wrote:
>
> On Tue, Jul 14, 2020 at 1:20 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila wrote:
> >
> > > I think we can do more than this by
> > > parallelizing the Insert pa
t that
point of time. It will work for your use case (where while removing
buffile you also want to remove the entire fileset) but not sure if it
is generic enough. For your case, I wonder if we can directly call
SharedFileSetDeleteAll and we can have a call like
SharedFileSetUnregister which will be called from it.
--
With Regards,
Amit Kapila.
On Wed, Aug 19, 2020 at 10:10 AM Amit Kapila wrote:
>
> On Mon, Aug 17, 2020 at 6:29 PM Dilip Kumar wrote:
> >
> >
> > In last patch v49-0001, there is one issue, Basically, I have called
> > BufFileFlush in all the cases. But, ideally, we can not call this i
On Wed, Aug 19, 2020 at 12:54 PM Masahiko Sawada
wrote:
>
> On Tue, 18 Aug 2020 at 13:06, Amit Kapila wrote:
> >
> >
> > I don't think we need to expose LVRelStats. We can just pass the
> > address of vacrelstats->offset_num to achieve what we want. I hav
On Thu, Aug 20, 2020 at 12:18 PM Masahiko Sawada
wrote:
>
> On Thu, 20 Aug 2020 at 14:01, Amit Kapila wrote:
> >
> > On Wed, Aug 19, 2020 at 12:54 PM Masahiko Sawada
> > wrote:
> >
> > Here, we can notice that for the index, we are getting context
>
On Thu, Aug 20, 2020 at 1:41 PM Dilip Kumar wrote:
>
> On Wed, Aug 19, 2020 at 1:35 PM Dilip Kumar wrote:
> >
> > On Wed, Aug 19, 2020 at 12:20 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Aug 19, 2020 at 10:10 AM Amit Kapila
> > > wro
On Thu, Aug 20, 2020 at 12:32 PM Amit Kapila wrote:
>
> On Thu, Aug 20, 2020 at 12:18 PM Masahiko Sawada
> wrote:
> >
> > On Thu, 20 Aug 2020 at 14:01, Amit Kapila wrote:
> > >
> > > On Wed, Aug 19, 2020 at 12:54 PM Masahiko Sawada
> > > wro
On Thu, Aug 20, 2020 at 5:42 PM Dilip Kumar wrote:
>
> On Thu, Aug 20, 2020 at 2:30 PM Amit Kapila wrote:
> >
> >
> > Right, I think this can happen if one has changed those by BufFileSeek
> > before doing truncate. We should fix that case as well.
>
> Right.
On Fri, Aug 21, 2020 at 9:14 AM Amit Kapila wrote:
>
> On Thu, Aug 20, 2020 at 5:42 PM Dilip Kumar wrote:
> >
> > On Thu, Aug 20, 2020 at 2:30 PM Amit Kapila wrote:
> > >
> > >
> > > Right, I think this can happen if one has changed those by BufFi
On Fri, Aug 21, 2020 at 9:14 AM Amit Kapila wrote:
>
> On Thu, Aug 20, 2020 at 5:42 PM Dilip Kumar wrote:
> >
> > On Thu, Aug 20, 2020 at 2:30 PM Amit Kapila wrote:
> > >
> > >
> > > Right, I think this can happen if one has changed those by BufFi
ing the shared BufFiles instead of always opening in
read-only mode. These enhancements in BufFile interface are required
for the upcoming patch to allow the replication apply worker, to
properly handle streamed in-progress transactions."
--
With Regards,
Amit Kapila.
f shread_buffers, (b) create an _init fork of such a
relation in-sync with the commit. You might want to read the archives
to see why at the first place we have decided to re-write the table
for SET UNLOGGED operation, see email [1].
[1] -
https://www.postgresql.org/message-id/CAFcNs%2Bpeg3VPG2%3Dv6Lu3vfCDP8mt7cs6-RMMXxjxWNLREgSRVQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
eDecodingTransactionId() and then those always seem to get
advanced. And GetOldestSafeDecodingTransactionId() takes into account
the already stored shared values of replication_slot_xmin and
replication_slot_catalog_xmin for computing the xmin_horizon for slot.
--
With Regards,
Amit Kapila.
On Fri, Aug 21, 2020 at 12:31 PM Masahiko Sawada
wrote:
>
> On Thu, 20 Aug 2020 at 21:12, Amit Kapila wrote:
> >
> >
> > Attached are both the patches. The first one is to improve existing
> > error context information, so I think we should back-patch to 13
On Sat, Aug 22, 2020 at 8:33 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Thu, Aug 20, 2020 at 10:28 PM Tom Lane wrote:
> >> 2. On the other hand, the code is *releasing* the
> >> ReplicationSlotControlLock before it calls
> >> ProcArraySetReplicat
On Mon, Aug 24, 2020 at 9:41 PM Dilip Kumar wrote:
>
> On Sat, Aug 22, 2020 at 8:38 AM Amit Kapila wrote:
> >
> > On Fri, Aug 21, 2020 at 5:10 PM Dilip Kumar wrote:
> > >
> > > I have reviewed and tested the patch and the changes look fine to me.
> > &g
801 - 900 of 6720 matches
Mail list logo
