2020-12-01 01:04 に Fujii Masao さんは書きました:
On 2020/11/30 23:05, Seino Yuki wrote:
2020-11-30 15:02 に Fujii Masao さんは書きました:
On 2020/11/30 12:08, Seino Yuki wrote:
2020-11-27 22:39 に Fujii Masao さんは書きました:
On 2020/11/27 21:39, Seino Yuki wrote:
2020-11-27 21:37 に Seino Yuki さんは書きました:
2020-11-16
2020-12-09 21:14 に Fujii Masao さんは書きました:
On 2020/12/09 20:42, Li Japin wrote:
Hi,
On Dec 9, 2020, at 6:37 PM, Seino Yuki <mailto:sein...@oss.nttdata.com>> wrote:
2020-12-01 01:04 に Fujii Masao さんは書きました:
On 2020/11/30 23:05, Seino Yuki wrote:
2020-11-30 15:02 に Fujii Masao さんは書
2020-12-14 23:01 に Fujii Masao さんは書きました:
On 2020/12/14 18:17, Seino Yuki wrote:
2020-12-09 21:14 に Fujii Masao さんは書きました:
On 2020/12/09 20:42, Li Japin wrote:
Hi,
On Dec 9, 2020, at 6:37 PM, Seino Yuki <mailto:sein...@oss.nttdata.com>> wrote:
2020-12-01 01:04 に Fujii Masao さんは書
2020-11-02 20:01 に Fujii Masao さんは書きました:
On 2020/11/02 14:02, Yuki Seino wrote:
The following review has been posted through the commitfest
application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:
However, let me confirm the following.
Is this information really useful?
If there is no valid use case for this, I'd like to drop it.
Thought?
I thought it would be easy for users to see at a glance that if there
is a case I assumed,
if the last modified date and time is old, there is no nee
2020-11-09 15:39 に Seino Yuki さんは書きました:
However, let me confirm the following.
Is this information really useful?
If there is no valid use case for this, I'd like to drop it.
Thought?
I thought it would be easy for users to see at a glance that if there
is a case I assumed,
if the
Thank you for pointing that out. I'll post a fixed patch.
+ SpinLockAcquire(&pgss->mutex);
You might noticed, but there a purpose of using the following
idiom. Without that, compiler might optimize out the comparison
assuming *pgss won't change.
volatile pgssSharedState
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->dealloc == 0);
Why is this assertion check necessary? It seems not necessary.
+ {
+ Assert(found == found_info);
Having
Due to similar fixed, we have also merged the patches discussed in the
following thread.
https://commitfest.postgresql.org/30/2736/
The patch is posted on the 2736 side of the thread.
Regards.
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->dealloc == 0);
Why is this assertion check necessary? It seems
2020-11-25 13:13 に Fujii Masao さんは書きました:
On 2020/11/25 12:02, Seino Yuki wrote:
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert
2020-11-16 12:28 に Seino Yuki さんは書きました:
Due to similar fixed, we have also merged the patches discussed in the
following thread.
https://commitfest.postgresql.org/30/2736/
The patch is posted on the 2736 side of the thread.
Regards.
The following patches have been committed and we have
2020-11-27 21:37 に Seino Yuki さんは書きました:
2020-11-16 12:28 に Seino Yuki さんは書きました:
Due to similar fixed, we have also merged the patches discussed in the
following thread.
https://commitfest.postgresql.org/30/2736/
The patch is posted on the 2736 side of the thread.
Regards.
I forgot the
2020-11-27 22:39 に Fujii Masao さんは書きました:
On 2020/11/27 21:39, Seino Yuki wrote:
2020-11-27 21:37 に Seino Yuki さんは書きました:
2020-11-16 12:28 に Seino Yuki さんは書きました:
Due to similar fixed, we have also merged the patches discussed in
the
following thread.
https://commitfest.postgresql.org/30/2736
2020-11-30 15:02 に Fujii Masao さんは書きました:
On 2020/11/30 12:08, Seino Yuki wrote:
2020-11-27 22:39 に Fujii Masao さんは書きました:
On 2020/11/27 21:39, Seino Yuki wrote:
2020-11-27 21:37 に Seino Yuki さんは書きました:
2020-11-16 12:28 に Seino Yuki さんは書きました:
Due to similar fixed, we have also merged the
2021-03-23 23:08 に Andrei Zubkov さんは書きました:
Dear Kuroda,
I don't like the idea because such a column has no meaning for the
specific row.
I prefer storing timestamp if GetCurrentTimestamp() is cheap.
I agree. New version attached.
Thanks for posting the patch.
I agree with this content.
Is i
ot; is executed, then "last_reset_userid",
"last_reset_userid" are updated, but do not update
"last_reset_all_time".
If "pg_statements_reset(0,0,0)" is executed, then "last_reset_userid",
"last_reset_userid" and others are null.
What do you think?
Regards,
Seino Yuki
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to me. Can you please add this to the next
commitfest?
Addded to commitfest. Here is an updated patch version.
Thanks for posting the patch.
I agree with this content.
+ Foreign S
Hi.
This is a proposal for a new feature in statistics collector.
I think we need to add statistics about refresh matview to
pg_stat_all_tables view.
When the "REFRESH MATERIALIZED VIEW" was executed, the number of times
it was executed
and date it took were not recorded anywhere.
"pg_stat_
On 2021-09-01 23:15, Fujii Masao wrote:
Why do you want to treat only REFRESH MATERIALIZED VIEW command
special?
What about other utility commands like TRUNCATE, CLUSTER, etc?
First of all, knowing the update date and time of the MATVIEW is
essential for actual operation.
Without that inform
SPI_start_transaction.
What do you think?
[1]
https://www.postgresql.org/docs/devel/spi-spi-start-transaction.html
[2]
https://www.postgresql.org/docs/devel/sql-begin.html
Regards,
--
Seino Yuki
NTT DATA CORPORATION
Thanks for the reply!
On 2023-06-30 23:26, Heikki Linnakangas wrote:
On 30/06/2023 17:15, Seino Yuki wrote:
Hi,
When I read the documents and coding of SPI, [1]
I found that the following the SPI_start_transaction does not support
transaciton_mode(ISOLATION LEVEL, READ WRITE/READ ONLY) like
On 2023-07-01 00:06, Tom Lane wrote:
Seino Yuki writes:
I also thought that using SPI_start_transaction would be more readable
than using SPI_commit/SPI_rollback to implicitly start a transaction.
What do you think?
I think you're trying to get us to undo commit 2e517818f, which
is not
On 2023-07-01 01:47, Tom Lane wrote:
Seino Yuki writes:
Of course, executing SET TRANSACTION ISOLATION LEVEL with SPI_execute
will result in error.
---
SPI_execute("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE", false, 0);
(Log Output)
ERROR: SET TRANSACTION ISOLATION LEVEL must
Hello,
I would like to add the information of the PID that caused the failure
when acquiring a lock with "FOR UPDATE NOWAIT".
When "FOR UPDATE" is executed and interrupted by lock_timeout,
xid and PID are output in the logs, but in the case of "FOR UPDATE
NOWAIT",
no information is output, maki
Hello,
Add a reference method for shared_memory_size_in_huge_pages
with the "SHOW" command.
The current documentation explains the use of the postgres -C command,
but this method may be limited in DBaaS or managed service environments.
In particular, CloudNativePG does not allow the server to be
Thank you for Review.
Could you explain how to reproduce this? In my quick test,
lock waits canceled by lock_timeout didn’t report either xid or PID,
so I might be missing something.
It seems to be outputting on my end, how about you?
= Console =
postgres=# SHOW log_lock_waits;
log_loc
Thank you, everyone.
the point being to encourage its use before the server is running
as we don't want to allocate anything when tuning it.
I was mistaken and now understand that it needs to be run before the
server is running.
Another idea is to use the same wording as for num_os_semaphores
Considering both points, I’m leaning toward adding a new GUC parameter
to control whether detailed logs should be generated for failed
NOWAIT locks (and possibly for those canceled by lock_timeout).
Alternatively, if adding a new GUC is not ideal, we could extend
log_lock_waits to accept a new
I will send the version with the GUC parameter added from the previous
patch.
I made some minor code refactoring.
Regards,
--
Yuki Seino
NTT DATA CORPORATION
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 934ef5e469..ff6bde0b49 100644
--- a/doc/src/sgml/config.sgml
+++
Currently, we are discussing two improvements:
1. Log output when NOWAIT fails.
2. Adding control via GUC parameters (NOWAIT, lock_timeout,
cancellation).
I'm not sure why it's challenging to provide detailed log messages for
lock waits canceled
by lock_timeout or user cancellation, while it'
The choice between adding a new GUC or extending the existing one
(e.g., log_lock_waits)
is debatable, but I prefer the latter. I'm considering extending
log_lock_waits
to accept a value like "fail". If set to "on" (the current behavior),
detailed logs are generated when the lock wait time excee
During our discussion, I also thought it would be useful to provide detailed logs
> for lock waits canceled by user actions or lock_timeout.
Thank you. I understand now.
You want to output the logs based on a different trigger than
log_lock_waits.
At first, I found that strange, but I see no
33 matches
Mail list logo
