Re: [GENERAL] MultiXact member wraparound protections are disabled

Thank you for your help Alvaro - we really appreciate it. The error in fact stopped this morning - we took downtime and ran a vacuum across all of our tables, and saw increased auto vacuum activity as well. It looks like it bumped up the oldest multitxid to something other than 1 now:

Re: [GENERAL] Issue with installation of postgresql server

On 10/13/2016 04:24 AM, Karre, Kanakaraju (US - Hyderabad) wrote: I have been trying to install Postgresql server on my machine (Windows 8-64 bit version) but it is failing to install by throwing the following error – “_There has been an error. The environment variable COMSPEC does not seem to

Re: [GENERAL] functions - triggers cross schemas

Ok that was my oversight in understanding that the path does not change upon entering a function. I assumed that .it does by simply picking it from the schema2.test1 Thanks a bunch Armand On Oct 13, 2016, at 5:31 PM, David G. Johnston wrote: > On Thu, Oct 13,

Re: [GENERAL] functions - triggers cross schemas

On Thu, Oct 13, 2016 at 3:18 PM, Armand Pirvu (home) wrote: > 2 schemas , schema1 and schema2, with same tables , a base table and a > tracking one. > > > Search path is set to schema1 by default. > insert into schema2.test1 (col2 , col3) values ('foo1','foo2') > I get

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Fri, Oct 14, 2016 at 2:04 AM, Kevin Grittner wrote: > On Wed, Oct 12, 2016 at 8:06 PM, Thomas Munro > wrote: >> The "higher isolation levels" probably shouldn't be treated the same way. >> >> I think Peter's right about REPEATABLE READ. We

[GENERAL] functions - triggers cross schemas

2 schemas , schema1 and schema2, with same tables , a base table and a tracking one. Search path is set to schema1 by default. insert into schema2.test1 (col2 , col3) values ('foo1','foo2') I get an entry in schema1.test1_hist and not in schema2.test1_hist I understand that the trigger

[GENERAL] postgres_fdw and permissions

