Re: [HACKERS] Async execution of postgres_fdw.

Stephen Frost writes: > I'm all for improving performance of postgres_fdw and would like to see > us support sending queries off to be worked asyncronously, but starting > execution on the remote server during ExecInitNode is against the > documentated FDW API spec. I discussed exactly this issue

Re: [HACKERS] Cube extension kNN support

Hi! Patch is pretty ready, last issue was about changed extension interface, so there should be migration script and version bump. Attaching a version with all migration stuff. distances2r4.patch Description: Binary data Stas. > On 09 May 2015, at 05:20, Alvaro Herrera wrote: > > Sergey

Re: [HACKERS] Remove obsolete mention of src/tools/backend

On Friday, May 8, 2015, Amit Langote wrote: > > Hi, > > Commit 63f1ccd got rid of src/tool/backend and hence > src/tool/backend/index.html. But lmgr README still directs reader to the > aforementioned file. Attached removes this obsolete reference. > Please ignore this. This has already been fix

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

On Fri, May 8, 2015 at 5:48 PM, Tom Lane wrote: > ... btw, I just noticed something that had escaped me because it seems so > obviously wrong that I had not even stopped to consider the possibility > that the code was doing what it's doing. To wit, that the planner > supposes that two foreign tab

Re: [HACKERS] Cube extension kNN support

Sergey Konoplev wrote: > On Thu, Mar 27, 2014 at 3:26 PM, Sergey Konoplev wrote: > > On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich > > wrote: > >> Here is the patch that introduces kNN search for cubes with euclidean, > >> taxicab and chebyshev distances. > > > > What is the status of this patc

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

On Fri, May 8, 2015 at 2:51 PM, Tom Lane wrote: > Well, we have two alternatives. I can keep hacking on this and get it > to a state where it seems credible to me, but we won't have any proof > that it actually works (though perhaps we could treat any problems > as bugs that should hopefully get

Re: [HACKERS] initdb -S and tablespaces

On Fri, May 8, 2015 at 7:53 PM, Andres Freund wrote: > On 2015-05-04 14:23:16 -0400, Robert Haas wrote: >> On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen >> wrote: >> > As for the non-backpatchable 0002, I agree with Andres that it should be >> > included in 9.5; but I take it you're still n

Re: [HACKERS] Async execution of postgres_fdw.

Kyotaro, * Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote: > The attached is the fixed patch. It apparently improves the > performance for the test case shown in the previous mail, in > which the average tuple length is about 140 bytes. I'm all for improving performance of postgres_fd

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

