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
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
(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
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
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
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
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, 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
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:
> >
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., 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
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
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
nitdb on
the new directory, and then upgraded using "pg_upgrade -b ... -B ... -d ... -D
-k".
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
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
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.
>> >
>
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 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
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
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
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
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
+-+---+--+--
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.
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.
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?
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.
> >>
&
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
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
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
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
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
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
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
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&
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,
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 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
--
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
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
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
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
> >&
::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
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
utors than
Stolon (including those contributed more than one patch/pull-request.)
--
Sincerely,
Alex
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
47 matches
Mail list logo