Say user1 creates a foreign table, and grants select permissions on it to user2. When user2 selects from the table, whose USER MAPPING is going to be used, the table owner (user1) or the executing user (user2)? Is this part of the FDW infrastructure or SQL/MED spec, and so above the postgres_fdw

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Thu, Oct 13, 2016 at 3:16 PM, Kevin Grittner wrote: > On Thu, Oct 13, 2016 at 2:16 PM, Peter Geoghegan wrote: >> We must still determine if a fix along the lines of the one proposed >> by Thomas is basically acceptable (that is, that it does not clearly >>

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Thu, Oct 13, 2016 at 2:16 PM, Peter Geoghegan wrote: > On Thu, Oct 13, 2016 at 6:19 AM, Kevin Grittner wrote: >> Every situation that generates a false positive hurts performance; >> we went to great lengths to minimize those cases. >> To generate a >>

Re: [GENERAL] "The index is not optimal" GiST warnings

James Robinson writes: > ... provokes the following warning 14 times (on PostgreSQL 9.5): > DEBUG: picksplit method for column 1 of index > "no_overlapping_rows_orig" failed > HINT: The index is not optimal. To optimize it, contact a developer, >

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Thu, Oct 13, 2016 at 6:19 AM, Kevin Grittner wrote: >> I was under the impression that false positives of this kind are >> allowed by SSI. Why focus on this false positive scenario in >> particular? > > Every situation that generates a false positive hurts performance; > we

Re: [GENERAL] Issue with installation of postgresql server

Hi Kanakaraju, This is a long shot but in case "case" matters, on all my computer the variable is "ComSpec". And I assume you added it as a System variable... Cheers, George On 13/10/2016 6:24 AM, Karre, Kanakaraju (US - Hyderabad) wrote: I have been trying to install Postgresql server on

[GENERAL] "The index is not optimal" GiST warnings

Folks, We are using triggers and daterange-enhanced side-tables for temporal logging of inserts/updates/deletes of data so that we can perform arbitrary point-in-time reporting. Given a slightly augmented many-many relationship table like: Table

[GENERAL] Issue with installation of postgresql server

I have been trying to install Postgresql server on my machine (Windows 8-64 bit version) but it is failing to install by throwing the following error - "There has been an error. The environment variable COMSPEC does not seem to point to the cmd.exe or there is a trailing semicolon present.

Re: [GENERAL] MultiXact member wraparound protections are disabled

avi Singh wrote: > Your right we looked back in our old logs and we do see the messages there > as well. Still what I'm not getting is since we restarted the database > after SAN FC re-cable effort auto-vacuum is running on all the threads > continuous. I have never seen auto-vacuum using all the

Re: [GENERAL] MultiXact member wraparound protections are disabled

Your right we looked back in our old logs and we do see the messages there as well. Still what I'm not getting is since we restarted the database after SAN FC re-cable effort auto-vacuum is running on all the threads continuous. I have never seen auto-vacuum using all the threads 24*7 on this

Re: [GENERAL] MultiXact member wraparound protections are disabled

AnandKumar, Karthik wrote: > Thanks. We started seeing this error right after a SAN FC re-cable effort - > so yes, that would make sense. > We’ll do a little more digging to see if the could have gotten removed. > If that’s an older file that we have in our filesystem backups, is it safe to

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian >: On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > I would assume that having pg_largeobject in a separate tablespace is more and > more common these days, having

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > I would assume that having pg_largeobject in a separate tablespace is more and > more common these days, having real-cheap SAN vs. fast-SSD for normal tables/ > indexes/wal. So common that no one has ever asked for this

Re: [GENERAL] Passing of where clause to remote table in FDW

"Jaisingkar, Piyush" writes: > While using fdw I am trying to get and filtered data from a foreign table. > Filtering using a regex in where clause as follows: > EXPLAIN ANALYZE VERBOSE SELECT CAF1.uprn > FROM XYZ as CAF1 > WHERE > >

Re: [GENERAL] confusion about user paring with pg_hba and pg_ident

On 10/12/2016 08:57 AM, arnaud gaboury wrote: On Wed, Oct 12, 2016 at 3:41 PM Adrian Klaver

[GENERAL] Passing of where clause to remote table in FDW

Hello, While using fdw I am trying to get and filtered data from a foreign table. Filtering using a regex in where clause as follows: EXPLAIN ANALYZE VERBOSE SELECT CAF1.uprn FROM XYZ as CAF1 WHERE

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Wed, Oct 12, 2016 at 8:32 PM, Peter Geoghegan wrote: > On Wed, Oct 12, 2016 at 6:06 PM, Thomas Munro > wrote: >> But yeah, the existing code raises false positive serialization >> failures under SERIALIZABLE, and that's visible in the isolation

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Wed, Oct 12, 2016 at 8:06 PM, Thomas Munro wrote: > On Thu, Oct 13, 2016 at 10:06 AM, Kevin Grittner wrote: >> On Wed, Oct 12, 2016 at 3:02 PM, Peter Geoghegan wrote: >> >>> I agree that the multi-value case is a bug. >> >>> I

Re: [GENERAL] SERIALIZABLE and INSERTs with multiple VALUES

On Wed, Oct 12, 2016 at 5:21 PM, Peter Geoghegan wrote: > On Wed, Oct 12, 2016 at 2:06 PM, Kevin Grittner wrote: >> If the "proper" fix is impossible (or just too freaking ugly) we >> might fall back on the fix Thomas suggested, but I would like to >> take

Re: [GENERAL] MultiXact member wraparound protections are disabled

Thanks. We started seeing this error right after a SAN FC re-cable effort - so yes, that would make sense. We’ll do a little more digging to see if the could have gotten removed. If that’s an older file that we have in our filesystem backups, is it safe to restore from there? On

Re: [GENERAL] MultiXact member wraparound protections are disabled

AnandKumar, Karthik wrote: > root@site-db01a:/var/lib/pgsql/cmates/data # ls pg_multixact/members > 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A 000B 000C > 000D 000E 000F 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 > 001A 001B >

[GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

Hi all.   (I tried raising this on -hackers but got "this is not supported"-answer, which is quite dissatisfactory..)   I have an issue with pg_upgrade upgrading 9.5 to 9.6. (my system is Ubuntu-16.04 and packages from http://apt.postgresql.org/)   In short