postgres=# create table t (a int, b int);
CREATE TABLE
postgres=# create index m on t(a);
CREATE INDEX
postgres=# create index m2 on t(a);
CREATE INDEX
postgres=# \d t
Table "demo.t"
Column | Type | Collation | Nullable | Default
+-+---+--+--
I have troubles to understand the pg lock in the following simple
situation.
Session 1:
begin; update t set a = 1 where a = 10;
Session 2:
begin; update t set a = 2 where a = 10;
They update the same row and session 2 is blocked by session 1 without
surprise.
The pretty straight implem
Before understanding how postgres implements the serializable isolation
level (I have see many paper related to it), I have question about how it
should be.
I mainly read the ideas from
https://www.postgresql.org/docs/11/transaction-iso.html.
In fact, this isolation level works exactly the same
On Tue, Aug 20, 2019 at 4:59 PM Heikki Linnakangas wrote:
> On 20/08/2019 10:23, Alex wrote:
> > I have troubles to understand the pg lock in the following simple
> > situation.
> >
> >
> > Session 1:
> >
> >
> > begin; update
On Tue, Aug 20, 2019 at 4:47 PM Alex wrote:
> Before understanding how postgres implements the serializable isolation
> level (I have see many paper related to it), I have question about how it
> should be.
>
>
> I mainly read the ideas from
> https://www.postgresql.or
given the following example:
postgres=# create table t2 as select generate_series(1, 10) as a,
generate_series(1, 10) as b;
SELECT 10
postgres=# create index t2_idx on t2(a);
CREATE INDEX
postgres=# set enable_seqscan = 0;
SET
postgres=# select * from t2 where a in (1, 10);
a
On Tue, Aug 20, 2019 at 10:52 PM Alex wrote:
>
>
> On Tue, Aug 20, 2019 at 4:59 PM Heikki Linnakangas
> wrote:
>
>> On 20/08/2019 10:23, Alex wrote:
>> > I have troubles to understand the pg lock in the following simple
>> > situation.
>> >
>
I can get the following log randomly and I am not which commit caused it.
I spend one day but failed at last.
2019-05-08 21:37:46.692 CST [60110] WARNING: problem in alloc set index
info: req size > alloc size for chunk 0x2a33a78 in block 0x2a33a18
2019-05-08 21:37:46.692 CST [60110] WARNING: i
it may happen in 30% cases).
On Thu, May 9, 2019 at 1:21 AM Robert Haas wrote:
> On Wed, May 8, 2019 at 10:34 AM Tom Lane wrote:
> > Alex writes:
> > > I can get the following log randomly and I am not which commit caused
> it.
> >
> > > 2019-05-08 21:37:4
On Thu, May 9, 2019 at 9:30 PM Tom Lane wrote:
> Alex writes:
> > Someone add some code during backend init which used palloc. but at that
> > time, the CurrentMemoryContext is PostmasterContext. at the end of
> > backend initialization, the PostmasterContext is de
I got some idea from the README under storage/lmgr and read some code of
LockAcquireExtended , but I still have some questions now.
LWLockAcquire(&MyProc->backendLock, LW_EXCLUSIVE);
if (FastPathStrongRelationLocks->count[fasthashcode] != 0)
acquired = false;
else
acquired = FastPathGra
HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletable yet */
It is a tuple which has been deleted AND committed but before the delete
there is a transaction started but not committed. Let call this transaction
as Transaction A.
if we create index on this time, Let's call this index as In
On Mon, Jun 10, 2019 at 3:28 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 12:15 PM Alex wrote:
>
>> HEAPTUPLE_RECENTLY_DEAD, /* tuple is dead, but not deletable yet */
>>
>> It is a tuple which has been deleted AND committed but before the delete
>> there is
On Mon, Jun 10, 2019 at 4:10 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 1:30 PM Alex wrote:
> >
> >
> >
> > On Mon, Jun 10, 2019 at 3:28 PM Kuntal Ghosh
> wrote:
> >>
> >> On Mon, Jun 10, 2019 at 12:15 PM Alex wrote:
> >>&g
Thanks! Appreciate it for your time!
On Mon, Jun 10, 2019 at 5:34 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 2:12 PM Alex wrote:
> > On Mon, Jun 10, 2019 at 4:10 PM Kuntal Ghosh
> wrote:
> >> I think what I'm trying to say is different.
> >>
&
In my case, I want to sleep 3 seconds in xxx.sql for pg_regress program.
but I don't want to run 'select pg_sleep(3)' . so it is possible for
pg_regress?
in psql, I can run \! sleep(3); exit;
but looks pg_regress doesn't support it.
ed epoll to run into problems like this too. If there's a
backwards-compatible way of making it less error prone, it'd be nice to do
so.
Alex
h it, causing the connection to fail and
reconnect. Outside of any SSL disconnects (which don't happen often), this
database is stopped and restarted twice a week so we can clone it (using cp -a
--reflink=always).
Any ideas on what might be causing this?
Thanks,
Alex
TABLE loader.sync DROP CONSTRAINT sync_pkey;
ALTER TABLE
record_loader=# ALTER TABLE loader.sync ADD CONSTRAINT sync_pkey PRIMARY KEY
(source, natural_key);
ERROR: could not create unique index "sync_pkey"
DETAIL: Key (source, natural_key)=(ok_lease, ...) is duplicated.
CONTEXT: parallel worker
Any ideas on what might cause this behavior?
Thanks,
Alex
nitdb on
the new directory, and then upgraded using "pg_upgrade -b ... -B ... -d ... -D
-k".
Alex
ade
backup. I also re-upgraded that PG10 backup to PG12, and right after the
upgrade I did not see any corruption either. I checked using both index scans
and sequential scans.
Alex
do have a BEFORE INSERT trigger, but it should never return NULL. This
trigger INSERTs into a different table using an ON CONFLICT DO NOTHING clause
and then does a RETURN NEW.
Alex
On Thu., December 12, 2019 at 5:25 PM, Tomas Vondra wrote:
>On Wed, Dec 11, 2019 at 11:46:40PM +0000, Alex Adriaanse wrote:
>>On Thu., December 5, 2019 at 5:45 PM, Tomas Vondra wrote:
>>> At first I thought maybe this might be due to collations changing and
>>> breaki
The cursor means something like declare c cursor for select * from t;
The holdable cursor means declare c cursor WITH HOLD for select * from t;
Holdable cursor is good at transaction, user can still access it after the
transaction is commit. But it is bad at it have to save all the record to
t
On Wed, Apr 24, 2019 at 11:30 PM Tom Lane wrote:
> alex lock writes:
> > The cursor means something like declare c cursor for select * from t;
> > The holdable cursor means declare c cursor WITH HOLD for select * from t;
>
> > Holdable cursor is good at transaction,
On Thu, Apr 25, 2019 at 9:53 AM alex lock wrote:
>
>
> that's something I want to change, as I said at the beginning. include
> avoid some memory release (like the EState and so on), snapshot release.
>
>
I check my original statement, I found "snapshot release&
::bigint::int::boolean;
bool
--
t
(1 row)
It is just one additional casting and required no additional patching
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
https://aws.amazon.com/dms/
DMS might be helpful if you need to move off of RDS
Alex Kane
On Mon, Mar 5, 2018 at 11:48 AM, Ants Aasma wrote:
> On Mon, Mar 5, 2018 at 2:11 PM, Darafei "Komяpa" Praliaskouski
> wrote:
> >> This approach mixes well with hash
> >&
First of all thank you for looking into this.
At the moment we workaround the problem by altering `acc` ROLE into a SUPERUSER
in PostgreSQL 16 instances. It sidestep the problem and having the lowest cost
to implement for us. While at first we think this feels like opening a security
hole, it does
(big endian), ppc64le (little endian), and a recent riscv64be
patch <https://reviews.llvm.org/D128612>. I guess that is why there are no
endian issues.
--
*From:* Thomas Munro
*Sent:* Thursday, December 15, 2022 9:59:39 AM
*To:* David Rowley
*Cc:* Alex Fan ; pgsql
ult. But jitlink and orc for riscv is
very mature since llvm-15, and even llvm-14 with two minor patches. It
would be good to have these bits, though ugly, so that postgresql jit can
work with llvm-15 as most distros are still moving to it.
cheers,
Alex Fan
On Sun, Dec 25, 2022 at 11:02 PM Andre
On Wed, Feb 19, 2020 at 4:35 PM Alex Malek wrote:
>
> Hello Postgres Hackers -
>
> We are having a reoccurring issue on 2 of our replicas where replication
> stops due to this message:
> "incorrect resource manager data checksum in record at ..."
> This has been oc
On Thu, Apr 2, 2020 at 2:10 PM Andres Freund wrote:
> Hi,
>
> On 2020-02-19 16:35:53 -0500, Alex Malek wrote:
> > We are having a reoccurring issue on 2 of our replicas where replication
> > stops due to this message:
> > "incorrect resource manager data checksum
r creating
ObjectLinkingLayer in a similar fashion as
LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager since orc
doesn't expose it yet.
Thanks and really appreciate if someone can offer a review to this and help
get it merged.
Cheers,
Alex
On Mon, Aug 29, 2022 at 5:46 PM Alex Fan wrote:
&g
This brings the bonus of support jitting on riscv64 (included in this patch)
and other platforms Rtdyld doesn't support, e.g. windows COFF.
Currently, llvm doesn't expose jitlink (ObjectLinkingLayer) via C API, so
a wrapper is added. This also adds minor llvm 15 compat fix that is needed
---
conf
On Mon, Jan 28, 2019, at 10:25, Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 09:05:26AM +0100, Magnus Hagander wrote:
> > And for plain format, we'd do the same -- sync after each file segment, and
> > then a final one of the directory when done, right?
>
> Well, the code is doing a double am
ive?
When using replication slots, what circumstances would cause the master to
not save the WAL file?
(I can't remember if it always had the next wal file or the one after that)
Thanks in advance,
Alex Malek
On Thu, Feb 20, 2020, 6:16 AM Amit Kapila wrote:
> On Thu, Feb 20, 2020 at 3:06 AM Alex Malek wrote:
> >
> >
> > Hello Postgres Hackers -
> >
> > We are having a reoccurring issue on 2 of our replicas where replication
> stops due to this message:
> >
On Thu, Feb 20, 2020 at 12:01 PM Alex Malek wrote:
> On Thu, Feb 20, 2020, 6:16 AM Amit Kapila wrote:
>
>> On Thu, Feb 20, 2020 at 3:06 AM Alex Malek wrote:
>> >
>> >
>> > Hello Postgres Hackers -
>> >
>> > We are having a reoccurring
I check the “alter database, alter role " and "set " command, but none of
them can set the parameters to all the existing sessions. do we have a
way to do that? looks the "assign_hook" can be used to customize this, is
it a right way to do that?
On Wed, Jun 12, 2019 at 4:25 PM Pavel Stehule
wrote:
> Hi
>
> st 12. 6. 2019 v 9:58 odesílatel alex lock napsal:
>
>> I check the “alter database, alter role " and "set " command, but none of
>> them can set the parameters to all the existing sessions.
Hello,
Earlier this week we have split our Postgres 9.6.8 shards, each having two
databases, into one database per shard setup. This was done by promoting
replicas and subsequently removing unused databases.
Immediately afterwards we have discovered repeated 'tuple concurrently updated'
errors on
ension_lock.h:31:13: note: declared here
extern void UnlockRelationForExtension(Relation relation);
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
-Original Message-
From: Alex Ignatov
Sent: Monday, May 21, 2018 6:00 PM
To: 'Robert Haas' ; 'Andres Freund'
Cc: 'Masahiko Sawada' ; 'Michael
8/).
Perhaps there is opportunity for a GSoC student to help fixing it. Until
then we cannot use logical replication for HA, and even doing something
simpler like automating creation of logical replicas in Patroni makes
little sense, as they are doomed to be reinitialized on every failover.
--
Sincerely,
Alex
utors than
Stolon (including those contributed more than one patch/pull-request.)
--
Sincerely,
Alex
ould also love to see is the
estimated on-disk size for the resulting index, before starting to create
it. This is obviously dependent on the actual index type and options, such
as fill-factor, etc.
Cheers,
--
Alex
, or say that we are not being exact. Being
exact is difficult as it depends on the block size. And as I looked
through the doc page in question, I noticed there are already several
cases using the "about" wording, e.g. "about 50MB of pg_xact storage"
and "about 2GB of pg_commit_ts storage", so here I went for
consistency with the rest of the doc.
Thanks,
Alex
o me, attached a v2 patch with small adjustments.
Thanks,
AlexFrom 3deda711bb4219089b32204c567e735b3d7a152b Mon Sep 17 00:00:00 2001
From: Alex Friedman
Date: Thu, 30 Jan 2025 17:19:07 +0200
Subject: [PATCH v2] Doc fix of aggressive vacuum threshold for multixact
members storage.
---
doc
master, but it should probably be backpatched
all the way through 14.
Best regards,
Alex Friedman
v1-0001-Doc-fix-of-aggressive-vacuum-threshold-for-multix.patch
Description: Binary data
ments,
I've added two reminders to multixact.c to update the docs, one for the
threshold and another for the multixact storage scheme. Please see if it makes
sense.
v4 patch attached.
Best regards,
Alex Friedman
From 0965413dbb0b85e4dd78f87a6ca3847dccdc78c7 Mon Sep 17 00:00:00 2001
From: Alex F
time to time, the goal is to
clarify that such discrepancies are to be expected. The attached patch reuses
Robert Haas's eloquent wording from his response in the above thread. I've tried
to keep it short and to the point, but it can be made more verbose if needed.
Best rega
eady has a full paragraph explaining
inconsistencies, so in my opinion it's worth it at least mentioning something
similar here for pg_stat_activity.
Best regards,
Alex FriedmanFrom fbbfc623e16ed97176c0ccf0ebc534d118e9f252 Mon Sep 17 00:00:00 2001
From: Alex Friedman
Date: Wed, 26 Feb
te used pages, and BLCKSZ - 1 for unused".
While these changes are minor, I've seen how this can cause a bit of confusion,
and it would be good to clarify it.
Best regards,
Alex FriedmanFrom a1b78438343fca053aa0014687eaba34d5e160e0 Mon Sep 17 00:00:00 2001
From: Alex Friedman
Date: Tue, 25 F
iscrepancies may exist between the view's columns.
Best regards,
Alex FriedmanFrom 58de88469f6201ae698ee34debcdec028526a72a Mon Sep 17 00:00:00 2001
From: Alex Friedman
Date: Wed, 26 Feb 2025 19:59:59 +0200
Subject: [PATCH v3] Clarify possibility of ephemeral discrepancies between
state
reminder may come in useful?
Best regards,
Alex Friedman
Good points, thank you. I'm good with going ahead as you've suggested.
Best regards,
Alex Friedman
57 matches
Mail list logo