Hi, On 2015-04-24 08:46:48 +0530, Abhijit Menon-Sen wrote: > diff --git a/contrib/pgstattuple/pgstatbloat.c > b/contrib/pgstattuple/pgstatbloat.c > new file mode 100644 > index 000..612e22b > --- /dev/null > +++ b/contrib/pgstattuple/pgstatbloat.c > @@ -0,0 +1,389 @@ > +/* > + * contrib/pgsta

Re: [HACKERS] GSSAPI, SSPI - include_realm default

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote: > > > My comment that include_realm is supported back to 8.4 was because there > > > is an expectation that a pg_hba.conf file can be used unchanged across > > > several major releases

Re: [HACKERS] initdb -S and tablespaces

On 2015-05-04 14:23:16 -0400, Robert Haas wrote: > On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen > wrote: > > As for the non-backpatchable 0002, I agree with Andres that it should be > > included in 9.5; but I take it you're still not convinced? > > No, I'm not convinced. That patch will p

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015-05-09 3:51 GMT+09:00 Tom Lane : > Robert Haas writes: >> On Fri, May 8, 2015 at 1:46 PM, Tom Lane wrote: >>> That's nice, but 9.5 feature freeze is only a week away. I don't have a >>> lot of confidence that this stuff is actually in a state where we won't >>> regret shipping it in 9.5. > >

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015-05-09 2:46 GMT+09:00 Tom Lane : > Kouhei Kaigai writes: >>> I've been trying to code-review this patch, because the documentation >>> seemed several bricks shy of a load, and I find myself entirely confused >>> by the fdw_ps_tlist and custom_ps_tlist fields. > >> Main-point of your concern is

Re: [HACKERS] Proposal: knowing detail of config files via SQL

Sawada, * Sawada Masahiko (sawada.m...@gmail.com) wrote: > Thank you for reviewing. > I agree with this. > Attached patch is updated version v10. Committed with quite a few additional changes and improvements. Please take a look, test, and let me know if you see any issues or have any concerns.

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015-05-09 6:48 GMT+09:00 Tom Lane : > ... btw, I just noticed something that had escaped me because it seems so > obviously wrong that I had not even stopped to consider the possibility > that the code was doing what it's doing. To wit, that the planner > supposes that two foreign tables are pote

Re: [HACKERS] Postgres GSSAPI Encryption

Robbie, * Robbie Harwood (rharw...@redhat.com) wrote: > Today, there exists GSSAPI authentication support in Postgres. I plan > to extend this work to include encryption as well, but wanted to get > your input on that first since you've probably thought about this > already. Great! > From what

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Andres Freund writes: > prairiedog, without CCA, failed as well > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-05-08%2019%3A55%3A11 > different test, but again directly after index creation. So I hope it's > indeed the indcheckxmin thing. Oh, interesting. That definitely sugg

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

... btw, I just noticed something that had escaped me because it seems so obviously wrong that I had not even stopped to consider the possibility that the code was doing what it's doing. To wit, that the planner supposes that two foreign tables are potentially remote-joinable if they share the sam

Re: [HACKERS] multixacts woes

Robert Haas wrote: > My colleague Thomas Munro and I have been working with Alvaro, and > also with Kevin and Amit, to fix bug #12990, a multixact-related data > corruption bug. Thanks for this great summary of the situation. > 1. I believe that there is still a narrow race condition that cause

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 22:29:47 +0200, Andres Freund wrote: > On 2015-05-08 15:22:09 -0400, Tom Lane wrote: > > I'm back to suspecting that the indcheckxmin issue is the true cause of > > the buildfarm failure > > though we lack an explanation why Andres failed to reproduce it ... > > My laptop is probabl

Re: [HACKERS] multixacts woes

Josh Berkus wrote: > I have a couple workloads in my pool which do consume mxids faster than > xids, due to (I think) execeptional numbers of FK conflicts. It's > definitely unusual, though, and I'm sure they'd rather have corruption > protection and endure some more vacuums. If we do this, thou

[HACKERS] Postgres GSSAPI Encryption

Hello! Today, there exists GSSAPI authentication support in Postgres. I plan to extend this work to include encryption as well, but wanted to get your input on that first since you've probably thought about this already. From what I can tell, the auth/encryption layer is very nicely designed for

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 15:22:09 -0400, Tom Lane wrote: > I'm back to suspecting that the indcheckxmin issue is the true cause of > the buildfarm failure Me too. > though we lack an explanation why Andres failed to reproduce it ... My laptop is probably a good bit faster than jaguarundi, particularly in a

Re: [HACKERS] multixacts woes

On 2015-05-08 12:57:17 -0700, Josh Berkus wrote: > I have a couple workloads in my pool which do consume mxids faster than > xids, due to (I think) execeptional numbers of FK conflicts. It's > definitely unusual, though, and I'm sure they'd rather have corruption > protection and endure some more

Re: [HACKERS] multixacts woes

On 05/08/2015 11:27 AM, Andres Freund wrote: > Hi, > > On 2015-05-08 14:15:44 -0400, Robert Haas wrote: >> 3. It seems to me that there is a danger that some users could see >> extremely frequent anti-mxid-member-wraparound vacuums as a result of >> this work. Granted, that beats data corruption

Re: [HACKERS] deparsing utility commands

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Here's a cleaned up version of this patch; I threw together a very quick > > test module, and updated a conflicting OID. As far as I can tell, I'm > > only missing the documentation updates before this is push-able. > > Here is a complete version.

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Fri, May 8, 2015 at 4:23 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Thu, May 7, 2015 at 7:55 PM, Sawada Masahiko wrote: > > > > On 5/7/15, Sawada Masahiko wrote: > > > On Wed, May 6, 2015 at 5:42 AM, Robert Haas > > > wrote: > > >> On Tue, May 5, 2015 at 11:10 AM,

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, May 7, 2015 at 7:55 PM, Sawada Masahiko wrote: > > On 5/7/15, Sawada Masahiko wrote: > > On Wed, May 6, 2015 at 5:42 AM, Robert Haas > > wrote: > >> On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko > > wrote: > >>> On Fri, May 1, 2015 at 9:04 PM, Robert Haas > > wrote: > On Thu, A

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Actually, looking closer, the quoted code is simply not broken without >> RELCACHE_FORCE_RELEASE: without that, neither heap_close nor index_close >> will do anything that could cause a cache flush. So while it's certainly >> good

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I wrote: > > Peter Geoghegan writes: > >> On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: > >>> Ooops. But shouldn't that have failed 100% of the time in a CCA build? > >>> Or is the candidates list fairly noncritical? > > >> The candidates list is abso

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

I wrote: > Peter Geoghegan writes: >> On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: >>> Ooops. But shouldn't that have failed 100% of the time in a CCA build? >>> Or is the candidates list fairly noncritical? >> The candidates list is absolutely critical. > Oh, I was confusing CCA with RELC

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Geoghegan writes: > > On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: > >> Ooops. But shouldn't that have failed 100% of the time in a CCA build? > >> Or is the candidates list fairly noncritical? > > > The candidates list is absolutely critical.

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 14:59:22 -0400, Tom Lane wrote: > Andres Freund writes: > > I think Peter (on IM) just found a more likely explanation than mine. > > index_close(idxRel, NoLock); > > heap_close(relation, NoLock); > > candidates = lappend_oi

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Peter Geoghegan writes: > On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: >> Ooops. But shouldn't that have failed 100% of the time in a CCA build? >> Or is the candidates list fairly noncritical? > The candidates list is absolutely critical. Oh, I was confusing CCA with RELCACHE_FORCE_RELEAS

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

* Peter Geoghegan (p...@heroku.com) wrote: > On Fri, May 8, 2015 at 12:00 PM, Peter Geoghegan wrote: > > On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: > >> Ooops. But shouldn't that have failed 100% of the time in a CCA build? > >> Or is the candidates list fairly noncritical? > > > > The can

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On Fri, May 8, 2015 at 12:00 PM, Peter Geoghegan wrote: > On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: >> Ooops. But shouldn't that have failed 100% of the time in a CCA build? >> Or is the candidates list fairly noncritical? > > The candidates list is absolutely critical. However, the prob

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On Fri, May 8, 2015 at 11:59 AM, Tom Lane wrote: > Ooops. But shouldn't that have failed 100% of the time in a CCA build? > Or is the candidates list fairly noncritical? The candidates list is absolutely critical. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Andres Freund writes: > I think Peter (on IM) just found a more likely explanation than mine. > index_close(idxRel, NoLock); > heap_close(relation, NoLock); > candidates = lappend_oid(candidates, > idxForm->indexrelid); > ... > Yes

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

Robert Haas writes: > On Fri, May 8, 2015 at 1:46 PM, Tom Lane wrote: >> That's nice, but 9.5 feature freeze is only a week away. I don't have a >> lot of confidence that this stuff is actually in a state where we won't >> regret shipping it in 9.5. > Yeah. The POC you were asking for upthread

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On Fri, May 8, 2015 at 11:35 AM, Andres Freund wrote: > I think Peter (on IM) just found a more likely explanation than mine. > > index_close(idxRel, NoLock); > heap_close(relation, NoLock); > candidates = lappend_oid(candidat

Re: [HACKERS] deparsing utility commands

On Fri, May 8, 2015 at 3:14 PM, Alvaro Herrera wrote: > > Alvaro Herrera wrote: > > Here's a cleaned up version of this patch; I threw together a very quick > > test module, and updated a conflicting OID. As far as I can tell, I'm > > only missing the documentation updates before this is push-abl

Re: [HACKERS] multixacts woes

On 2015-05-08 14:32:14 -0400, Robert Haas wrote: > On Fri, May 8, 2015 at 2:27 PM, Andres Freund wrote: > > On 2015-05-08 14:15:44 -0400, Robert Haas wrote: > >> Apparently, we have been hanging our hat since the release of 9.3.0 on > >> the theory that the average multixact won't ever have more t

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 14:30:46 -0400, Tom Lane wrote: > Maybe just hold an open transaction in another session while you do what > the regression test does? I think this is probably not a matter of CCA > per se but just timing. It's unfortunate that the test in question is > run serially without other tr

Re: [HACKERS] multixacts woes

On Fri, May 8, 2015 at 2:27 PM, Andres Freund wrote: > On 2015-05-08 14:15:44 -0400, Robert Haas wrote: >> Apparently, we have been hanging our hat since the release of 9.3.0 on >> the theory that the average multixact won't ever have more than two >> members, and therefore the members SLRU won't

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Andres Freund writes: > On 2015-05-08 11:10:00 -0700, Peter Geoghegan wrote: >> +1. I knew we should have done this before commit. > Hrmpf. > I couldn't hit the problem with CCA unfortunately, even after a bunch of > tries; quite possibly it's too fast on my laptop. Maybe just hold an open tran

Re: [HACKERS] multixacts woes

Hi, On 2015-05-08 14:15:44 -0400, Robert Haas wrote: > Apparently, we have been hanging our hat since the release of 9.3.0 on > the theory that the average multixact won't ever have more than two > members, and therefore the members SLRU won't overwrite itself and > corrupt data. It's essentially

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

On Fri, May 8, 2015 at 1:46 PM, Tom Lane wrote: > That's nice, but 9.5 feature freeze is only a week away. I don't have a > lot of confidence that this stuff is actually in a state where we won't > regret shipping it in 9.5. Yeah. The POC you were asking for upthread certainly exists and has fo

[HACKERS] multixacts woes

My colleague Thomas Munro and I have been working with Alvaro, and also with Kevin and Amit, to fix bug #12990, a multixact-related data corruption bug. I somehow did not realize until very recently that we actually use two SLRUs to keep track of multixacts: one for the multixacts themselves (pg_m

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 11:10:00 -0700, Peter Geoghegan wrote: > +1. I knew we should have done this before commit. Hrmpf. I couldn't hit the problem with CCA unfortunately, even after a bunch of tries; quite possibly it's too fast on my laptop. So I'll just have remove the check and we'll see whether it

Re: [HACKERS] deparsing utility commands

Alvaro Herrera wrote: > Here's a cleaned up version of this patch; I threw together a very quick > test module, and updated a conflicting OID. As far as I can tell, I'm > only missing the documentation updates before this is push-able. Here is a complete version. Barring serious problems, I inte

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On Fri, May 8, 2015 at 11:06 AM, Andres Freund wrote: > On 2015-05-08 20:37:15 +0300, Heikki Linnakangas wrote: >> Why does INSERT ON CONFLICT pay attention to indcheckxmin? Uniqueness check >> only cares about the most recent committed version of the tuple, and the >> index good for that use imme

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 20:37:15 +0300, Heikki Linnakangas wrote: > Why does INSERT ON CONFLICT pay attention to indcheckxmin? Uniqueness check > only cares about the most recent committed version of the tuple, and the > index good for that use immediately. If there was a problem there, the > uniqueness chec

Re: [HACKERS] ALTER SYSTEM and ParseConfigFile()

Stephen Frost writes: > Greetings, > While working through the pg_file_settings patch, I came across this > comment above ParseConfigFp() (which is called by ParseConfigFile()): > src/backend/utils/misc/guc-file.l:603 > -- > * Output parame

[HACKERS] ALTER SYSTEM and ParseConfigFile()

Greetings, While working through the pg_file_settings patch, I came across this comment above ParseConfigFp() (which is called by ParseConfigFile()): src/backend/utils/misc/guc-file.l:603 -- * Output parameters: * head_p, tail_p: head and

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

Kouhei Kaigai writes: >> I've been trying to code-review this patch, because the documentation >> seemed several bricks shy of a load, and I find myself entirely confused >> by the fdw_ps_tlist and custom_ps_tlist fields. > Main-point of your concern is lack of documentation/comments to introduce

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 19:32:02 +0200, Andres Freund wrote: > If the failure is indeed caused by checkxmin (trying to reproduce > right now), we can just remove the updates in that subsection of the > tests. They're not relevant. Hm. Or easier and uglier, replace the CREATE INDEX statements with CREATE IN

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 05/08/2015 08:25 PM, Tom Lane wrote: Andres Freund writes: On 2015-05-08 12:32:10 -0400, Tom Lane wrote: Looks like there's a CLOBBER_CACHE_ALWAYS issue ... http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2015-05-08%2011%3A52%3A00 Currently index inferrence ignores i

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 13:25:22 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-05-08 12:32:10 -0400, Tom Lane wrote: > >> Looks like there's a CLOBBER_CACHE_ALWAYS issue ... > >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2015-05-08%2011%3A52%3A00 > > > Currently inde

Re: [HACKERS] [COMMITTERS] pgsql: Teach autovacuum about multixact member wraparound.

On Fri, May 8, 2015 at 1:23 PM, Kevin Grittner wrote: > Robert Haas wrote: > >> This patch leaves unsolved the problem of ensuring that emergency >> autovacuums are triggered even when autovacuum=off. We'll need >> to fix that via a separate patch. > > I think we also need something like your pr

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Andres Freund writes: > On 2015-05-08 12:32:10 -0400, Tom Lane wrote: >> Looks like there's a CLOBBER_CACHE_ALWAYS issue ... >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2015-05-08%2011%3A52%3A00 > Currently index inferrence ignores indexes that aren't yet valid > accor

[HACKERS] Re: [COMMITTERS] pgsql: Teach autovacuum about multixact member wraparound.

Robert Haas wrote: > This patch leaves unsolved the problem of ensuring that emergency > autovacuums are triggered even when autovacuum=off. We'll need > to fix that via a separate patch. I think we also need something like your previously-posted multixact-truncate-race.patch as a follow-on.

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 12:32:10 -0400, Tom Lane wrote: > Andres Freund writes: > > So I've committed the patch yesterday evening. I'm pretty sure there'll > > be some more minor things to change. But overall I feel good about the > > current state. > > Looks like there's a CLOBBER_CACHE_ALWAYS issue ... >

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Andres Freund writes: > So I've committed the patch yesterday evening. I'm pretty sure there'll > be some more minor things to change. But overall I feel good about the > current state. Looks like there's a CLOBBER_CACHE_ALWAYS issue ... http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jagu

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 8 May 2015 at 16:51, Andres Freund wrote: > On 2015-05-08 16:36:07 +0100, Geoff Winkless wrote: > > I thought the previous version suggested multiple possible targets and > > actions, this suggests that while there can be multiple targets the > > action is always the same. > > I don't think an

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-05-08 16:36:07 +0100, Geoff Winkless wrote: > Omitted only has one m. > > There's an extra space in "error . (See". > > Otherwise it reads fine to me, although I've only skimmed it. Thanks, I'll push fixes for those. > I may have misunderstood: there is only one ON CONFLICT action > all

Re: [HACKERS] transforms vs. CLOBBER_CACHE_ALWAYS

* Tom Lane wrote: Christian Ullrich writes: * Peter Eisentraut wrote: On 4/30/15 2:49 PM, Andrew Dunstan wrote: friarbird is a FreeBSD buildfarm animal running with -DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours. However, it's been stuck since Monday running the plpyth

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 8 May 2015 at 16:03, Andres Freund wrote: > So I've committed the patch yesterday evening. I'm pretty sure there'll > be some more minor things to change. But overall I feel good about the > current state. > > It'd be quite helpful if others could read the docs, specifically for > insert, and

Re: [HACKERS] [COMMITTERS] pgsql: Add transforms feature

Peter Eisentraut writes: > On 5/3/15 2:27 PM, Tom Lane wrote: >> 2. Preventing undefined-symbol errors at link time will hide actual coding >> errors, not only the intended cross-plugin reference cases. We have >> repeatedly seen the buildfarm members that complain about this find actual >> bugs

Re: [HACKERS] transforms vs. CLOBBER_CACHE_ALWAYS

Christian Ullrich writes: > * Peter Eisentraut wrote: >> On 4/30/15 2:49 PM, Andrew Dunstan wrote: >>> friarbird is a FreeBSD buildfarm animal running with >>> -DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours. >>> However, it's been stuck since Monday running the plpython regr

Re: [HACKERS] transforms vs. CLOBBER_CACHE_ALWAYS

* Peter Eisentraut wrote: On 4/30/15 2:49 PM, Andrew Dunstan wrote: friarbird is a FreeBSD buildfarm animal running with -DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours. However, it's been stuck since Monday running the plpython regression tests. The only relevant commit

Re: [HACKERS] Broken --dry-run mode in pg_rewind

8 мая 2015 г., в 16:39, Vladimir Borodin написал(а):8 мая 2015 г., в 16:11, Stephen Frost написал(а):* Heikki Linnakangas (hlinn...@iki.fi) wrote:On 05/08/2015 03:39 PM, Michael Paquier wrote:On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

So I've committed the patch yesterday evening. I'm pretty sure there'll be some more minor things to change. But overall I feel good about the current state. It'd be quite helpful if others could read the docs, specifically for insert, and comment whether they're understandable. I've spent a fair

Re: [HACKERS] Modify pg_stat_get_activity to build a tuplestore

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > > As I mentioned on another thread, you're certainly right about that, and > > here's the first broken-out patch, which just changes > > pg_stat_get_activity to build and return a tuplestore in a single > > function call

Re: [HACKERS] Disabling trust/ident authentication configure option

--On 6. Mai 2015 16:28:43 -0400 Andrew Dunstan wrote: >> Single user sessions would work, but the "peer" authentication is also >> still available and should be the preferred method to reset passwords >> when trust is disabled, so this should not be an issue. > > (Personally I think there's

Re: [HACKERS] Modify pg_stat_get_activity to build a tuplestore

Stephen Frost wrote: > As I mentioned on another thread, you're certainly right about that, and > here's the first broken-out patch, which just changes > pg_stat_get_activity to build and return a tuplestore in a single > function call instead of using the old-style multiple-invokation call > meth

[HACKERS] Remove obsolete mention of src/tools/backend

Hi, Commit 63f1ccd got rid of src/tool/backend and hence src/tool/backend/index.html. But lmgr README still directs reader to the aforementioned file. Attached removes this obsolete reference. Thanks, Amit diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README index 6bc7e

Re: [HACKERS] Broken --dry-run mode in pg_rewind

> 8 мая 2015 г., в 16:11, Stephen Frost написал(а): > > * Heikki Linnakangas (hlinn...@iki.fi ) wrote: >> On 05/08/2015 03:39 PM, Michael Paquier wrote: >>> On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas wrote: On 05/08/2015 03:25 PM, Vladimir Borodin wrote: >>>

Re: [HACKERS] subxcnt defined as signed integer in SnapshotData and SerializeSnapshotData

On 8 May 2015 at 13:02, Michael Paquier wrote: > On Fri, May 8, 2015 at 3:55 PM, Simon Riggs wrote: > > On 7 May 2015 at 21:40, Michael Paquier > wrote: > >> > >> Hi all, > >> > >> Coverity is complaining about the following assertion introduced in > >> commit 924bcf4 (parallel stuff, Serialize

Re: [HACKERS] Streaming replication and WAL archive interactions

On 04/22/2015 10:07 AM, Michael Paquier wrote: On Wed, Apr 22, 2015 at 3:38 PM, Heikki Linnakangas wrote: I feel that the best approach is to archive the last, partial segment, but with the .partial suffix. I don't see any plausible real-wold setup where the current behavior would be better. I

Re: [HACKERS] Broken --dry-run mode in pg_rewind

* Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 05/08/2015 03:39 PM, Michael Paquier wrote: > >On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas wrote: > >>On 05/08/2015 03:25 PM, Vladimir Borodin wrote: > >>>Seems, that pg_rewind does not account --dry-run option properly. A simple > >>>fix >

Re: [HACKERS] is possible to upgrade from 9.2 to 9.4 with pg_upgrade

2015-05-07 13:43 GMT+02:00 Alvaro Herrera : > The problem is here: > > > [root@ps-test5:/etc/puppet/modules/postgresql/files] pg_controldata > > /mnt/ebs/pgsql/data > > pg_control version number:922 > > Catalog version number: 201302181 > > The catversion for 9.2 is 20120

Re: [HACKERS] Broken --dry-run mode in pg_rewind

On 05/08/2015 03:39 PM, Michael Paquier wrote: On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas wrote: On 05/08/2015 03:25 PM, Vladimir Borodin wrote: Seems, that pg_rewind does not account --dry-run option properly. A simple fix for that is attached. No, the --dry-run takes effect later.

Re: [HACKERS] Broken --dry-run mode in pg_rewind

On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas wrote: > On 05/08/2015 03:25 PM, Vladimir Borodin wrote: >> Seems, that pg_rewind does not account --dry-run option properly. A simple >> fix >> for that is attached. > > > No, the --dry-run takes effect later. It performs all the actions it > nor

Re: [HACKERS] Broken --dry-run mode in pg_rewind

On 05/08/2015 03:25 PM, Vladimir Borodin wrote: Hi all. Seems, that pg_rewind does not account --dry-run option properly. A simple fix for that is attached. No, the --dry-run takes effect later. It performs all the actions it normally would, including reading files from the source, except for

[HACKERS] Broken --dry-run mode in pg_rewind

Hi all.Seems, that pg_rewind does not account --dry-run option properly. A simple fix for that is attached. pg_rewind_dry_run_fix.patch Description: Binary data --May the force be with you…https://simply.name

Re: [HACKERS] PATCH: remove nclients/nthreads constraint from pgbench

Minor v2 update to change a not badly chosen variable name. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index a808546..2517a3a 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -326,8 +326,7 @@ pgbench options dbname

Re: [HACKERS] subxcnt defined as signed integer in SnapshotData and SerializeSnapshotData

On Fri, May 8, 2015 at 3:55 PM, Simon Riggs wrote: > On 7 May 2015 at 21:40, Michael Paquier wrote: >> >> Hi all, >> >> Coverity is complaining about the following assertion introduced in >> commit 924bcf4 (parallel stuff, SerializeSnapshot@snapmgr.c): >> + Assert(snapshot->xcnt >= 0); >> >

Re: [HACKERS] Obsolete mention of src/tools/backend

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > Commit 63f1ccd got rid of src/tool/backend and hence > src/tool/backend/index.html. But lmgr README still directs reader to the > aforementioned file. Attached removes this obsolete reference. Pushed, thanks! Stephen signatu

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On 7 May 2015 at 18:37, Andres Freund wrote: > I don't see a problem at all, with one exception: If we want the AS to > be optional like in a bunch of other places, we have to either promote > VALUES to a reserved keyword, only accept unreserved keywords, or play > precedence games. I think it'd

Re: [HACKERS] commitfest app bug/feature

ISTM that an additional "Duplicate" or "To remove" status could be a tag for admins to remove the entries? This looks like an overkill to me. Entries with the same description headline mean the same thing. Sure. My point was to provide a mean to signal explicitely that an entry can be remo