FROM (SELECT -2::bigint /* 0x/FFFE
> */ AS my_bigint_lsn) AS stat(my_int64);
Thanks for sharing. It works. I will include this in the next patch.
On Sat, Feb 19, 2022 at 11:02 AM Julien Rouhaud wrote:
>
> Hi,
>
> On Fri, Feb 18, 2022 at 08:07:0
o support this. I am planning to take care
in the next patch.
---
> If pg_is_in_recovery() is true, then it's a restartpoint, otherwise it's a
> restartpoint if the checkpoint's timeline is different from the current
> timeline?
Fixed.
Sharing the v2 patch. Kindly ha
gt; + else
> + checkpoint_progress_update_param(flags,
> PROGRESS_CHECKPOINT_KIND,
> +
> PROGRESS_CHECKPOINT_KIND_UNKNOWN);
> + }
> +}
>
> --
> With Regards,
> Ashutosh Sharma.
>
> On Thu, Feb 10, 2022 at 12:23 PM Nitin Jadhav
>
increases the
code readability than calling it separately in all the scenarios. I am
planning to include log based reporting in the next patch. Even after
that if using the same function is not recommended, I am happy to
change.
Thanks & Regards,
Nitin Jadhav
On Wed, Feb 23, 2022 at 12:13
ch will make it correct. My
opinion about maintaining a separate field to show upcoming checkpoint
flags is it makes the view complex. Please share your thoughts.
Thanks & Regards,
On Thu, Feb 24, 2022 at 10:45 PM Matthias van de Meent
wrote:
>
> On Wed, 23 Feb 2022 at 14:28, Nitin Jadh
ling pgstat progress reporting when in bootstrap processing mode
> / startup/end-of-recovery makes very little sense (see upthread) and
> should be removed, regardless of whether seperate functions stay.
Removed since log based reporting is not part of the current patch.
> > diff --git a/
, val);
> + }
>
> Any specific reason for recording the timelineID in checkpoint stats
> table? Will this ever change in our case?
The timelineID is used to decide whether the current operation is
checkpoint or restartpoint. There is a field in the view to display
this in
!ImmediateCheckpointRequested() &&
>IsCheckpointOnSchedule(progress))
I understand that the checkpointer considers flags as well as the
shmem flags and if CHECKPOINT_IMMEDIATE flag is set, it affects the
current checkpoint operation (No further delay) but does no
684800 +
(S.param4::float / 100)) AS start_time' works fine. The value
'946684800' is equal to ((POSTGRES_EPOCH_JDATE - UNIX_EPOCH_JDATE) *
SECS_PER_DAY). I am not sure whether it is good practice to use this
way. Kindly share your thoughts.
Thanks & Regards,
Nitin Jadha
#x27; structure.
Please share your thoughts.
If required, I would like to work on the patch.
Thanks & Regards,
Nitin Jadhav
er once the
> > pg_stat_progress_checkpoint view gets in.
>
> I don't think that's really necessary to give the pid list.
>
> If you requested a new checkpoint, it doesn't matter if it's only your backend
> that triggered it, another backend or a few other d
feel we should support this. Thoughts?
Please find the patch attached.
Thanks & Regards,
Nitin Jadhav
v1-0001-add-checkpoint_requested-flag-to-the-log-message.patch
Description: Binary data
st_lsn
:s/pg_get_first_and_last_valid_wal_record_lsn/pg_wal_first_and_last_lsn
:s/pg_get_wal_record_info/pg_wal_record_info
:s/pg_get_wal_stats/pg_wal_stats
5) Even 'pg_get_wal_stats' and 'pg_get_wal_stats_till_end_of_wal' can
be clubbed as one function.
The above comments are
thing it's still only showing the initial
> checkpoint flags, so it's *not* showing what the checkpoint is really
> doing, only what the checkpoint may be doing if nothing else happens.
> It just feels wrong. You could even use that ckpt_flags info to know
> that at least one
ing like the
> backend that requested checkpoint will wait until it's completion
> + Wait for completion before returning.
>
> 13) "removing unneeded or flushing needed logical rewrite mapping files"
> + The checkpointer process is currently removing/flu
ted so that we can match the
behaviour with checkpoint end message? Please share your thoughts.
---
> I think we can add a couple of more information to this view -
> start_time for buffer write operation and start_time for buffer sync
> operation. These are two very time consuming tasks
ause some operation (for which the checkpoint is necessary) is
forced the checkpoint".
Fixed other comments as per the discussion above.
Please find the v5 patch attached and share your thoughts.
Thanks & Regards,
Nitin Jadhav
On Mon, Mar 7, 2022 at 7:45 P
comments.
>
> I will update in the next patch.
The current format matches with the server log message for the
checkpoint start in LogCheckpointStart(). Just to be consistent, I
have not changed the code.
I have taken care of the rest of the comments in v5 patch for which
there was clarit
current checkpoint behaviour gets affected by only
CHECKPOINT_IMMEDIATE flag and all other checkpoint requests done in
case of createdb(), dropdb(), etc gets called with
CHECKPOINT_IMMEDIATE flag. I have updated this in the v5 patch. Please
share your thoughts.
Thanks & Regards,
Nitin Jadhav
On Thu, Mar
' END ||
CASE WHEN (S.param2 & 128) > 0 AND (S.param2 & -256) > 0
THEN ', ' ELSE '' END ||
CASE WHEN (S.param2 & 256) > 0 THEN 'time' ELSE '' END
|| '}'
Basically, a separate CASE statement is used t
been explicitly requested, the user may
not understand that it affects current checkpoint behaviour unless the
user knows the internals of the checkpoint. How about naming the field
to 'throttled' (Yes/ No) since our objective is to show that the
current checkpoint is throttled or not.
Th
Hi,
I have observed that the table naming conventions used in
'progress-reporting.html' are not consistent across different
sections. For some cases "Phases" (Table 28.37. CREATE INDEX Phases)
is used and for some cases "phases" (Table 28.35. ANALYZE phases) is
used. I have attached a patch to cor
escribed by the 'flags' field and there
is no new request, then the value of this field is 'Yes' (Not
throttling) which again confuses the user.
'new request' - The value will be set to Yes/No if any new checkpoint
requests. This just indicates whether new requests have
the current checkpoint
starts with a different set of flags and when there is a new request
(with CHECKPOINT_IMMEDIATE), it just processes the pending operations
quickly to take up next requests. If we update this information in the
'flags' field of the view, it says that the current checkpoint
th that, so it appears correct
> to me.
>
> Therefore, I have committed it.
Thank you so much.
Thanks & Regards,
Nitin Jadhav
On Tue, Mar 15, 2022 at 2:22 AM Robert Haas wrote:
>
> On Fri, Jul 9, 2021 at 10:44 AM Tomas Vondra
> wrote:
> > Yeah, does not seem to be w
so much to display "how the checkpoint
> was initially started" rather than "how the checkpoint is really behaving
> right
> now". The whole point of having a progress view is to have something dynamic
> that reflects the current activity.
As of now
_walinspect.c:415:16: error: ‘XLogReaderState’ {aka ‘struct
XLogReaderState’} has no member named ‘blocks’
415 | record->blocks[block_id].hole_length);
|^~
make: *** [../../src/Makefile.global:941: pg_walinspect.o] Error 1
Thanks & Regards,
Nitin Jadhav
On Th
terminal while keeping
> the behavior consistent with other platforms, people would have no
> objections to that.
I feel the patch attached above handles this scenario.
Thanks and Regards,
Nitin Jadhav
On Tue, Mar 2, 2021 at 6:53 AM Michael Paquier wrote:
> On Tue, Mar 02, 2021 at 01:28:
Hi,
I have reviewed the patch and it looks good to me.
Thanks and Regards,
Nitin Jadhav
On Wed, Mar 3, 2021 at 1:09 PM Fujii Masao
wrote:
>
>
> On 2021/03/03 12:27, miyake_kouta wrote:
> > 2021-03-03 00:09, Fujii Masao wrote:
> >> We can simplify the code more and rem
eturn MyBEEntry->st_queryid;
+}
Is it safe to directly read the data from MyBEEntry without
calling pgstat_begin_read_activity() and pgstat_end_read_activity(). Kindly
ref pgstat_get_backend_current_activity() for more information. Kindly let
me know if I am wrong.
Thanks and Regards,
Nitin Jadhav
rrent write, as it will be
> from the same backend that originally wrote it. It avoids some overhead to
> retrieve the queryid, but if people think it's worth having the loop (or a
> comment explaining why there's no loop) I'm also fine with it.
Thanks for the explanation. Please
>
> On Tue, Apr 06, 2021 at 11:41:52AM -0400, Alvaro Herrera wrote:
> > On 2021-Apr-06, Nitin Jadhav wrote:
> >
> > > I have reviewed the code. Here are a few minor comments.
> > >
> > > 1.
> > > +void
> > > +pgstat_repor
!plainText' if block.
4.
static int binary_upgrade = 0;
static int column_inserts = 0;
+static int create_only = 0;
static int disable_dollar_quoting = 0;
The variable 'create_only' should be changed to 'createdb_only' to match
with
similar variable used in pg
for this since
StartupXLOG() gets called during the startup process, bootstrap
process or standalone backend. As per earlier discussion we need
support for this in the case of startup process and standalone
backend. Hence guarded this with '!IsBootstrapProcessingMode()'. Also
verified the behavio
new one) but the flag
is already set to true by the previous timer. Hence the next call to
ereport_startup_progress() logs a message. So I feel just setting
'startup_progress_timer_expired' to false in
begin_startup_progress_phase() would work. Please correct me if I am
wrong.
Thanks & Regards,
Nitin Jadh
7;t see
> how to avoid the race condition otherwise.
Right. There is a possibility of race conditions. In that case the
above changes look good to me.
Thanks & Regards,
Nitin Jadhav
On Fri, Oct 29, 2021 at 6:10 PM Robert Haas wrote:
>
> On Fri, Oct 29, 20
> I noticed that there's no commitfest entry for this. Will you please
> add this to the next one?
I have added it to Nov commitfest.
Thanks & Regards,
Nitin Jadhav
On Fri, Oct 29, 2021 at 1:40 PM Amit Langote wrote:
>
> Hi Nitin,
>
> On Fri, Oct 22, 2021 at 6:
GB
wal_writer_delay=1ms
./pgbench --initialize --scale=300 postgres
WAL buffers hit=37214
WAL buffers miss=844
Please share your thoughts.
Thanks & Regards,
Nitin Jadhav
On Tue, Mar 7, 2023 at 12:39 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 7, 2023 at 3:30 AM Nathan Bos
The patch looks good to me.
Thanks & Regards,
Nitin Jadhav
On Fri, Dec 2, 2022 at 11:20 AM Bharath Rupireddy
wrote:
>
> On Wed, Nov 30, 2022 at 5:15 PM Bharath Rupireddy
> wrote:
> >
> > I don't have a strong opinion about changing column names. However, if
>
same. Please share your thoughts.
Thanks & Regards,
Nitin Jadhav
v1-0001-Fix-inconsistency-in-checkpointer-stats.patch
Description: Binary data
is
before the end of the checkpoint. Please share if you have any other
ideas.
On Wed, Dec 14, 2022 at 4:55 PM Bharath Rupireddy
wrote:
>
> On Wed, Dec 14, 2022 at 1:02 PM Nitin Jadhav
> wrote:
> >
> > Hi,
> >
> > While working on checkpoint related stuff, I
fdata, aka outside the context of a checkpoint or
> shutdown sequence.
Sorry. I missed adding braces. Fixed in the v2 patch attached.
Thanks & Regards,
Nitin Jadhav
On Thu, Dec 15, 2022 at 3:16 AM Michael Paquier wrote:
>
> On Wed, Dec 14, 2022 at 04:54:53PM +0530, Bhar
ist ProcessSyncRequests() up into CheckPointGuts() to make it clearer
that it applies to all the SLRU mini-buffer-pools as well as the main
buffer pool. Rearrange things so that data collected in CheckpointStats
includes SLRU activity.
Thanks & Regards,
Nitin Jadhav
On Tue, Dec 20, 2022 at 2:38
; write=0.045 s, sync=0.161 s, total=0.244
s; sync files=25, longest=0.146 s, average=0.007 s; distance=66130 kB,
estimate=66130 kB; lsn=0/5557C78, redo lsn=0/5557C40
Thanks & Regards,
Nitin Jadhav
On Tue, Dec 20, 2022 at 11:08 PM Andres Freund wrote:
>
> On 2022-12-20 08:18:36 -0500, R
mmon to table/index stats?
+1 to keep common functions/code between table and index stats. Only
the data structure should be different as the goal is to shrink the
current memory usage.
Thanks & Regards,
Nitin Jadhav
On Thu, Jan 5, 2023 at 3:35 PM Drouvot, Bertrand
wrote:
>
> Hi,
&g
work on the patch if a fix is required.
[1]:
SELECT name FROM pg_settings WHERE NOT 'NOT_IN_SAMPLE' = ANY
(pg_settings_get_flags(name)) AND name <> 'config_file' ORDER BY 1;
Thanks & Regards,
Nitin Jadhav
;all_params_array' in 003_check_guc.pl whenever we add such GUCs.
I am not able to choose any of the above options as each has some
disadvantages but if no other options exist, then I would like to go
with option-3 as it validates more than the one currently doing.
Please share if any other b
TTINGS)) ||
((conf->flags & GUC_SUPERUSER_ONLY) &&
!has_privs_of_role(GetUserId(), ROLE_PG_READ_ALL_SETTINGS)))
*noshow = true;
else
*noshow = false;
}
-
-
-
}
On Mon, Jan 16, 2023 at 7:58 AM Michael Paquier wrote:
>
> On S
w. So a return statement in GetConfigOptionValues() when
noshow is set to true is needed. Attached the patch for the same.
Please share your thoughts.
Thanks & Regards,
Nitin Jadhav
Attaching the patch.
On Wed, Jan 18, 2023 at 1:21 PM Nitin Jadhav
wrote:
>
> Hi,
>
> GetConfigOptionValues function extracts the config parameters for the
> given variable irrespective of whether it results in noshow or not.
> But the parent function show_all_settings
the number of such parameters (GUC_NO_SHOW_ALL and
GUC_SUPERUSER_ONLY) are less, we may not see improvements in
performance. We can treat it as a kind of refactoring.
Thanks & Regards,
Nitin Jadhav
On Wed, Jan 18, 2023 at 1:47 PM Bharath Rupireddy
wrote:
>
> On Wed, Jan 18, 2023
hed a patch for the same. Please share the
comments if any.
Thanks & Regards,
Nitin Jadhav
On Wed, Jan 18, 2023 at 9:44 PM Tom Lane wrote:
>
> Nitin Jadhav writes:
> > GetConfigOptionValues function extracts the config parameters for the
> > given variable irrespective of wh
the sync
> progress locally, and we may need some refactoring here.
I agree to provide above mentioned information as part of showing the
progress of current checkpoint operation. I am currently looking into
the code to know if any other information can be added.
Thanks & Regards,
Nitin Jadhav
On
uring shutdown and end-of-recovery
cases as we cannot access pg_stat_progress_checkpoint in those cases.
I am working on this to use log_startup_progress_interval mechanism to
log the progress in the server logs.
Kindly review the patch and share your thoughts.
On Fri, Jan 28, 2022 at 12:24 PM Bharath Rupired
this. If there are any changes to the existing mechanism to
make it generic to support basic data types, I would like to discuss
this in the new thread.
On Thu, Feb 10, 2022 at 12:22 PM Nitin Jadhav
wrote:
>
> > > We need at least a trace of the number of buffers to sync (num_to_scan)
>
r the additional information. I feel the information related to
the pending shutdown request should also be added.
Thanks & Regards,
Nitin Jadhav
On Thu, Feb 10, 2022 at 5:32 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> Given that CheckpointWriteDelay() is really a hot code path i.e.
; which takes int64 (not
Timestamptz) as argument and then returns string representing the
elapsed time. This function can be called in the view. Is it
safe/advisable to use int64 type here rather than Timestamptz for this
purpose? 'checkpoint start location' (lsn = uint64) - I feel we
cannot
> pg_is_in_recovery()?
AFAIK we cannot use pg_is_in_recovery() to predict whether it is a
checkpoint or restartpoint because if the system exits from recovery
mode during restartpoint then any query to pg_stat_progress_checkpoint
view will return it as a checkpoint which is ideally not correct.
rted due to the expiration of a
> >checkpoint_timeout< interval
"The checkpoint is started because checkpoint_timeout expired".
> > + The checkpoint operation is forced even if no XLOG activity has
> > occurred
> > + since the last one.
>
> + Some operation fo
syncing files may complete before
pg_is_in_recovery() returns false. But there are some cleanup
operations happen as part of the checkpoint. During this scenario, we
may get false value for pg_is_in_recovery(). Please refer following
piece of code which is present in CreateRestartpoint().
if (!Re
ther then then kind of checkpoint?
> You should still be able to compute the information while giving a bit more
> information for the same memory usage.
Can you please describe more about how checkpoint/restartpoint can be
confirmed using the timeline id.
Thanks & Regards,
Nit
message, we should increment all three here,
buffers_total, buffers_processed and buffers_written. So the total
number of buffers calculated earlier may not always be the same. If
this looks good, I will update this in the next patch.
Thanks & Regards,
Nitin Jadhav
On Fri, Nov 4, 2022 at
can be done directly while declaring the variable.
Thanks & Regards,
Nitin Jadhav
On Wed, Mar 3, 2021 at 1:56 AM Justin Pryzby wrote:
> https://commitfest.postgresql.org/32/2694/
>
> I don't know what committers will say, but I think that "ALTER TABLE"
> might be
&g
am working on it.
1. Handling of 'NULL' values.
2. Support multi column case in partition pruning.
3. Add test cases to the regression test suite.
Please share your thoughts.
Thanks & Regards,
Nitin Jadhav
v0_multi_column_list_partitioning.patch
Description: Binary data
So, In case of insertion of row (300, 50). Based on the understanding,
partition 'r3' should have rejected it.
Kindly confirm whether the above is expected or not. If expected, kindly
explain.
Thanks and Regards,
Nitin Jadhav
is correct.
So in the above scenarios, users cannot create a partition for column 'a'
values
from (0) to (100). If user tries insert any values for column 'a' between
'0' to '100',
either it should go to default partition if exists. Otherwise it should
fail sayin
ve. For example
for a partition
with 2 partition keys (a,b) for values like (1,1), (1,2), (1,3),
(1,4),(1,5). This
would be converted to (1,1,1,1,1), (1,2,3,4,5). It is difficult to match
the values
of column 'a' to 'b'. Anyways let's wait for the other's opinion abou
Hi,
The file path mentioned in the file comments of
'src/backend/utils/activity/backend_status.c'
was incorrect. Modified it to the correct path. Please find the patch
attached.
Thanks & Regards,
Nitin Jadhav
v1_0001-fix_file_path_in_comments.patch
Description: Binary data
't
> overlap with existing partitions' ranges; the following will work for
> example:
>
> create table r3 partition of r for values from (0,100) to (100,0);
Thanks for the clarification.
Thanks & Regards,
Nitin Jadhav
On Wed, May 12, 2021 at 5:41 PM Amit Langote
wrote
n it contains NULL values. Otherwise no change) but it improves in case
of
memory allocations. As memory allocations are costly operations, I feel we
should
consider changing the existing code.
Please share your thoughts.
[1] -
https://mail.google.com/mail/u/2/#search/multi+column+list/KtbxLxgZZTjRxNrBWvmHzDTHXCHLssSprg?compose=CllgCHrjDqKgWCBNMmLqhzKhmrvHhSRlRVZxPCVcLkLmFQwrccpTpqLNgbWqKkTkTFCHMtZjWnV
Thanks & Regards,
Nitin Jadhav
v1_remove_extra_mem_alloc_from_list_bounds.patch
Description: Binary data
IST
(1 row)
postgres@123613=#select to_char(current_timestamp, 'HH');
to_char
-
08
(1 row)
postgres@123613=#select to_char(current_timestamp, 'hh');
to_char
-
08
(1 row)
Thanks & Regards,
Nitin Jadhav
e with Oracle and required for the datetime template
language for jsonpath in an upcoming patch.
Nikita Glukhov and Andrew Dunstan, reviewed by Pavel Stehule.
Thanks & Regards,
Nitin Jadhav
On Sun, May 16, 2021 at 8:40 PM Tom Lane wrote:
>
> Nitin Jadhav writes:
> > While u
if any changes are required.
Thanks & Regards,
Nitin Jadhav
On Sun, May 16, 2021 at 10:34 PM Tom Lane wrote:
>
> Nitin Jadhav writes:
> > Thanks for the explanation. I also feel that we may not support every
> > case-variant. But the other reason which triggered me to think
> Please add it to the July commitfest: https://commitfest.postgresql.org/33/
Added a commitfest entry https://commitfest.postgresql.org/33/3121/
Thanks & Regards,
Nitin Jadhav
On Mon, May 17, 2021 at 7:05 AM David Rowley wrote:
>
> On Mon, 17 May 2021 at 06:23, Nitin Ja
dSpec **boundspecs, int nparts,
PartitionKey key, int **mapping)
{
int i;
Assert(nparts > 0);
Thanks & Regards,
Nitin Jadhav
On Sun, May 16, 2021 at 10:52 PM Zhihong Yu wrote:
>
>
>
> On Sun, May 16, 2021 at 10:00 AM Justin Pryz
top of
'v2_0001-removed_extra_mem_alloc_from_create_list_bounds.patch'.
Attaching all the patches here.
--
Thanks & Regards,
Nitin Jadhav
On Mon, May 17, 2021 at 8:33 PM Justin Pryzby wrote:
>
> On Mon, May 17, 2021 at 08:22:25PM +0530, Nitin Jadhav wrote:
> > I agree and t
memory
available, we may see 'out of memory' errors without the patch but it
may work with the patch. I have not done experiments in this angle. I
am happy to do it if required.
Please share your thoughts.
--
Thanks & Regards,
Nitin Jadhav
On Tue, May 18, 2021 at 11:19 PM Robert
> Created a table with one column of type 'int' and partitioned by that
> column. Created 1 million partitions using following queries.
Sorry. It's not 1 million. Its 10,000 partitions.
--
Thanks & Regards,
Nitin Jadhav
On Thu, May 20, 2021 at 12:21 AM Nitin Jadhav
wr
27;tzh:tzm') as
"tzh:tzm";
I have fixed these comments.
> I am not sure whether we should backport this or not but I don't see any
issues with back-patching.
I am also not sure about this. If it is really required, I would like to
create those patches.
Please find the p
fo
{
int col_index;
int. bound_index;
} NullBoundIsNullInfo;
Add 2 fields of type 'NullBoundDatumInfo' and 'NullBoundIsNullInfo' to
the structure [2].
--
Thanks & Regards,
Nitin Jadhav
On Fri, May 21, 2021 at 5:47 PM Amit Langote wrote:
>
> On Fri, M
0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [9956/4129] voluntary/involuntary context switches
Please share your thoughts.
--
Thanks & Regards,
Nitin Jadhav
On Thu, May 20, 2021 at 12:47 AM Justin Pryzby wrote:
> On Tue, May 18, 2021 at 01:49:12PM -0400, Robert H
ther it adds to the
improvement.
Sorry. Kindly ignore the above comment. I had misunderstood the statement.
Thanks & Regards,
Nitin Jadhav
On Sun, May 23, 2021 at 10:40 PM Nitin Jadhav
wrote:
> > I see this as a code cleanup more than an performance optimization.
>
> I agree with
y
> different, or if there's an impressive improvement for this case.
I did not get this point. Kindly explain for which scenario the memory
usage test has to be done.
Thanks & Regards,
Nitin Jadhav
On Sun, May 23, 2021 at 11:16 PM Justin Pryzby wrote:
>
> On Sun, May 23, 2021 at 10
o not lose track of it.
Added https://commitfest.postgresql.org/42/4140/
Thanks & Regards,
Nitin Jadhav
On Mon, Jan 23, 2023 at 11:30 AM Bharath Rupireddy
wrote:
>
> On Thu, Jan 19, 2023 at 3:27 PM Nitin Jadhav
> wrote:
> >
> > > Possibly a better answer is to refactor
atch as it
reduces the code size.
Thanks & Regards,
Nitin Jadhav
On Mon, Jan 23, 2023 at 9:51 PM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > LGTM. I've marked it RfC.
>
> After looking at this, it seemed to me that the factorization
> wasn't quite right
veloper can use both GUC_NO_SHOW_ALL and
GUC_EXPLAIN knowingly or unknowingly for a single GUC. If used by
mistake then according to the existing code (without patch),
GUC_NO_SHOW_ALL takes higher precedence whether it is marked first or
last in the code. I am more convinced with this behaviour as I
* from detecting the problem. But it's better than nothing, and for sure
* we shouldn't expend code on masking the problem more.)
*/
Thanks & Regards,
Nitin Jadhav
hanks & Regards,
Nitin Jadhav
On Wed, Jan 25, 2023 at 9:23 PM Tom Lane wrote:
>
> Nitin Jadhav writes:
> > I agree that the developer can use both GUC_NO_SHOW_ALL and
> > GUC_EXPLAIN knowingly or unknowingly for a single GUC. If used by
> > mistake
e.
The v1 patch corresponds to what you are suggesting. But the question
is not about tracking slru buffers, it is about separating this
information from main buffers count during checkpoint. I think there
is enough discussion done upthread to exclude slru buffers from
CheckpointStats.ckpt_bufs_written
t/CALj2ACXZMOGEtjk%2Beh0Zeiz%3D46ETVkr0koYAjWt8SoJUJJUe9g%40mail.gmail.com#04705e421e0dc63b1f0c862ae4929e6f
Thanks & Regards,
Nitin Jadhav
On Wed, Jan 18, 2023 at 12:31 PM Nitin Jadhav
wrote:
>
> > We would miss the names of the parameters that are marked as NO_SHOW,
> > missing from pg_settin
s now. Similarly why can't we
have a GUC marked as GUC_NO_SHOW_ALL but not GUC_NOT_IN_CONFIG. For me
it makes sense if a GUC is marked as NO_SHOW_ALL and it can be present
in a sample file. It's up to the author/developer to choose which all
flags are applicable to the newly introduced GUCs. Ple
v1 patch and using this (as true)
while creating the table tab_settings_flags in guc.sq and just remove
(NO_SHOW_ALL && !NO_RESET_ALL) check from guc.sql. I don't think doing
this is a problem as we can retain the support of existing signatures
of the pg_show_all_settings function as
are your thoughts.
Thanks & Regards,
Nitin Jadhav
On Sat, Feb 4, 2023 at 1:07 AM Tom Lane wrote:
>
> Nitin Jadhav writes:
> > My concern is if we do this, then we will end up having some policies
> > (which can be read from pg_show_all_settings()) in guc.sql and some in
>
ate_series(1, 1000)));
DO $$
DECLARE v_r record;
DECLARE vref_cursor REFCURSOR;
BEGIN
OPEN vref_cursor FOR SELECT data FROM toasted;
LOOP
fetch vref_cursor into v_r;
INSERT INTO toasted(data) VALUES(v_r.data);
COMMIT;
END LOOP;
END;$$;
Thanks & Regards,
Nitin Jadhav
On Fri, Jan 27, 2023 at 6:26
0002, only for
> HEAD, as that would be a new check.
>
> Remains
> 0002, that I am letting sleep to see if there's interest for it, or
> perhaps more ideas around it.
Makes sense and the patch looks good to me.
Thanks & Regards,
Nitin Jadhav
On Wed, Feb 8, 2023 at 1:29
there's no need for 2 separate patches for these changes.
> I will make it a single patch while sharing the next patch.
Clubbed both patches into one.
Thanks & Regards,
Nitin Jadhav
On Tue, Feb 14, 2023 at 6:08 AM Andres Freund wrote:
>
>
> On 2022-12-21 17:14:12 +0530, Niti
-column list partitioning.
Kindly review the patch and let me know if any changes are required.
Pending items:
1. Support of partition pruning for multi-column list partitioning.
2. Support of partition wise join for multi-column list partitioning.
I will continue to work on the above 2 items.
Ki
rd length at
0/774E758: wanted 24, got 0
2021-06-04 19:40:07.227 IST [51116] LOG: redo done at 0/774E730
system usage: CPU: user: 0.77 s, system: 0.03 s, elapsed: 0.82 s
Kindly let me know if any changes are required.
Thanks & Regards,
Nitin Jadhav
On Thu, Apr 22, 2021 at 4:39 AM Jehan-Guilla
y
> with a GetCurrentTimestamp() after applying every WAL record ... that
> seems like it will be slow.
Thanks for correcting me. This approach is far better than what I had
used earlier. I have done the code changes as per your approach in the
attached patch.
Kindly let me know if any
e to change this value as setting in a
user session is not at all useful. But I am confused between
PGC_POSTMASTER and PGC_SIGHUP. We should use PGC_SIGHUP if we would
like to allow the change during restart after a crash. Otherwise
PGC_POSTMASTER would be sufficient. Kindly share your th
1 - 100 of 148 matches
Mail list logo
