Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

> Maybe we need another type of snapshot that would accept any > non-vacuumable tuple. I really don't want SnapshotAny semantics here, > but a tuple that was live more recently than the xmin horizon seems > like it's acceptable enough. HeapTupleSatisfiesVacuum already > implements the right

Re: [HACKERS] Time based lag tracking for logical replication

On 23/04/17 01:10, Petr Jelinek wrote: > Hi, > > The time based lag tracking commit [1] added interface for logging > progress of replication so that we can report lag as time interval > instead of just bytes. But the patch didn't contain patch for the > builtin logical replication. > > So I

Re: [HACKERS] Re: logical replication and PANIC during shutdown checkpoint in publisher

On Tue, Apr 25, 2017 at 03:26:06PM -0400, Peter Eisentraut wrote: > On 4/20/17 11:30, Peter Eisentraut wrote: > > On 4/19/17 23:04, Noah Misch wrote: > >> This PostgreSQL 10 open item is past due for your status update. Kindly > >> send > >> a status update within 24 hours, and include a date

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

Dmitriy Sarafannikov writes: >> Maybe we need another type of snapshot that would accept any >> non-vacuumable tuple. I really don't want SnapshotAny semantics here, > If I understood correctly, this new type of snapshot would help if > there are long running

Re: [HACKERS] convert EXSITS to inner join gotcha and bug

Really, the way to fix Teodor's complaint is to recognize that the semijoin inner rel is effectively unique against the whole outer rel, and then strength-reduce the semijoin to a plain join. The infrastructure we built for unique joins is capable of proving that, we just weren't applying it in

[HACKERS] CTE inlining

Hello, dear hackers! There is task in todo list about optional CTE optimization fence disabling. I am not interested at this point in disabling mechanism implementation, but I would like to discuss the optimization mechanism, that should work when the fence is disabled. It seems, that we

Re: [HACKERS] convert EXSITS to inner join gotcha and bug

On 29 April 2017 at 15:39, Tom Lane wrote: > I'm kind of strongly tempted to apply the second patch; but it would > be fair to complain that reduce_unique_semijoins() is new development > and should wait for v11. Opinions? My vote is for the non-minimal patch. Of course, I'd

Re: [HACKERS] snapbuild woes

On Fri, Apr 21, 2017 at 10:34:58PM -0700, Andres Freund wrote: > I've a bunch of tests, but I don't quite know whether we can expose all > of them via classical tests. There are several easy ones that I > definitely want to add (import "empty" snapshot; import snapshot with > running xacts;

Re: [HACKERS] convert EXSITS to inner join gotcha and bug

David Rowley writes: > On 29 April 2017 at 15:39, Tom Lane wrote: >> I'm kind of strongly tempted to apply the second patch; but it would >> be fair to complain that reduce_unique_semijoins() is new development >> and should wait for v11.

[HACKERS] A misconception about the meaning of 'volatile' in GetNewTransactionId?

Hi hackers, I was reading xact.c and noticed this block: /* * Use volatile pointer to prevent code rearrangement; other backends * could be examining my subxids info concurrently, and we don't want * them to see an invalid

Re: [HACKERS] CTE inlining

On 30 Apr. 2017 13:28, "Andres Freund" wrote: On 2017-04-30 00:28:46 -0400, Tom Lane wrote: > There's already a pretty large hill to climb here in the way of > breaking peoples' expectations about CTEs being optimization > fences. Breaking the documented semantics about CTEs

Re: [HACKERS] A misconception about the meaning of 'volatile' in GetNewTransactionId?

Thomas Munro writes: > I was reading xact.c and noticed this block: > ... > Isn't this insufficient on non-TSO systems like POWER and Arm? Yeah, I think you're right. That code probably predates our support for memory barriers, so "volatile" was the best we could

Re: [HACKERS] CTE inlining

On 30 Apr. 2017 07:56, "Ilya Shkuratov" wrote: Hello, dear hackers! There is task in todo list about optional CTE optimization fence disabling. I am not interested at this point in disabling mechanism implementation, but I would like to discuss the optimization mechanism, that

Re: [HACKERS] CTE inlining

Craig Ringer writes: > - as you noted, it is hard to decide when it's worth inlining vs > materializing for CTE terms referenced more than once. [ raised eyebrow... ] Please explain why the answer isn't trivially "never". There's already a pretty large hill to

Re: [HACKERS] CTE inlining

2017-04-30 6:28 GMT+02:00 Tom Lane : > Craig Ringer writes: > > - as you noted, it is hard to decide when it's worth inlining vs > > materializing for CTE terms referenced more than once. > > [ raised eyebrow... ] Please explain why the answer

Re: [HACKERS] CTE inlining

On 2017-04-30 00:28:46 -0400, Tom Lane wrote: > There's already a pretty large hill to climb here in the way of > breaking peoples' expectations about CTEs being optimization > fences. Breaking the documented semantics about CTEs being > single-evaluation seems to me to be an absolute