On Thu, Aug 7, 2025 at 12:21 AM Siraj G wrote:
> Yes Ron, database migration service. But it works better if we have to
> migrate all the DBs in one shot
>
Is that really a problem?
But if there's a problem with DMS, then logical replication should do the
trick.
> since it converts the target
Yes Ron, database migration service. But it works better if we have to
migrate all the DBs in one shot since it converts the target DB into a read
replica during the migration.
Regards
Siraj
On Thu, Aug 7, 2025 at 9:33 AM Ron Johnson wrote:
> On Wed, Aug 6, 2025 at 9:30 PM Siraj G wrote:
>
>>
On Wed, Aug 6, 2025 at 9:30 PM Siraj G wrote:
> Hello Experts!
>
> I have this environment with 100+ DBs and would like to migrate to GCP's
> cloud SQL for Postgres.
>
> Primary: 48 CPUs, 48GB memory
> Secondary/Read Replica: 80 CPUs, 128GB memory
> PG version: 12.22 (we have already started the
Hello Experts!
I have this environment with 100+ DBs and would like to migrate to GCP's
cloud SQL for Postgres.
Primary: 48 CPUs, 48GB memory
Secondary/Read Replica: 80 CPUs, 128GB memory
PG version: 12.22 (we have already started the upgrade process)
OS: Ubuntu
I would like to migrate 2 DBs fir
On 8/6/25 14:39, Rumpi Gravenstein wrote:
That having a table and function with similar names causes this problem
is a bug.
Actually it is that a type and function have the same name. The
connection is the table as that where the type gets it's name. Further
complicated by you doing _type_nam
On Wed, Aug 6, 2025 at 2:39 PM Rumpi Gravenstein wrote:
> That having a table and function with similar names causes this problem is
> a bug.
>
>
Arguably. But it seems likely it's one we are not going to fix.
David J.
"David G. Johnston" writes:
> On Wednesday, August 6, 2025, Rumpi Gravenstein wrote:
>> Here's a reproducible test case that causes the problem in different
>> schemas. The issue appears to be related to creating a table and a
>> function that has the same name as the table with a prepended unde
That having a table and function with similar names causes this problem is
a bug.
Going forward I'll be sure to avoid the problem.
On Wed, Aug 6, 2025 at 5:35 PM David G. Johnston
wrote:
> On Wednesday, August 6, 2025, Rumpi Gravenstein
> wrote:
>
>> Here's a reproducible test case that causes
On Wednesday, August 6, 2025, Rumpi Gravenstein wrote:
> Here's a reproducible test case that causes the problem in different
> schemas. The issue appears to be related to creating a table and a
> function that has the same name as the table with a prepended underscore.
>
Don’t do that. Naming
Here's a reproducible test case that causes the problem in different
schemas. The issue appears to be related to creating a table and a
function that has the same name as the table with a prepended underscore.
rumpi_test -- table name
_rumpi_test -- function name
Here's the test case;
SELECT v
On Wednesday, August 6, 2025, Rumpi Gravenstein wrote:
>
> xxx_pub_dev_2_db=# drop FUNCTION if exists _sa_setup_role;
> DROP FUNCTION
> xxx_pub_dev_2_db=# select proname, pronamespace, oid from pg_proc where
> proname like '%sa_setup%';
> proname | pronamespace | oid
> -+--+--
On 8/6/25 1:17 PM, Rumpi Gravenstein wrote:
Just coming back to this. Don't know how to interpret this:
xxx_pub_dev_2_db=# select proname, pronamespace, oid from pg_proc where
proname like '%sa_setup%';
proname | pronamespace | oid
+--+-
_sa_s
Just coming back to this. Don't know how to interpret this:
xxx_pub_dev_2_db=# select proname, pronamespace, oid from pg_proc where
proname like '%sa_setup%';
proname | pronamespace | oid
+--+-
_sa_setup_role | 7038406 | 7869125
(1 row)
xxx_pub_
Puzzling.
I'd do:
pg_dump --schema-only xxx_pub_dev_2_db | grep -i -A5 _sa_setup_role
Note the -i. That _might_ be important.
On Wed, Aug 6, 2025 at 4:18 PM Rumpi Gravenstein wrote:
> Just coming back to this. Don't know how to interpret this:
>
> xxx_pub_dev_2_db=# select proname, pronamesp
On 8/6/25 11:24, suport...@unitsistemas.com.br wrote:
The executable's libpq is 32-bit, and its dependencies are correct and
on the same architecture. In my Postgres, libpq was on a 64-bit
You need to give more details on what '... my Postgres ...' is?
Did you download it as package or did
## Dominique Devienne (ddevie...@gmail.com):
> Turns out, thanks to ChatGPT for clueing me in, CALL does NOT support
> named parameters.
Turns out, ChatGPT is once again very wrong.
As per https://www.postgresql.org/docs/14/sql-call.html ,
"Arguments can include parameter names, using the syntax
On Wed, Aug 6, 2025 at 11:46 AM Adrian Klaver wrote:
>
> On 8/6/25 06:17, suport...@unitsistemas.com.br wrote:
> > Hello, how are you? I'm asking for help. When I try to compile a 32-bit
> > executable, in my 32-bit Delphi as well, in my 64-bit operating system,
> > an error appears about libpq.dl
On 8/6/25 05:37, Charles Qi wrote:
And if we do the updates in multiple subtransactions, multixact will be
created, which is not created when the BEFORE ROW UPDATE trigger is absent.
Is this behavior by design? If so, what is the purpose for the behavior?
I would say this is by design. My rea
On 8/6/25 10:48, Dominique Devienne wrote:
(sorry, this is a rant...).
Was getting an error calling a procedure
ERROR: procedure ... does not exist
HINT: No procedure matches the given name and argument types. You
might need to add explicit type casts.
I verify USAGE on the SCHEMA of the pro
Hi
st 6. 8. 2025 v 19:49 odesílatel Dominique Devienne
napsal:
> (sorry, this is a rant...).
>
> Was getting an error calling a procedure
>
> ERROR: procedure ... does not exist
> HINT: No procedure matches the given name and argument types. You
> might need to add explicit type casts.
>
> I v
(sorry, this is a rant...).
Was getting an error calling a procedure
ERROR: procedure ... does not exist
HINT: No procedure matches the given name and argument types. You
might need to add explicit type casts.
I verify USAGE on the SCHEMA of the proc. OK.
I verify EXECUTE on the FUNCTION. OK.
On 8/6/25 06:17, suport...@unitsistemas.com.br wrote:
Hello, how are you? I'm asking for help. When I try to compile a 32-bit
executable, in my 32-bit Delphi as well, in my 64-bit operating system,
an error appears about libpq.dll, saying that it was found, but not
loaded. Can you help me with
Hello, how are you? I'm asking for help. When I try to compile a 32-bit executable, in my 32-bit Delphi as well, in my 64-bit operating system, an error appears about libpq.dll, saying that it was found, but not loaded. Can you help me with this?
And if we do the updates in multiple subtransactions, multixact will be
created, which is not created when the BEFORE ROW UPDATE trigger is absent.
Is this behavior by design? If so, what is the purpose for the behavior?
Tested version:
PostgreSQL 14.18 (Ubuntu 14.18-0ubuntu0.22.04.1) on x86_64-p
> On Aug 6, 2025, at 8:03 AM, Simon Connah wrote:
>
> Hi,
>
> I'm pretty new to PostgreSQL and am building a simple website with it.
>
> My main question is whether I should use stored procedures / functions
> or whether I should embed raw SQL queries in my backend? I understand
> that proce
In my experience, starting with store procedures in a project might seem
overwhelming. Still, as time passes, and your deliverables output grows, it
becomes easier to maintain and improve your products.
It is just a different paradigm that allows you to focus on improving your
code everywhere. Rem
On Wed, Aug 6, 2025 at 2:04 PM Simon Connah wrote:
> My main question is whether I should use stored procedures / functions
> or whether I should embed raw SQL queries in my backend? I understand
> that procedures are faster as it cuts down on the round trip speed and
> the database can optimise i
Thank you all for your help. It is much appreciated. I'll have a play
around and see how things work out.
Simon.
On Wed, 6 Aug 2025 at 14:17, Philip Semanchuk
wrote:
>
>
>
> > On Aug 6, 2025, at 8:03 AM, Simon Connah wrote:
> >
> > Hi,
> >
> > I'm pretty new to PostgreSQL and am building a simp
Generally you should use stored procedures when it will reduce the number
of round trips to the database. Wrapping simple SELECT statements in a
stored proc just adds friction for updating the application especially as
the number of developers grows.
On Wed, Aug 6, 2025, 8:04 AM Simon Connah wro
Hi
st 6. 8. 2025 v 14:04 odesílatel Simon Connah napsal:
> Hi,
>
> I'm pretty new to PostgreSQL and am building a simple website with it.
>
> My main question is whether I should use stored procedures / functions
> or whether I should embed raw SQL queries in my backend? I understand
> that proc
Hi,
I'm pretty new to PostgreSQL and am building a simple website with it.
My main question is whether I should use stored procedures / functions
or whether I should embed raw SQL queries in my backend? I understand
that procedures are faster as it cuts down on the round trip speed and
the databa
31 matches
Mail list logo