Re: [GENERAL] Naming conventions for column names

On Wed, Nov 8, 2017 at 12:41 AM, Alvaro Herrera wrote: > Sachin Kotwal wrote: >> 3. Notify or highlight these changes in release notes because this can >> break some existing tools and user code. > > Notifying people when their tools no longer work with a new server is >

Re: [GENERAL] Fwd: standby stop replicating, then picked back up

On Wed, Nov 8, 2017 at 5:17 AM, Laurenz Albe wrote: > chris kim wrote: >> I had a standby hang for a while, not replicating, but then it fixed >> itself but I'm not sure why it happened in the first place. What would I >> look into to see why this happened, or any

Re: [GENERAL] idle in transaction, why

> On Nov 7, 2017, at 12:16 AM, Thomas Kellerer wrote: > > Rob Sargent schrieb am 06.11.2017 um 23:09: >> Gosh I wish I could learn to proof-read my posts. >> My support crew graciously set >> >> idle_transaction_timeout = 1 >> >> Now to ponder if I need zero or some large

Re: [GENERAL] Fwd: standby stop replicating, then picked back up

chris kim wrote: > I had a standby hang for a while, not replicating, but then it fixed > itself but I'm not sure why it happened in the first place. What would I > look into to see why this happened, or any insight into why is greatly > appreciated. You give us precious little information.

[GENERAL] Fwd: standby stop replicating, then picked back up

Forwarded Message Subject:standby stop replicating, then picked back up Date: Tue, 7 Nov 2017 13:04:18 -0700 From: chris kim To: pgsql-in-gene...@postgresql.org Hello, I had a standby hang for a while,

Re: [GENERAL] Incremental refresh - Materialized view

On 11/6/2017 11:34 PM, Krithika Venkatesh wrote: Materialized view log is one of the feature in oracle. It creates a log in which the changes made to the table are recorded. This log is required for an asynchronous materialized view that is refreshed incrementally. I read in the below link

Re: [GENERAL] Block duplications in a shared buffers

Thank you Tom, you were right. I needed to group by all the columns: reldatabase, reltablespace, relforknumber too. Now all of them are unique. Thank you for clearing this out :) -- Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html -- Sent via pgsql-general

Re: [GENERAL] Block duplications in a shared buffers

Tom Lane-2 wrote > Postgres would be completely broken if that were true, because > modifications made to one copy would fail to propagate to other copies. > I don't know where your data came from, but it can't be an accurate > representation of the instantaneous state of the buffer cache. > >

Re: [GENERAL] idle in transaction, why

On 11/07/2017 09:09 AM, Scott Marlowe wrote: On Tue, Nov 7, 2017 at 7:44 AM, Rob Sargent wrote: On Nov 7, 2017, at 12:16 AM, Thomas Kellerer wrote: I would figure values in "minutes" to be more realistic depending on the workload and

Re: [GENERAL] idle in transaction, why

On Tue, Nov 7, 2017 at 7:44 AM, Rob Sargent wrote: > > >> On Nov 7, 2017, at 12:16 AM, Thomas Kellerer wrote: >> >> I would figure values in "minutes" to be more realistic depending on the >> workload and characteristics of the application. >> >> A

Re: [GENERAL] Naming conventions for column names

Sachin Kotwal wrote: > 3. Notify or highlight these changes in release notes because this can > break some existing tools and user code. Notifying people when their tools no longer work with a new server is not the problem; they figure that out pretty quickly once they try the new version. The

Re: [GENERAL] Block duplications in a shared buffers

pinker writes: > I was analysing shared buffers content and noticed that exactly the same > disk block appears there many times with different or the same usagecount. Postgres would be completely broken if that were true, because modifications made to one copy would fail to

[GENERAL] Block duplications in a shared buffers

Hi All, I was analysing shared buffers content and noticed that exactly the same disk block appears there many times with different or the same usagecount. What's the cause of that? It's because of transactions? SELECT count(*), relfilenode, relblocknumber, array_agg(usagecount)

Re: [GENERAL] Naming conventions for column names

On Mon, Nov 6, 2017 at 10:30 PM, Sachin Kotwal wrote: > > Please committers give their final view on this. > > ​They, and others, have - its a "don't want".​ IOW, don't expend any effort since that effort will have been wasted - not that it would take zero effort to

Re: [GENERAL] Incremental refresh - Materialized view

On Tue, Nov 7, 2017 at 7:08 AM, Rakesh Kumar wrote: > You have already been informed. PG, as yet, does not allow incremental > refresh of a MV. It allows online refresh of a MV, but that it does by > doing a full table scan of the base table and rebuilding the MV. >

Re: [GENERAL] idle in transaction, why

> On Nov 7, 2017, at 12:16 AM, Thomas Kellerer wrote: > > Rob Sargent schrieb am 06.11.2017 um 23:09: >> Gosh I wish I could learn to proof-read my posts. >> My support crew graciously set >> >> idle_transaction_timeout = 1 >> >> Now to ponder if I need zero or some large

Re: [GENERAL] Incremental refresh - Materialized view

You have already been informed. PG, as yet, does not allow incremental refresh of a MV. It allows online refresh of a MV, but that it does by doing a full table scan of the base table and rebuilding the MV. From: Krithika Venkatesh