ERROR: control reached end of function without RETURN, except, it is not a function it is a procedure or a nameless block.

Hi Support, I get an error in a stored procedure - not a stored function mind you - control reached end of function without RETURN The error occurs when doing an exit in  a stored procedure. Now I cannot give all of the stored procedures involved but I can simulate te problem with a very s

Re: ERROR: control reached end of function without RETURN, except, it is not a function it is a procedure or a nameless block.

Hi po 13. 9. 2021 v 13:23 odesílatel Herwig Goemans napsal: > Hi Support, > > > I get an error in a stored procedure - not a stored function mind you - > control reached end of function without RETURN > > The error occurs when doing an exit in a stored procedure. Now > I cannot give all of the

Re: ERROR: control reached end of function without RETURN, except, it is not a function it is a procedure or a nameless block.

Pavel Stehule writes: > po 13. 9. 2021 v 13:23 odesílatel Herwig Goemans > napsal: >> I get an error in a stored procedure - not a stored function mind you - >> control reached end of function without RETURN >> The error occurs when doing an exit in a stored procedure. > This is Postgres's bug

Fastest option to transfer db?

I have a database that I want to transfer from one VM to another. Both VM’s are running on the same (ProxMox) host. select pg_size_pretty(pg_database_size(‘dbname')); shows the database size to be 336GB. What is going to be the fastest method to transfer this data? - The database cluster has ot

Re: Query takes around 15 to 20 min over 20Lakh rows

Hi Tom/David Could you please help me getting started to optimise this query?? Thanks & Regards Shubham mittal On Tue, Sep 7, 2021, 8:57 PM Michael Lewis wrote: > Have you ever used this site to visualize the explain plan and spot bad > estimates and slow nodes? https://explain.depesz.com/s/

Re: Fastest option to transfer db?

What version of Postgres is the source? Can you make use of logical replication?

Re: Fastest option to transfer db?

Source DB is 11.12, destination is 13.4. I’ll look into logical replication - It sounds like it could be a good option. Thanks! --- Israel Brewster Software Engineer Alaska Volcano Observatory Geophysical Institute - UAF 2156 Koyukuk Drive Fairbanks AK 99775-7320 Work: 907-474-5172 cell: 907-

Re: Fastest option to transfer db?

Ok, I have logical replication up-and-running (I guess - seemed to simple to be working. Shouldn’t it be complicated, requiring many steps and configuration changes?), maxing out one CPU core on each machine (more or less), and showing network throughput of around 15M. If DU changes are to be be

what is pg_stat_activity.query for idle connections ?

11.3 on linux I have a DB with a worrisome number of connections with pg_stat_activity.query = '/* DBD::Pg ping test v3.5.3 */', all of them with state='idle'. I have code that uses perl's ping method to ping the DB and I suspect this is the source. Is '/* DBD::Pg ping test v3.5.3 */' the last t

Re: what is pg_stat_activity.query for idle connections ?

David Gauthier writes: > 11.3 on linux > I have a DB with a worrisome number of connections with > pg_stat_activity.query = '/* DBD::Pg ping test v3.5.3 */', all of them with > state='idle'. I have code that uses perl's ping method to ping the DB and > I suspect this is the source. Is '/* DBD::P

To JIT (or not!) in Ubuntu packages

We've noticed that the Ubuntu postgresql-12 package has --with-llvm enabled on x86_64, but not on aarch64. Does anybody know if this was intentional, or just an oversight? For what it's worth, it seems the beta postgresql-14 package for Ubuntu still doesn't have --with-llvm. I'm not sure if

The tragedy of SQL

A fun philosophical discussion. I am no fan of “worse is better”, and particularly its poster child, SQL. The world’s economic output would be substantially higher (5%?) if our industry had settled on almost anything other than SQL for relational databases. So much of the design of *almost ever

Re: The tragedy of SQL

They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. The whole industry, programming languages, infrastructure, everything would have developed differently if relations were a natural, pleasurable thing to use in any program

Re: The tragedy of SQL

On 9/13/21 11:51 PM, Guyren Howe wrote: They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn. The whole industry, programming languages, infrastructure, everything would have developed differently if relations were a natural

Re: The tragedy of SQL

Many languages are awesome. I'm always astonished at what great things people have come up with, over the years; it's been a wonderfully fertile field. We would certainly not be better off if we'd just buckled down, and used COBOL and FORTRAN... or even relatively good languages like C, APL, and