Re: [GENERAL] Unexpected interval comparison

At Thu, 30 Mar 2017 10:57:19 -0400, Tom Lane wrote in <2087.1490885...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Tue, 21 Mar 2017 07:52:25 -0700, Adrian Klaver > > wrote in > >

REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

Paul Jungwirth writes: >> Also I don't understand why you wrote “You need the permission on both >> tables”: Only the owner of a table can add constraints to it > Ah, this piece was really helpful for me in making it click. Thanks so > much! I added a couple new

Re: [GENERAL] Postgres Permissions Article

Also I don't understand why you wrote “You need the permission on both tables”: Only the owner of a table can add constraints to it Ah, this piece was really helpful for me in making it click. Thanks so much! I added a couple new paragraphs to my post with a link back to this thread. I feel

Re: [GENERAL] pg_dump recording privileges on foreign data wrappers

Adam Mackler writes: > If I grant a privilege on a foreign data wrapper like this: > GRANT USAGE ON FOREIGN DATA WRAPPER postgres_fdw TO myuser; > from within psql, then a dump of the database produced using pg_dump > seems to lack an equivalent GRANT statement,

Re: [GENERAL] inevitability of to_date() when converting representations which don't represent whole timestamps

On 03/30/2017 08:21 AM, Shaun Cutts wrote: On Mar 30, 2017, at 10:02 AM, Adrian Klaver > wrote: On 03/29/2017 06:19 PM, Shaun Cutts wrote: When being asked to convert a day of the week, the to_date() function returns the same day

[GENERAL] pg_dump recording privileges on foreign data wrappers

If I grant a privilege on a foreign data wrapper like this: GRANT USAGE ON FOREIGN DATA WRAPPER postgres_fdw TO myuser; from within psql, then a dump of the database produced using pg_dump seems to lack an equivalent GRANT statement, even though it contains the CREATE EXTENSION statement for

Re: [GENERAL] Tablespace Default Behavior

On 03/30/2017 10:02 AM, harpagornis wrote: Nope, I installed v4.1.3 and it is the same, pg_default appears as the tablespace. Even when I use the drop down list in the right pane of PgAdmin to select the my_space tablespace, and then click the Save button, it does not change. pgAdmin is a

Re: [GENERAL] Tablespace Default Behavior

Nope, I installed v4.1.3 and it is the same, pg_default appears as the tablespace. Even when I use the drop down list in the right pane of PgAdmin to select the my_space tablespace, and then click the Save button, it does not change. -- View this message in context:

Re: [GENERAL] HotSync Replicate doubt?

Good, them I must tested, thanks guys!!! On Thu, Mar 30, 2017 at 9:49 AM, Adrian Klaver wrote: > On 03/30/2017 09:39 AM, Periko Support wrote: >> >> Hi guys. >> >> I had some doubt about PSQL internal replication mechanics(Streaming). >> >> If I setup a Master-Slave

Re: [GENERAL] HotSync Replicate doubt?

On 03/30/2017 09:39 AM, Periko Support wrote: Hi guys. I had some doubt about PSQL internal replication mechanics(Streaming). If I setup a Master-Slave Hot StandBy. The slave is on a Read-Only stage, but we can query the server. If a user create a table in the database: CREATE DATABASE

Re: [GENERAL] HotSync Replicate doubt?

On Thu, 30 Mar 2017 09:39:40 -0700 Periko Support wrote: > Hi guys. > > I had some doubt about PSQL internal replication mechanics(Streaming). > > If I setup a Master-Slave Hot StandBy. > > The slave is on a Read-Only stage, but we can query the server. > > If a

[GENERAL] HotSync Replicate doubt?

Hi guys. I had some doubt about PSQL internal replication mechanics(Streaming). If I setup a Master-Slave Hot StandBy. The slave is on a Read-Only stage, but we can query the server. If a user create a table in the database: CREATE DATABASE mynewdb; CREATE TABLE mytbale-name + fields. Or if

Re: [GENERAL] PostgreSQL and Kubernetes

Il 30/03/2017 15:27, Adrian Klaver ha scritto: On 03/30/2017 03:10 AM, Moreno Andreo wrote: Hi everyone, I was googling around while searching stuff to finish my cluster solution (already running in production in single-server mode) with barman and pgbouncer, when I ran into this

Re: [GENERAL] Tablespace Default Behavior

On 03/30/2017 08:36 AM, harpagornis wrote: Postgres version is 9.4 PgAdmin version is 1.0 Alright seems this is a known issue: https://redmine.postgresql.org/issues/2069 You will need a Postgres coummunity account: https://www.postgresql.org/account/signup/ to see the issue though.

Re: [GENERAL] inevitability of to_date() when converting representations which don't represent whole timestamps

On Thu, Mar 30, 2017 at 8:21 AM, Shaun Cutts wrote: > > My use case is to convert the name of a day to a day of the week number — > now testing in English, but ultimately locale insensitive, so relying on > to_date() to recognize the day in whatever the database locale

Re: [GENERAL] Tablespace Default Behavior

Postgres version is 9.4 PgAdmin version is 1.0 The value returned by the suggested query is correctly reported as 'my_space'. -- View this message in context: http://www.postgresql-archive.org/Tablespace-Default-Behavior-tp5952910p5953046.html Sent from the PostgreSQL - general mailing list

Re: [GENERAL] Tablespace Default Behavior

On 03/30/2017 07:35 AM, harpagornis wrote: In PgAdmin, when I right-click the table, in the Properties pane on the right side of the screen, the tablespace is listed as "pg_default" What we know. Correct me if I am wrong: 1) In postgresql.conf you have: default_tablespace = '' 2) You

