A shared storage would require a lot of extra work. That's essentially what
AWS Aurora does.
You will have to have functionality to sync in-memory states between nodes,
because all the instances will have cached data that can easily become
stale on any write operation.
That alone is not that simple
And finally, some read only benchmarks with the same postgres build.
9P:
postgres@zerofs:/mnt_9p$ pgbench -vvv -c 100 -j 40 -t 1 bench -S
pgbench (16.9 (Ubuntu 16.10-1))
starting vacuum...end.
starting vacuum pgbench_accounts...end.
transaction type:
scaling factor: 50
query mode: simple
num
I built postgres (same version, 16.9) but --with-block-size=32 (I'd really love
if this would be a initdb time flag!) and did some more testing:
synchronous_commit = off
postgres@zerofs:~$ pgbench -vvv -c 100 -j 40 -t 1 bench
pgbench (16.9 (Ubuntu 16.10-1))
starting vacuum...end.
starting va
On Fri, Jul 25, 2025 at 9:57 AM Jon Zeppieri wrote:
> Thanks for the response, Nick. I'm curious why the situation you describe
> wouldn't also lead to the write_lag and flush_lag also being
> high. If the problem is simply keeping up with the primary, wouldn't you
> expect all three lag times to
Laurenz Albe writes:
> On Fri, 2025-07-25 at 14:10 -0400, Tom Lane wrote:
>> So ... any chance you have a data type named _sa_setup_role?
> ... it could also be a type "sa_setup_role", and "_sa_setup_role"
> is interpreted as the corresponding array type:
Oh, of course --- that's a good deal mor
On Fri, 2025-07-25 at 14:10 -0400, Tom Lane wrote:
> After looking at the code I remembered that the parser might be taking
> this as a type coercion request. With that idea, I can duplicate the
> observed behavior like so:
>
> regression=# select _sa_setup_role('af_repo_app');
> INFO: af_repo_a
I wrote:
> Well, there's got to be *something* different about that database.
After looking at the code I remembered that the parser might be taking
this as a type coercion request. With that idea, I can duplicate the
observed behavior like so:
regression=# select _sa_setup_role('af_repo_app');
Rumpi Gravenstein writes:
> Our databases are deployed with automation tools. They should all be
> created the same. They all have the same 17 extensions. I've asked a DBA
> to confirm.
Well, there's got to be *something* different about that database.
> This issue only appears in the functio
Now I'm wondering about stray entries in pg_cast. Also,
do you have any extensions loaded in that DB that aren't
in your other ones?
Our databases are deployed with automation tools. They should all be
created the same. They all have the same 17 extensions. I've asked a DBA
to confirm.
This
Rumpi Gravenstein writes:
> No ... just one version:
D'oh, actually this would have complained if there was more
than one match, so that theory is wrong:
> _pub_dev_2_db=# DROP FUNCTION if exists _sa_setup_role;
> DROP FUNCTION
Now I'm wondering about stray entries in pg_cast. Also,
do you
There is really only one function with this name. A rerun of my test
script with the suggested change:
_pub_dev_2_db=# SELECT version();
version
---
On 7/25/25 09:59, Rumpi Gravenstein wrote:
No ... just one version:
_pub_dev_2_db=# \df _sa_setup_role
Do:
\df *._sa_setup_role
--
Rumpi Gravenstein
--
Adrian Klaver
adrian.kla...@aklaver.com
No ... just one version:
_pub_dev_2_db=# SHOW server_version;
server_version
16.9
(1 row)
_pub_dev_2_db=# DROP FUNCTION if exists _sa_setup_role;
DROP FUNCTION
_pub_dev_2_db=# CREATE OR REPLACE FUNCTION _sa_setup_role(
p_role_to_be_granted varchar)
_pub_dev_2_d
Rumpi Gravenstein writes:
> I've been confound by the following behavior that I see in one of our
> PostgreSQL 16 instances. In this case I am running this script from psql.
I'd bet there is another function named _sa_setup_role() that takes
some kind of array, and the parser is resolving the am
On 7/25/25 09:36, Rumpi Gravenstein wrote:
PostgreSQL Experts,
I've been confound by the following behavior that I see in one of our
PostgreSQL 16 instances. In this case I am running this script from psql.
-
PostgreSQL Experts,
I've been confound by the following behavior that I see in one of our
PostgreSQL 16 instances. In this case I am running this script from psql.
-
_pub_dev_2_db=# SELECT
On 7/25/25 05:26, Mark wrote:
Hi all
Apologies for any unexpected protocol exceptions, I do not post to
mailing lists very often
I have been trying to work with JSON objects and noticed I could not get
the function json_to_record to produce results, unless I had the key
values in lower case
On Fri, 2025-07-25 at 13:05 +0300, JānisE wrote:
> I seem to not be able to get PostgreSQL to sort rows by a string column
> respecting the diacritics.
>
> I read [1] that it's possible to define a custom collation having collation
> strength "ks"
> set to "level2", which would mean that it's a
On Wed, Jul 23, 2025 at 4:27 PM Nick Cleaton wrote:
>
> On Fri, 18 Jul 2025 at 21:29, Jon Zeppieri wrote:
> >
> > I just had a situation where physical replication fell far behind
> > (hours). The write and flush lag times were 0, but replay_lag was
> > high. The replica has hot_standby_feedback
Sorry all,
Figured it out, the following works:
query:
select * from json_to_record('{"secLvl": 13, "firBal": "somethi", "firLvl":
"C", "thiLvl": "A", "fourLvl": 2}'::json) as x("secLvl" int, "firBal" text,
"firLvl
" text, "thiLvl" text, "fourLvl" int);
result:
secLvl | firBal | firLvl | thiLvl
Hi all
Apologies for any unexpected protocol exceptions, I do not post to mailing
lists very often
I have been trying to work with JSON objects and noticed I could not get
the function json_to_record to produce results, unless I had the key values
in lower case, through testing what works.
I com
Hello! I seem to not be able to get PostgreSQL to sort rows by a string column
respecting the diacritics. I read [1] that it's possible to define a custom
collation having collation strength "ks" set to "level2", which would mean that
it's accent-sensitive. However, when I try to actually sort u
Hi,
I went ahead and did that test.
Here is the postgresql config I used for reference (note the wal options
(recycle, init_zero) as well as full_page_writes = off, because ZeroFS cannot
have torn writes by design).
https://gist.github.com/Barre/8d68f0d00446389998a31f4e60f3276d
Test was runni
23 matches
Mail list logo
