> On Feb 2, 2023, at 1:26 PM, Benedict Holland
> wrote:
>
>
> No idea at all. We had the data for the insert and had to insert it again. It
> was extremely confusing but oh boy did it wreck our systems.
>
> Thanks,
> Ben
Someone has a baked-in uuid in a script I suspect.
>
No idea at all. We had the data for the insert and had to insert it again.
It was extremely confusing but oh boy did it wreck our systems.
Thanks,
Ben
On Thu, Feb 2, 2023, 6:17 PM Ron wrote:
> On 2/2/23 17:11, Peter J. Holzer wrote:
> > On 2023-02-02 10:22:09 -0500, Benedict Holland wrote:
>
On 2/2/23 17:11, Peter J. Holzer wrote:
On 2023-02-02 10:22:09 -0500, Benedict Holland wrote:
Well... until two processes generate an identical UUID. That happened to me
several times.
How did that happen? Pure software implementation with non-random seed?
Hardware with insufficient entropy
On 2023-02-02 10:22:09 -0500, Benedict Holland wrote:
> Well... until two processes generate an identical UUID. That happened to me
> several times.
How did that happen? Pure software implementation with non-random seed?
Hardware with insufficient entropy source?
hp
--
_ | Peter J.
Just a bump on this --- perhaps the error is a bug with the DBMS?
>From what I can see "speculative insertion changes" in this context means
>INSERT..ON CONFLICT DML. Although I have some experience writing extensions
>and simple patches for the code base, I don't know anything as a developer
Tested the UUIDv7 generator for postgres as below.
With regards to performance , It's still way behind the sequence. I was
expecting the insert performance of UUID v7 to be closer to the sequence ,
but it doesn't seem so, as it's 500ms vs 3000ms. And the generation takes a
lot longer time as
Zahir Lalani writes:
> LEFT JOIN lateral (
> SELECT
> CASE
> WHEN (0 > 0) THEN
> convert_from(crypto_secretbox_open, 'utf8')::JSON
> ELSE
> NULL
> END AS edata
> FROM
> crypto_secretbox_open(coalesce(null,
> '')::bytea,
> On 02/02/2023 13:54 CET Zahir Lalani wrote:
>
> Confidential
>
> Hello All
>
> We are testing a upgrade from pg11 to pg14 and have some issues to overcome.
> One of these is that we have upgraded pgsodium to the latest and there is a
> functional change – this question is not about sodium BTW.
Well... until two processes generate an identical UUID. That happened to me
several times. It's rare but when that happens, oh boy that is a mess to
figure out.
Thanks,
Ben
On Thu, Feb 2, 2023, 10:17 AM Miles Elam wrote:
> On Wed, Feb 1, 2023 at 10:48 AM Kirk Wolak wrote:
>
>>
>>
>> On Wed,
On Wed, Feb 1, 2023 at 10:48 AM Kirk Wolak wrote:
>
>
> On Wed, Feb 1, 2023 at 1:34 PM veem v wrote:
>
>>
>> 1) sequence generation vs UUID generation, execution time increased from
>> ~291ms to 5655ms.
>> 2) Insert performance of "sequence" vs "UUID" execution time increased
>> from ~2031ms
On Thu, Feb 2, 2023 at 12:38 PM Daulat wrote:
> Thanks for your quick reply.
>
> uname -a
> .amzn1.x86_64 #1 SMP Sun Nov 27 06:09:45 UTC 2022 x86_64 x86_64 x86_64
> GNU/Linux
>
> Postgres and pgBackrest installed from source
>
> curl -LO
>
Confidential
Hello All
We are testing a upgrade from pg11 to pg14 and have some issues to overcome.
One of these is that we have upgraded pgsodium to the latest and there is a
functional change - this question is not about sodium BTW.
So here is a sample bit of code that I will use to explain
Thanks for your quick reply.
uname -a
.amzn1.x86_64 #1 SMP Sun Nov 27 06:09:45 UTC 2022 x86_64 x86_64 x86_64
GNU/Linux
Postgres and pgBackrest installed from source
curl -LO
https://github.com/pgbackrest/pgbackrest/archive/release/2.43.tar.gz
wget
I use Jetbrains datagrip. I am using pycharm for python dev and datagrip has a
similar UI.
Sent from Proton Mail mobile
Original Message
On Feb 2, 2023, 3:50 AM, Jiten Kumar Shah wrote:
> You can try https://github.com/OmniDB/OmniDB is not active but it is working
> and also
On Thu, Feb 2, 2023 at 7:46 AM Daulat wrote:
> I have pgbackrest v.43 installed on the same server where we are
> running postgres v14.6 that is upgraded from postgres v.10.2
>
> ls /opt/PostgreSQL-14/lib/
>
> libecpg.alibecpg_compat.so.3.14 libpgcommon.a
> libpgport_shlib.a
You can try https://github.com/OmniDB/OmniDB is not active but it is
working and also available in postgres debian repo
On 2/2/23 13:38, Brent Wood wrote:
The free version of Valentina Studio and DBeaver are the two I prefer
If you use Postgis for spatial data, DBeaver understands
The free version of Valentina Studio and DBeaver are the two I prefer
If you use Postgis for spatial data, DBeaver understands geometry data & can
display data on a simple map or as tabular output, with a built in Leaflet
facility.
https://valentina-db.com/en/studio/download
17 matches
Mail list logo