Re: [GENERAL] Unexpected interval comparison

Kyotaro HORIGUCHI writes: > At Tue, 21 Mar 2017 07:52:25 -0700, Adrian Klaver > wrote in <375c9e5a-960f-942c-913f-55632a1f0...@aklaver.com> >> On 03/21/2017 07:42 AM, Tom Lane wrote: >>> It looks like the problem is overflow of the

Re: [GENERAL] Tablespace Default Behavior

In PgAdmin, when I right-click the table, in the Properties pane on the right side of the screen, the tablespace is listed as "pg_default" -- View this message in context: http://www.postgresql-archive.org/Tablespace-Default-Behavior-tp5952910p5953028.html Sent from the PostgreSQL - general

[GENERAL] Re: inevitability of to_date() when converting representations which don't represent whole timestamps

On Thursday, March 30, 2017, Peter J. Holzer wrote: > I > > > > David tells this is not a bug, but it still seems like a reasonable > > requirement on to_date() to me. Is there some reason why this isn’t > > possible? > > The documentation warns that to_date “interpret input

Re: [GENERAL] Handling psql lost connections

On 2017-03-29 08:49:57 -0700, Steve Crawford wrote: > When firewalls/VPNs stand between my psql client and a remote PostgreSQL > server > the connection will on occasion time out and drop. This results in the > following scenario: > > -Leave for lunch mid project - leave psql open. > > -Return

Re: [GENERAL] Tablespace Default Behavior

On 03/29/2017 09:18 PM, harpagornis wrote: That is what I suspected, and thank you for the explanation. I think it is misleading and a bug in PgAdmin for explicitly listing the tablespace as pg_default. Listing it where? -- View this message in context:

Re: [GENERAL] inevitability of to_date() when converting representations which don't represent whole timestamps

I don't understand what you mean by "inevitability" in the subject. On 2017-03-29 21:19:56 -0400, Shaun Cutts wrote: > When being asked to convert a day of the week, the to_date() function > returns the same day ('0001-01-01 BC’) no matter which day is > converted: > > # select to_date(‘Monday’,

Re: [GENERAL] inevitability of to_date() when converting representations which don't represent whole timestamps

On 03/29/2017 06:19 PM, Shaun Cutts wrote: When being asked to convert a day of the week, the to_date() function returns the same day ('0001-01-01 BC’) no matter which day is converted: # select to_date(‘Monday’, ‘Day’) '0001-01-01 BC’ # select to_date(‘Tuesday’, ‘Day’) '0001-01-01 BC’

[GENERAL] Keycloak and Postgres

Hi, I have a replication question, we have some big Cisco UCS VM thingy, where VMs are snapshotted, the drives are abstracted etc. If a VM crashes it will be resumed in 1 min from another rack. What brings us master slave replication or some other kind of replication in this setup? Should we

Re: [GENERAL] Postgres Permissions Article

On 2017-03-29 08:05:23 -0700, Paul Jungwirth wrote: > On 03/29/2017 06:36 AM, Tom Lane wrote: > >Karsten Hilbert writes: > >>Being able to create foreign keys may allow to indirectly > >>discover whether certain values exists in a table which I > >>don't otherwise have

Re: [GENERAL] PostgreSQL and Kubernetes

On 03/30/2017 03:10 AM, Moreno Andreo wrote: Hi everyone, I was googling around while searching stuff to finish my cluster solution (already running in production in single-server mode) with barman and pgbouncer, when I ran into this

Re: [GENERAL] PostgreSQL and Kubernetes

On Thu, Mar 30, 2017 at 6:10 AM, Moreno Andreo wrote: > Since I'm on Google Cloud Platform, I thought it would be a good idea to > see what it offers. They currently have in beta a Postgres flavor of their cloudsql. I haven't used it yet, but I plan to test it

Re: [GENERAL] Huge Pages - setting the right value

W dniu 2017-03-30 11:45:55 użytkownik pinker napisał: > Hi, > I'm currently testing performance with and without huge pages. Documentation > says that in order to estimate the number of huge pages needed one should > check the postmaster's VmPeak value. I wonder if it's only

[GENERAL] PostgreSQL and Kubernetes

Hi everyone,     I was googling around while searching stuff to finish my cluster solution (already running in production in single-server mode) with barman and pgbouncer, when I ran into this

[GENERAL] Huge Pages - setting the right value

Hi, I'm currently testing performance with and without huge pages. Documentation says that in order to estimate the number of huge pages needed one should check the postmaster's VmPeak value. I wonder if it's only postmaster memory usage what's matters? Or I could get better estimation from the

Re: [GENERAL] Unexpected interval comparison

Hello, At Tue, 21 Mar 2017 07:52:25 -0700, Adrian Klaver wrote in <375c9e5a-960f-942c-913f-55632a1f0...@aklaver.com> > On 03/21/2017 07:42 AM, Tom Lane wrote: > > Frazer McLean writes: > >> I came across an unexpected comparison (tested on

Re: [GENERAL] Using relations in the SELECT part

Hello Tom, Il giorno mer, 29/03/2017 alle 09.59 -0400, Tom Lane ha scritto: [...] > > Furthermore, let's assume postgres does a cartesian product, if I > > add a > > new relation as third element, does it create 4x3 product? > > You've hit on the reason why it's semantically ugly: it's not very

Re: [GENERAL] Issue in autovacuum

Thanks for your responses! We are not using prepared transactions and not using replication slots as well. We do have a lot of transactions getting created and closed on account of executing the update queries. Thanks, Prateek -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us]