Re: [GENERAL] Link errors

On Fri, May 5, 2017 at 1:30 AM, Igor Korot wrote: > Hi, > [code] > 1> Creating library vc_mswuddll\postgres_dll.lib and object > vc_mswuddll\postgres_dll.exp > 1>libpqd.lib(fe-connect.obj) : error LNK2019: unresolved external > symbol __imp__WSAIoctl@36 referenced in function _setKeepalivesWi

Re: [GENERAL] Caching and Blobs in PG? Was: Can PG replace redis, amqp, s3 in the future?

On Wed, May 3, 2017 at 3:57 AM, Thomas Güttler wrote: > Am 02.05.2017 um 05:43 schrieb Jeff Janes: > >> On Sun, Apr 30, 2017 at 4:37 AM, Thomas Güttler < >> guettl...@thomas-guettler.de > >> wrote: >> >> Is is possible that PostgreSQL will replace these bu

Re: [GENERAL] Caching and Blobs in PG? Was: Can PG replace redis, amqp, s3 in the future?

On 2017-05-04 23:08:25 +0200, Sven R. Kunze wrote: > On 03.05.2017 12:57, Thomas Güttler wrote: > >Am 02.05.2017 um 05:43 schrieb Jeff Janes: > >>No. You can certainly use PostgreSQL to store blobs. But then, you > >>need to store the PostgreSQL data **someplace**. > >>If you don't store it in S3

Re: [GENERAL] Caching and Blobs in PG? Was: Can PG replace redis, amqp, s3 in the future?

On 5/5/2017 11:28 AM, Peter J. Holzer wrote: On 2017-05-04 23:08:25 +0200, Sven R. Kunze wrote: On 03.05.2017 12:57, Thomas Güttler wrote: Am 02.05.2017 um 05:43 schrieb Jeff Janes: No. You can certainly use PostgreSQL to store blobs. But then, you need to store the PostgreSQL data **somepla

Re: [GENERAL] Can PG replace redis, amqp, s3 in the future?

Bill Moran wrote: > > There's a well-written article I saw recently that directly addresses > your question ... I'm too lazy to find it, but google will probably > turn it up for you. This? http://renesd.blogspot.co.uk/2017/02/is-postgresql-good-enough.html Tony. -- f.anthony.n.finchhttp://

Re: [GENERAL] Vaccum Query

On 05/04/2017 02:04 PM, PAWAN SHARMA wrote: > Hi All, > > Any Idea what happens when we run standard vacuum (without full) on a > table which has exclusive lock (or alter statement is being processed > on that table). > > What happens in this case ? Will vacuum wait for the alter to commit ? > Yes

Re: [GENERAL] Caching and Blobs in PG? Was: Can PG replace redis, amqp, s3 in the future?

On 2017-05-05 11:46:55 -0700, John R Pierce wrote: > On 5/5/2017 11:28 AM, Peter J. Holzer wrote: > > On 2017-05-04 23:08:25 +0200, Sven R. Kunze wrote: > > On 03.05.2017 12:57, Thomas Güttler wrote: > > Am 02.05.2017 um 05:43 schrieb Jeff Janes: > > No.

Re: [GENERAL] Can PG replace redis, amqp, s3 in the future?

On Fri, 5 May 2017 19:52:42 +0100 Tony Finch wrote: > Bill Moran wrote: > > > > There's a well-written article I saw recently that directly addresses > > your question ... I'm too lazy to find it, but google will probably > > turn it up for you. > > This? http://renesd.blogspot.co.uk/2017/02/is

[GENERAL] Logical decoding CPU-bound w/ large number of tables

Heyo, I'm attempting to use logical decoding with the streaming replication protocol to perform change-data-capture on PostgreSQL 9.5.4. I'm seeing the replication stream "stall" for long periods of time where the walsender process will be pinned at 100% CPU utilization, but no data is being sent

[GENERAL] PG96 pg_restore connecting to PG95 causes ERROR: unrecognized configuration parameter "idle_in_transaction_session_timeout"

When doing a dump+restore upgrade, it's commonly recommended to use the later version of pg_restore: https://www.postgresql.org/docs/current/static/upgrading.html "It is recommended that you use the pg_dump and pg_dumpall programs from the newer version of PostgreSQL, to take advantage of enhancem

Re: [GENERAL] Logical decoding CPU-bound w/ large number of tables

Mathieu Fenniak writes: > I'm attempting to use logical decoding with the streaming replication > protocol to perform change-data-capture on PostgreSQL 9.5.4. I'm seeing > the replication stream "stall" for long periods of time where the walsender > process will be pinned at 100% CPU utilization,

Re: [GENERAL] PG96 pg_restore connecting to PG95 causes ERROR: unrecognized configuration parameter "idle_in_transaction_session_timeout"

Justin Pryzby writes: > When doing a dump+restore upgrade, it's commonly recommended to use the later > version of pg_restore: > https://www.postgresql.org/docs/current/static/upgrading.html > "It is recommended that you use the pg_dump and pg_dumpall programs from the > newer version of PostgreS

Re: [GENERAL] Logical decoding CPU-bound w/ large number of tables

Hi, On 2017-05-05 14:24:07 -0600, Mathieu Fenniak wrote: > The stalls occur unpredictably on my production system, but generally seem > to be correlated with schema operations. My source database has about > 100,000 tables; it's a one-schema-per-tenant multi-tenant SaaS system. I'm unfortunately

Re: [GENERAL] Logical decoding CPU-bound w/ large number of tables

Hi, On 2017-05-05 20:59:09 -0400, Tom Lane wrote: > Hmm ... as for RelfilenodeMapInvalidateCallback, the lack of calls to > hash_search() from it in your trace says that it usually isn't doing > anything useful. All the time is being spent in hash_seq_search, > uselessly iterating over the hashta

Re: [GENERAL] Logical decoding CPU-bound w/ large number of tables

Andres Freund writes: > On 2017-05-05 14:24:07 -0600, Mathieu Fenniak wrote: >> It appears that most of the time is spent in the >> RelfilenodeMapInvalidateCallback and CatalogCacheIdInvalidate cache >> invalidation callbacks, both of which appear to be invalidating caches >> based upon the cache

Re: [GENERAL] Logical decoding CPU-bound w/ large number of tables

On 2017-05-05 21:32:27 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-05-05 14:24:07 -0600, Mathieu Fenniak wrote: > >> It appears that most of the time is spent in the > >> RelfilenodeMapInvalidateCallback and CatalogCacheIdInvalidate cache > >> invalidation callbacks, both of which a