[GENERAL] CTE in a Recursive Union

I have a recursive view that uses a CTE in both the recursive and non-recursive operands to the union operator. This CTE is quite complex --- it calls various others CTEs and does some aggregations, etc. Looking at the explain plan for the view I can see that a "CTE Scan" with a Filter is being

[GENERAL] CTE in a Recursive Union

I have a recursive view that uses a CTE in both the recursive and non-recursive operands to the union operator. This CTE is quite complex --- it calls various others CTEs and does some aggregations, etc. Looking at the explain plan for the view I can see that a "CTE Scan" with a Filter is being

Re: [GENERAL] Serializable Isolation and read/write conflict with index and different keys

On Wed, Aug 30, 2017 at 4:28 AM, Luca Looz wrote: > I'm trying to use the serializable isolation but i'm getting read/write > dependencies error even if i have an unique index on the column used and the > transactions are using different keys. > For an example see this

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

Stuart, Thank you! I will investigate. /s/jr Consultant Concerto GR Mobile: 612.208.6601 Concerto - a composition for orchestra and a soloist > On 29Aug, 2017, at 7:52 AM, Stuart Bishop wrote: > > On 29 August 2017 at 08:42, Jerry Regan >

[GENERAL] Serializable Isolation and read/write conflict with index and different keys

I'm trying to use the serializable isolation but i'm getting read/write dependencies error even if i have an unique index on the column used and the transactions are using different keys. For an example see this gist: https://gist.github.com/nathanl/f98450014f62dcaf0405394a0955e18e Is this an

Re: [GENERAL] Unlogged Crash Detection

On Tue, Aug 29, 2017 at 11:09 PM, Andres Freund wrote: > Huh, but that's not particularly meaningful, is it? That'll just as well > be the case for a freshly created relation, no? I have assumed that the OP has some control on the timing of the relations, using an event

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

On Tue, Aug 29, 2017 at 10:21 AM, Daniel Verite wrote: > Jerry Regan wrote: > > > I think I could justify the effort to ‘script’ psql. I’m not so sure I > can > > justify the effort to write a standalone program. > > As a hack around psql, you could have a script

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

Jerry Regan wrote: > I think I could justify the effort to ‘script’ psql. I’m not so sure I can > justify the effort to write a standalone program. As a hack around psql, you could have a script that feeds psql with "SELECT 1" from time to time and capture only the notifications output:

Re: [GENERAL] Unlogged Crash Detection

On 2017-08-29 20:19:52 +0900, Michael Paquier wrote: > On Tue, Aug 29, 2017 at 6:06 PM, Gersner wrote: > > I see, interesting. > > Please do not top-post. This is not the recommended way of dealing > with threads on this mailing list. > > > We have lots of unlogged tables,

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

On 29 August 2017 at 08:42, Jerry Regan wrote: > Tom, > > After a few minutes thought….. > > /s/jr > Consultant > Concerto GR > Mobile: 612.208.6601 > > Concerto - a composition for orchestra and a soloist > > > > On 28Aug, 2017, at 6:08 PM, Tom Lane

Re: [GENERAL] Out of memory/corrupted shared memory problem on server

Johann Spies writes: > On 25 August 2017 at 13:48, Tom Lane wrote: >> Remember that "work_mem" is "work memory per plan node", so a complex >> query could easily chew up a multiple of that number --- and that's >> with everything going according to

Re: [GENERAL] Unlogged Crash Detection

On Tue, Aug 29, 2017 at 6:06 PM, Gersner wrote: > I see, interesting. Please do not top-post. This is not the recommended way of dealing with threads on this mailing list. > We have lots of unlogged tables, upon a crash we want to create a > feedback/alert that data

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

Tom, After a few minutes thought….. /s/jr Consultant Concerto GR Mobile: 612.208.6601 Concerto - a composition for orchestra and a soloist > On 28Aug, 2017, at 6:08 PM, Tom Lane wrote: > > "David G. Johnston" writes: >> On Mon, Aug 28, 2017

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

David, Thanks for your response! /s/jr Consultant Concerto GR Mobile: 612.208.6601 Concerto - a composition for orchestra and a soloist > On 28Aug, 2017, at 5:36 PM, David G. Johnston > wrote: > > On Mon, Aug 28, 2017 at 1:28 PM, Jerry Regan >

Re: [GENERAL] Create Action for psql when NOTIFY Recieved

Tom, I understand all you’ve said. I was hoping for a different answer. C’est la vie. I think I could justify the effort to ‘script’ psql. I’m not so sure I can justify the effort to write a standalone program. At least I have an answer. Thanks! /s/jr Consultant Concerto GR Mobile:

Re: [GENERAL] Unlogged Crash Detection

I see, interesting. We have lots of unlogged tables, upon a crash we want to create a feedback/alert that data disappeared. Not very familiar with the internal structure, but is it possible to identify if the current table is the INIT_FORKNUM? Gersner On Tue, Aug 29, 2017 at 11:27 AM, Michael

Re: [GENERAL] Unlogged Crash Detection

On Tue, Aug 29, 2017 at 5:17 PM, Gersner wrote: > Is there a reliable way to distinguish between an empty unlogged table to an > unlogged table which has been truncated due to a crash? Why do you want to make such a difference? At the beginning of a crash recovery all the, the

Re: [GENERAL] Performance with high correlation in group by on PK

On 28 August 2017 at 21:32, Jeff Janes wrote: > On Mon, Aug 28, 2017 at 5:22 AM, Alban Hertroys wrote: >> >> Hi all, >> >> It's been a while since I actually got to use PG for anything serious, >> but we're finally doing some experimentation @work now to

[GENERAL] Unlogged Crash Detection

Is there a reliable way to distinguish between an empty unlogged table to an unlogged table which has been truncated due to a crash? Gersner.

Re: [GENERAL] Out of memory/corrupted shared memory problem on server

On 25 August 2017 at 13:48, Tom Lane wrote: > How complex is "complex"? I can think of two likely scenarios: > 1. You've stumbled across some kind of memory-leak bug in Postgres. > 2. The query's just using too much memory. In this connection, it's > not good that you've