Hi hackers,
I found that in enum XactEvent, there is 'XACT_EVENT_PREPARE' for
'prepare transaction', but there is no event for 'commit prepared' or
'rollback prepared'.
For the following SQL:
begin;
create table test(a int);
PREPARE TRANSACTION
ystem_scan, it receives the SharedInvalidationMessages
and returns the tuples which
are out of date. systable_recheck_tuple is used in dependency.c for such
case.
Tom Lane 于2024年1月14日周日 03:12写道：
> I wrote:
> > Xiaoran Wang writes:
> >> Hmm, how about first checking if any inva
.
if (inval_count != SharedInvalidMessageCounter &&
!systable_recheck_tuple(scandesc, ntp))
{
heap_freetuple(dtp);
return NULL;
}
Xiaoran Wang 于2024年1月13日周六 13:16写道：
> Great! That's what exactly we need.
>
> The patch LGTM, +1
>
>
&g
Great! That's what exactly we need.
The patch LGTM, +1
Tom Lane 于2024年1月13日周六 04:47写道：
> I wrote:
> > This is uncomfortably much in bed with the tuple table slot code,
> > perhaps, but I don't see a way to do it more cleanly unless we want
> > to add some new provisions to that API. Andres,
amp;
TransactionIdDidCommit(xmax))
{
heap_freetuple(dtp);
return NULL;
I'm not quite sure the code is correct, I cannot clearly understand
'HeapTupleHeaderGetUpdateXid', and I need more time to dive into it.
Any thoughts?
Tom Lane 于2024年
Hi,
>> BTW, while nosing around I found what seems like a very nasty related
>> bug. Suppose that a catalog tuple being loaded into syscache contains
>> some toasted fields. CatalogCacheCreateEntry will flatten the tuple,
>> involving fetches from toast tables that will certainly cause
>>
Hi Heikii,
I haven't dug into your patch yet, but for this problem, I have another
idea.
---
explain verbose
select foo from mytable order by sha256(bar::bytea);
QUERY PLAN
Hi,
I updated the comment about the CatalogSnapshot `src/backend/utils/time/
snapmgr.c`
Xiaoran Wang 于2023年12月18日周一 15:02写道：
> Hi,
> Thanks for your reply.
>
> jian he 于2023年12月18日周一 08:20写道：
>
>> Hi
>> ---setup.
>> drop table s2;
>> create table s2(a int
Hi,
Thanks for your reply.
jian he 于2023年12月18日周一 08:20写道：
> Hi
> ---setup.
> drop table s2;
> create table s2(a int);
>
> After apply the patch
> alter table s2 add primary key (a);
>
> watch CatalogSnapshot
>
> #0 GetNonHistoricCatalogSnapshot (relid=1259)
> at
>
not the same as the transaction “CurrentSnapshot”, but we can still update
the CatalogSnapshot’s
“curcid”, as the “curcid” only be checked when the tuple is inserted or
deleted by the current transaction.
Xiaoran Wang 于2023年12月7日周四 10:13写道：
> Hi hackers,
>
>
> For loc
Hi hackers,
For local invalidation messages, there is no need to call
`InvalidateCatalogSnapshot` to set the CatalogSnapshot to NULL and
rebuild it later. Instead, just update the CatalogSnapshot's `curcid`
in `SnapshotSetCommandId`, this way can make the CatalogSnapshot work
well too.
This
Hi,
I updated the comment in 'SnapshotSetCommandId' in this patch which specifies
the reason why it
is not necessary to update 'curcid' of CatalogSnapshot.
Best regards, xiaoran
0001-Update-the-comment-in-SnapshotSetCommandId.patch
Description:
Hi,
I have a question about the routine "GetNonHistoricCatalogSnapshot".
It has a param "Oid relid". It firstly
checks if the relation has systemcache or if it is in
"RelationInvalidatesSnapshotsOnly" related relations.
If yes, it will invalidate the CatalogSnapshot.
I just wonder in which
From: tender wang
Sent: Thursday, May 11, 2023 3:26 PM
To: Tom Lane
Cc: Bharath Rupireddy ; Xiaoran Wang
; pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Use RelationClose rather than table_close in
heap_create_with_catalog
!! External Email
Tom Lane mailto:t
,
NoLock); /* do not unlock till end of xact */
this line is a little confusing since there is no lock on the relation at all.
So I think it's better to use RelationColse here.
From: tender wang
Sent: Wednesday, May 10, 2023 10:57 AM
To: Xiaoran Wang
Cc
Hi hackers,
In heap_create_with_catalog, the Relation new_rel_desc is created
by RelationBuildLocalRelation, not table_open. So it's better to
call RelationClose to release it.
What's more, the comment for it seems useless, just delete it.
Thanks!
Hi,
I created a postgers_fdw server lookback as the test does. Then run the
following SQLs
create table t1(c0 int);
insert into t1 values(1);
create foreign table ft1(
c0 int
) SERVER loopback OPTIONS (schema_name 'public', table_name 't1');
Then started a transaction that runs queries on
Hi,
The max size for the shmem hash table name is SHMEM_INDEX_KEYSIZE - 1.
but when the caller uses a longer hash table name, it doesn't report any error,
instead
it just uses the first SHMEM_INDEX_KEYSIZE -1 chars as the hash table name.
I created some shmem hash tables with the same prefix
The max size for the shared memory hash table name is SHMEM_INDEX_KEYSIZE - 1
(shared hash table name is stored and indexed by ShmemIndex hash table,
the key size of it is SHMEM_INDEX_KEYSIZE), but when the caller uses a
longer hash table name, it doesn't report any error, instead it just
19 matches
Mail list logo
