SV: SV: SV: SV: Problem with ssl and psql in Postgresql 13

Hi, Yes it´s odd. I think we begin with download/reinstall and take it from there. The server name is just letters and numbers so I think we can rule that out. Christmas is coming up fast as usual so I think I will pick this up in January. Thanks for all the help and Happy Christmas! Or God J

Re: pg_upgrade question

Hi Dan, > I am trying to find out if there is any step by step instruction to reconcile > old data dir and upgraded data dir after using “—link” option to do an > upgrade. > > I ran this to do an upgrade from 11.5 to 12.1: pg_upgrade -d > /hostname/pg/dev115/data -D /hostname/pg/dev121upg/dat

Re: Avoid excessive inlining?

On Mon, 2020-12-21 at 11:45 -0500, Philip Semanchuk wrote: > > On Dec 19, 2020, at 12:59 AM, Joel Jacobson wrote: > > Is there a way to avoid excessive inlining when writing pure SQL functions, > > without having to use PL/pgSQL? > > The rules for inlining are here: > https://wiki.postgresql.org

Re: Avoid excessive inlining?

> On Dec 22, 2020, at 8:40 AM, Laurenz Albe wrote: > > On Mon, 2020-12-21 at 11:45 -0500, Philip Semanchuk wrote: >>> On Dec 19, 2020, at 12:59 AM, Joel Jacobson wrote: >>> Is there a way to avoid excessive inlining when writing pure SQL functions, >>> without having to use PL/pgSQL? >> >>

Re: Avoid excessive inlining?

On Tue, Dec 22, 2020, at 14:40, Laurenz Albe wrote: >I would say that the simplest way to prevent a function from being inlined >is to set a parameter on it: > ALTER FUNCTION f() SET enable_seqscan = on; Thanks, very useful, didn't know about that trick. I think I was a bit unclear about my prob

Re: Avoid excessive inlining?

"Joel Jacobson" writes: > I think I was a bit unclear about my problem, and might have used the wrong > terminology. > In my LATERAL query, there are calculations in a certain order. > For each step, "columns" are computed named e.g. "g", "c", "h", "i", etc. > However, when looking at the query p

Re: Missing rows after migrating from postgres 11 to 12 with logical replication

> > Did you have some other replication running on the 11 instance? > Yes the 11 instance also had another (11) replica running. (But these logs are from the 12 instance) The new 12 instance also had a replica running. In any case what was the command logged just before the ERROR. > There is no

Re: Avoid excessive inlining?

Thanks Tom, this was exactly what I needed to hear. I guess I recently have become too fond of all the nice new "recent" advanced SQL features, such as LATERAL and MATERIALIZED CTEs, now in my possession since I now only code on hobby projects, after all the years stuck in an old PostgreSQL ver

ts_parse reports different between MacOS, FreeBSD/Linux

Hello, We have an application whose test suite fails on MacOS when running the search tests on unicode characters. I've narrowed it down to the following: macos=# select * from ts_parse('default','天'); tokid | token ---+--- 12 | 天 (1 row) freebsd=# select * from ts_parse('default'

Re: Missing rows after migrating from postgres 11 to 12 with logical replication

On 12/22/20 9:10 AM, Lars Vonk wrote: Did you have some other replication running on the 11 instance? Yes the 11 instance also had another (11) replica running. (But these logs are from the 12 instance) The 11 instance had the data that went missing in the 12 instance, so what shows up

Re: ts_parse reports different between MacOS, FreeBSD/Linux

"Mark Felder" writes: > We have an application whose test suite fails on MacOS when running the > search tests on unicode characters. Yeah, known problem :-(. The text search parser relies on the C library's locale data to classify characters as being letters, digits, etc. Unfortunately, the UT

Information schema sql_identifier

Per version 12 release notes: "Treat object-name columns in the information_schema views as being of type name, not varchar (Tom Lane) Per the SQL standard, object-name columns in the information_schema views are declared as being of domain type sql_identifier. In PostgreSQL, the underlying

Re: Information schema sql_identifier

On Tue, Dec 22, 2020 at 5:08 PM Adrian Klaver wrote: > SELECT pg_table_size(table_name::regclass) from information_schema.tables; > ERROR: invalid name syntax > > So how does one go about using a table name from > information_schema.tables in pg_table_size()? > Find that the function signatu

Re: Information schema sql_identifier

Adrian Klaver writes: > So how does one go about using a table name from > information_schema.tables in pg_table_size()? You want something like select pg_table_size(quote_ident(table_schema)||'.'||quote_ident(table_name)) from information_schema.tables; I imagine that the failures you got a

Re: Information schema sql_identifier

On 12/22/20 4:33 PM, David G. Johnston wrote: On Tue, Dec 22, 2020 at 5:08 PM Adrian Klaver > wrote: SELECT pg_table_size(table_name::regclass)  from information_schema.tables; ERROR:  invalid name syntax So how does one go about using a table n

Re: Information schema sql_identifier

On 12/22/20 4:39 PM, Tom Lane wrote: Adrian Klaver writes: So how does one go about using a table name from information_schema.tables in pg_table_size()? You want something like select pg_table_size(quote_ident(table_schema)||'.'||quote_ident(table_name)) from information_schema.tables;

Re: Information schema sql_identifier

On Tue, 2020-12-22 at 16:07 -0800, Adrian Klaver wrote: > This came up in this SO question: > > https://stackoverflow.com/questions/65416748/postgres-12-4-gives-function-does-not-exists-error > > Where the query is: > > SELECT (TABLE_SCHEMA || '"."' || TABLE_NAME) as table_name, > pg_siz