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
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
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
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
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
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
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-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
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
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
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-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-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-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
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-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-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-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-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
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.
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
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
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
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-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:
25 matches
Mail list logo
