PostgreSQL 10.3 and Ubuntu

There is PostgreSQL 10.3 already. I have Ubuntu 17.10 (artful) and there is not a pgdg repository for it. There is PostgreSQL 10.3 in 16.04 LTS (xenial) pgdg repository, but such packages can't be installed on 17.10 (artful) Ubuntu. And there is zesty-pgdg (for 17.04 Ubuntu), works fine for me

Requiring pass and database psql shell command

Hi Guys, do you have also problem that every time you have to log into your database using shell and psql? I have to write over and over localhost, username, password...how to force shell to remember this? Best, Jacek

psql variables in the DO command

Hello, I can't use psql variable in the DO command. Is it intentional behavior? postgres=# \set var 'Hello, World!' postgres=# do $$begin raise notice '%', :'var'; end;$$; ERROR:  syntax error at or near ":" LINE 1: do $$begin raise notice '%', :'var'; end;$$;    

Re: Requiring pass and database psql shell command

Well, it's not a problem, it's the way it's designed and it's a sensible design. Check https://www.postgresql.org/docs/9.3/static/libpq-envars.html for more info on doing what you want. On March 5, 2018 7:55:46 AM EST, "Łukasz Jarych" wrote: >Hi Guys, > >do you have also

Re: Requiring pass and database psql shell command

On Mon, Mar 5, 2018 at 5:55 AM, Łukasz Jarych wrote: > Hi Guys, > > do you have also problem that every time you have to log into your > database using shell and psql? > > I have to write over and over localhost, username, password...how to force > shell to remember this? > >

Re: psql variables in the DO command

2018-03-05 15:02 GMT+01:00 Pavel Luzanov : > On 05.03.2018 16:56, Pavel Stehule wrote: > > >> I can't use psql variable in the DO command. Is it intentional behavior? >>> >> >> yes. psql variables living on client side, and are not accessible from >> server side . DO

Re: psql variables in the DO command

On 05.03.2018 16:42, Pavel Stehule wrote: I can't use psql variable in the DO command. Is it intentional behavior? yes. psql variables living on client side, and are not accessible from server side . DO command is executed on server side. But SELECT command also executed on a

Re: Requiring pass and database psql shell command

The password file is also a solution. https://www.postgresql.org/docs/current/static/libpq-pgpass.html On 03/05/2018 07:33 AM, James Keener wrote: Well, it's not a problem, it's the way it's designed and it's a sensible design. Check https://www.postgresql.org/docs/9.3/static/libpq-envars.html

Re: psql variables in the DO command

Another possible, but inconvenient workaround - constructing the right string before execution: postgres=# \set var 'Hello, World!' postgres=# \set cmd '$$begin raise notice ''%'', ' :'var' '; end;$$;' postgres=# do :cmd; NOTICE:  Hello, World! DO - Pavel Luzanov Postgres Professional:

Re: What is wrong with my pgadmin?

On 03/05/2018 06:05 AM, Łukasz Jarych wrote: Hi Guys, what is wrong with my pgAdmin? I am creating wrong query: select 1/0 but still this is executed! Well it will be executed, but it should throw an error. Can you confirm that running select 1/0; in psql does indeed throw an error:

Re: What is wrong with my pgadmin?

Hello, This is a bug with pgAdmin4 (Bug: RM#3090 ). Work around for this problem is to set lc_messages = 'en_US.UTF-8' in "postgresql.conf" file. -- Regards, Murtuza Zabuawala EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: psql variables in the DO command

Hi 2018-03-05 14:13 GMT+01:00 Pavel Luzanov : > Hello, > > I can't use psql variable in the DO command. Is it intentional behavior? > yes. psql variables living on client side, and are not accessible from server side . DO command is executed on server side. you can

Re: psql variables in the DO command

On 05.03.2018 16:56, Pavel Stehule wrote: I can't use psql variable in the DO command. Is it intentional behavior? yes. psql variables living on client side, and are not accessible from server side . DO command is executed on server side. But SELECT command

Re: Requiring pass and database psql shell command

thank you!! Jacek 2018-03-05 14:33 GMT+01:00 James Keener : > Well, it's not a problem, it's the way it's designed and it's a sensible > design. Check https://www.postgresql.org/docs/9.3/static/libpq-envars.html > for more info on doing what you want. > > > On March 5, 2018

JDBC4 and setting statement_timeout: responds "is not yet implemented"

Dear Sirs, As quite new in this discussiongroup I have red a lot about statement_timeout, but I can't find any answer on the following problem: My JavaEE-code responds the fpllowing Error message: *Method org.postgresql.jdbc4.Jdbc4PreparedStatement.setQueryTimeout(int) is not yet implemented*

psqlODBC and PostgreSQL

Hi team, Could you tell me the components of psqlODBC, what other applications come along with this download package? Could you let me know if PostgreSQL (Client version 10.x) is a stand alone product or an embedded product? If it is packaged separately by package maintenance?

回复： pg_upgrade fails to restore function

HI Tom Thank you very much for your help. This issue has been solved. Regards, Henry -- 原始邮件 -- 发件人: "Tom Lane"; 发送时间: 2018年3月3日(星期六) 晚上11:30 收件人: "Roger Sunny"<947035...@qq.com>; 抄送: "pgsql-general"; 主题:

Re: psql variables in the DO command

On 05.03.2018 18:01, Pavel Stehule wrote: It is most correct when you thinking about it. 1. :xx is out of SQL syntax, so can by safely used. There is not risk of unwanted usage. But there is absence of wanted usage too. 2. but string literal can contain :xxx symbols and not necessary it

Re: What is wrong with my pgadmin?

Hi, yes, using psql there is an error. Jacek 2018-03-05 15:22 GMT+01:00 Adrian Klaver : > On 03/05/2018 06:05 AM, Łukasz Jarych wrote: > >> Hi Guys, >> >> what is wrong with my pgAdmin? >> >> I am creating wrong query: >> >> select 1/0 but still this is executed! >>

Re: What is wrong with my pgadmin?

I am using: I am using: thank you for help, Jacek 2018-03-05 15:22 GMT+01:00 Adrian Klaver : > On 03/05/2018 06:05 AM, Łukasz Jarych wrote: > >> Hi Guys, >> >> what is wrong with my pgAdmin? >> >> I am creating wrong query: >> >> select 1/0 but still this is

Re: psql variables in the DO command

2018-03-05 16:19 GMT+01:00 Pavel Luzanov : > On 05.03.2018 18:01, Pavel Stehule wrote: > > > It is most correct when you thinking about it. > > 1. :xx is out of SQL syntax, so can by safely used. There is not risk of > unwanted usage. > > But there is absence of wanted

Re: What is wrong with my pgadmin?

Hi geoff, i am expecting that there will be error thrown by pg_admin. Jacek 2018-03-05 15:09 GMT+01:00 geoff hoffman : > What result were you expecting? A divide by zero error? > > > > On Mar 5, 2018, at 07:05, Łukasz Jarych wrote: > > > > Hi Guys, > > > >

Best options for new PG instance

Hi: I'm going to be requesting a PG DB instance (v9.6.7) from an IT dept in a large corp setting. I was wondering if anyone could comment on the pros/cons of getting this put on a virtual machine vs hard metal ? Locally mounted disk vs nfs ? Thanks !

Re: Best options for new PG instance

> On Mar 5, 2018, at 8:53 AM, David Gauthier wrote: > > Hi: > > I'm going to be requesting a PG DB instance (v9.6.7) from an IT dept in a > large corp setting. I was wondering if anyone could comment on the pros/cons > of getting this put on a virtual machine vs

Re: Q: text palloc() size vs. SET_VARSIZE()

Am 04.03.18 20:52 schrieb(en) Tom Lane: > From the docs, for me it is not clear whether the value assigned using SET_VARSIZE() must be the *exact* size of the newly allocated return value, or just the length of the text plus the header size. IOW would the code above create a memory leak if

Re: psql variables in the DO command

2018-03-05 14:52 GMT+01:00 Pavel Luzanov : > On 05.03.2018 16:42, Pavel Stehule wrote: > > > I can't use psql variable in the DO command. Is it intentional behavior? >> > > yes. psql variables living on client side, and are not accessible from > server side . DO command

Re: What is wrong with my pgadmin?

Using pgAdmin 4 2.0 on pg 9.6 and 10 I get div/0 error. On 05/03/2018, 14:22, "Adrian Klaver" wrote: On 03/05/2018 06:05 AM, Łukasz Jarych wrote: > Hi Guys, > > what is wrong with my pgAdmin? > > I am creating wrong query: > >

Re: PQConsumeinput stuck on recv

Hi, On 2018-03-05 17:57:51 -0300, Andre Oliveira Freitas wrote: > Ok, on one hand glad to hear that is an artifact, on the other hand > that means the issue is still out there... > > I'm not a maintainer of Freeswitch, I am an user of it. However I am > trying to supply the maintainers with any

Re: Best options for new PG instance

David Gauthier writes: > Hi: > > I'm going to be requesting a PG DB instance (v9.6.7) from an IT dept in a > large corp setting. I was wondering if anyone could comment on the > pros/cons of getting this put on a virtual machine vs hard metal ? Locally > mounted disk

Re: JDBC4 and setting statement_timeout: responds "is not yet implemented"

Hi Gunnar, On Mon, 2018-03-05 at 12:27 +0100, Gunnar Halvorsen wrote: > Dear Sirs, > As quite new in this discussiongroup I have red a lot about > statement_timeout, but I can't find any answer on the following > problem: > > My JavaEE-code responds the fpllowing Error message: > > Method >

Re: Best options for new PG instance

On Mon, Mar 05, 2018 at 09:51:53AM -0800, Steve Atkins wrote: > I've been running postgresql instances on ESXi VMs for years with no > issues. I've not benchmarked them, but performance has been good > enough despite their running on fairly wimpy hardware. Performance > relative to bare metal is

RE: org.postgresql.util.PSQLException: Error could not open file "base/": No such file or directory

What do you have on your postgresql logs, on the server? Alvaro Aguayo Jefe de Operaciones Open Comb Systems E.I.R.L. Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103  | RPC: (+51)  954183248 Website: www.ocs.pe Sent from my Sony Xperia™ smartphone Raghavendra Rao J S V wrote

org.postgresql.util.PSQLException: Error could not open file "base/": No such file or directory

Hi, Few of the tables and indexes are bloated though auto vacuum has enables. Two reclaim the space vacuum, I have ran vacuum full on the larger tables and also performed reindex on the indexes which are in larger size. Now the size of the database is in control. After perfoming the vacuum full

Re: Resync second slave to new master

On Tue, Mar 06, 2018 at 04:45:10AM +, Dylan Luong wrote: > After a failover (promote) to the Slave1, is it easily resync the > Slave2 to the new master (old slave1)? Do we need to do full rebuild > of the Slave2 from new master everytime we failover to Slave1 from > Master? Can we use

Re: Best options for new PG instance

First - NEVER USE NFS TO STORE DATA YOU DON'T WANT TO LOSE. That said, what you want to host on depends a lot on whether your system is typically CPU bound or I/O bound. A VM for the computational side is generally quite fine. If you're seriously CPU bound then you're likely to want to cluster the

Re: Resync second slave to new master

On Tue, Mar 06, 2018 at 06:00:40AM +, Dylan Luong wrote: > So everytime after promoting Slave to become master (either manually > or automatic), just stop Slave2 and run pg_rewind on slave2 against > the new maser (old slave1). And when old master server is available > again, use pg_rewind on

Resync second slave to new master

Hi We are currently on PostgreSQL 9.6 and our HA is configured as master/slave with wal streaming replication. We would like to setup a second slave which replicates from the same master. Eg: Current setup: Slave <-- Master Slave is setup for automatic failover and we use pg_rewind after

Re: org.postgresql.util.PSQLException: Error could not open file "base/": No such file or directory

On 03/05/2018 05:54 PM, Raghavendra Rao J S V wrote: Hi, Few of the tables and indexes are bloated though auto vacuum has enables. Two reclaim the space vacuum, I have ran vacuum full on the larger tables and also performed reindex on the indexes which are in larger size. Now the size of the

RE: Resync second slave to new master

Thanks Michael, So everytime after promoting Slave to become master (either manually or automatic), just stop Slave2 and run pg_rewind on slave2 against the new maser (old slave1). And when old master server is available again, use pg_rewind on that serve as well against new master to return to