Re: [HACKERS] xid wrap / optimize frozen tables?

Just FYI: We have worked around these issues by running regular (scripted and thus controlled) vaccuums on all tables but the active ones and adding L2 ZFS caching (l2arc). I hope to get back to this again soon. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] [PATCH] two-arg current_setting() with fallback

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I have reviewed the patch. Here are my review comments: 1. P

Re: [HACKERS] [PATCH] two-arg current_setting() with fallback

Hi, Attached patch which fixes my review comments. Since code changes were good, just fixed reported cosmetic changes. David, can you please cross check? Thanks -- Jeevan B Chalke Principal Software Engineer, Product Development EnterpriseDB Corporation The Enterprise PostgreSQL Company diff -

Re: [CORE] [HACKERS] postpone next week's release

On 05/30/2015 11:47 PM, Andres Freund wrote: I don't think it's primarily a problem of lack of review; although that is a large problem. I think the biggest systematic problem is that the compound complexity of postgres has increased dramatically over the years. Features have added complexity l

Re: [CORE] [HACKERS] postpone next week's release

On 2015-06-04 11:51:44 +0300, Heikki Linnakangas wrote: > I think this explanation is wrong. I agree that there are many places that > would be good to refactor - like StartupXLOG() - but the multixact code was > not too bad in that regard. IIRC the patch included some refactoring, it > added some

Re: [CORE] [HACKERS] postpone next week's release

On 06/04/2015 12:17 PM, Andres Freund wrote: On 2015-06-04 11:51:44 +0300, Heikki Linnakangas wrote: So, I'm all for refactoring and adding abstractions where it makes sense, but it's not going to solve design problems. I personally don't really see the multixact changes being that bad on the

Re: [CORE] [HACKERS] postpone next week's release

On 30 May 2015 at 05:08, Tom Lane wrote: > Robert Haas writes: > > On Fri, May 29, 2015 at 6:33 PM, Andres Freund > wrote: > >> Why? A large portion of the input required to go from beta towards a > >> release is from actual users. To see when things break, what confuses > >> them and such. > >

Re: [HACKERS] Construction of Plan-node by CSP (RE: Custom/Foreign-Join-APIs)

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > Sent: Thursday, May 28, 2015 5:35 AM > To: Robert Haas > Cc: Kaigai Kouhei(海外 浩平); Thom Brown; Kohei KaiGai; Shigeru Hanada; > pgsql-hackers@postgreSQL.org >

Re: [HACKERS] Missing "-i / --ignore-version" in pg_dump help

On Wed, Jun 3, 2015 at 1:53 AM, Fujii Masao wrote: > On Fri, May 22, 2015 at 11:01 PM, Tom Lane wrote: >> Fujii Masao writes: >>> On Fri, May 22, 2015 at 8:59 PM, Fabrízio de Royes Mello >>> wrote: There are some reason to "-i, --ignore-version" option doesn't appear in pg_dump help?

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, Jun 4, 2015 at 10:14 AM, Amit Kapila wrote: > On Thu, Jun 4, 2015 at 1:52 AM, Andrew Dunstan > wrote: > >> >> On 06/02/2015 11:55 PM, Amit Kapila wrote: >> >> On Tue, Jun 2, 2015 at 10:26 PM, Andrew Dunstan >> > wrote: >>> >>> Well, it seems to me the new

Re: [HACKERS] Memory leak with XLogFileCopy since de768844 (WAL file with .partial)

On Mon, Jun 1, 2015 at 4:24 PM, Michael Paquier wrote: > On Thu, May 28, 2015 at 9:09 PM, Michael Paquier > wrote: >> Since commit de768844, XLogFileCopy of xlog.c returns to caller a >> pstrdup'd string that can be used afterwards for other things. >> XLogFileCopy is used in only one place, and

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Thu, Jun 4, 2015 at 2:42 AM, Noah Misch wrote: > I like that change a lot. It's much easier to seek forgiveness for wasting <= > 28 GiB of disk than for deleting visibility information wrongly. I'm glad you like it. I concur. >> 2. If setting the offset stop limit (the point where we refuse

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 06/03/2015 10:02 PM, Peter Geoghegan wrote: I've noticed some more issues with the jsonb documentation, and the new jsonb stuff generally. I didn't set out to give Andrew feedback on the semantics weeks after feature freeze, but unfortunately this feels like another discussion that we need to

Re: [HACKERS] RFC: Remove contrib entirely

On Fri, May 29, 2015 at 10:30 AM, Stephen Frost wrote: > That work will be much less if we simply split what's in contrib now > into extension and contrib directories, as it's still all one source > repo to the packagers. If we punt things out (unless they're being > formally deprecated/removed)

Re: [HACKERS] [CORE] Restore-reliability mode

Josh, * Josh Berkus (j...@agliodbs.com) wrote: > I would argue that if we delay 9.5 in order to do a 100% manual review > of code, without adding any new automated tests or other non-manual > tools for improving stability, then it's a waste of time; we might as > well just release the beta, and ou

[HACKERS] Dependency between bgw_notify_pid and bgw_flags

Hi, Documentation here http://www.postgresql.org/docs/devel/static/bgworker.html does not indicate any relation between the fields bgw_notify_pid and bgw_flags of BackgroundWorker structure. But in one has to set BGWORKER_BACKEND_DATABASE_CONNECTION in order to use bgw_notify_pid feature. In Backg

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On 06/04/2015 12:44 AM, Amit Kapila wrote: Given that the function raises an error on failure, I think it will otherwise be OK as is. Please find an updated patch attached with this mail. No attachment. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 10:34 AM, Robert Haas wrote: For what it's worth, I also don't particularly support renaming contrib. I don't really see that it buys us enough to justify the hassle it will cause. One thing that may be worth doing yet is separating the code that is just intended as a POC (lik

Re: [HACKERS] RFC: Remove contrib entirely

On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan wrote: > The biggest problem is that packagers tend just to bundle contrib together > in one lump. If we could divide it into two, something like "standard > modules" and "misc", with the former being included with the server package, > I think that

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 6/4/15 8:43 AM, Andrew Dunstan wrote: You are conflating two different things here, quite pointlessly. The RH operand of ?| is not a path, whereas the RH operand of this - variant is. The fact that they are both text arrays doesn't mean that they should mean the same thing. And this is really

Re: [HACKERS] Streaming replication for psycopg2

On Tue, Jun 2, 2015 at 2:23 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > Hello, > > I've submitted a patch to psycopg2 to support streaming replication protocol (COPY_BOTH): https://github.com/psycopg/psycopg2/pull/322 > > It would be great if more people had a chance to take a

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 07:34 AM, Robert Haas wrote: I don't think it's very practical to talk about getting rid of contrib when we reliably add to it in every release: Except, that is kind of the point. Why are we adding to it? Contrib (AFAICS) is all things that don't need to be in -core. That is th

Re: [HACKERS] RFC: Remove contrib entirely

On 6/4/15 10:30 AM, Robert Haas wrote: On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan wrote: >The biggest problem is that packagers tend just to bundle contrib together >in one lump. If we could divide it into two, something like "standard >modules" and "misc", with the former being included w

Re: [HACKERS] RFC: Remove contrib entirely

Robert Haas writes: > On Thu, Jun 4, 2015 at 11:22 AM, Andrew Dunstan wrote: >> The biggest problem is that packagers tend just to bundle contrib together >> in one lump. If we could divide it into two, something like "standard >> modules" and "misc", with the former being included with the serve

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 11:49 AM, Joshua D. Drake wrote: On 06/04/2015 07:34 AM, Robert Haas wrote: I don't think it's very practical to talk about getting rid of contrib when we reliably add to it in every release: Except, that is kind of the point. Why are we adding to it? Contrib (AFAICS) is all

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 09:00 AM, Andrew Dunstan wrote: No. You keep getting this wrong. The fact that we have extensions doesn't mean that we want to throw out everything that is an extension. It's perfectly reasonable for us to maintain some ourselves, not least as part of eating out own dog food. Y

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Tom Lane wrote: >> Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact >> so it does not explain whatever is happening on chipmunk. > Ah, thanks for diagnosing that. > The chipmunk failure is strange -- notice it only references the > = operators, excep

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 08:55 AM, Jim Nasby wrote: Personally, I'd rather we publish a list of formally vetted and approved versions of PGXN modules. There are many benefits to that, and the downside of not having that stuff as part of make check would be overcome by the explicit testing we would need to

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > Actually not --- if you browse through the last half dozen failures > on chipmunk you will notice that > > (1) the set of operators complained of varies a bit from one failure > to the next; > > (2) more often than not, this is one of the failures: > > WARNING: no results for

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera wrote: > Hm. Well, what this message says is that we ran that query using > both BRIN and seqscan, and that in both cases no row was returned. Note > that if the BRIN and seqscan cases had returned different sets of rows, > the error message would have been different. So this mig

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Thu, Jun 4, 2015 at 9:42 AM, Robert Haas wrote: > Thanks for the review. Here's a new version. I've fixed the things Alvaro and Noah noted, and some compiler warnings about set but unused variables. I also tested it, and it doesn't quite work as hoped. If started on a cluster where oldestMu

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Evidently there is a problem right there. If I simply add an "order by > tenthous" as proposed by Peter, many more errors appear; and what errors > appear differs if I change shared_buffers. I think the real fix for > this is to change the hand-picked values used in the

Re: [HACKERS] brin regression test intermittent failures

I wrote: > I think it would be a good idea to extend the brinopers table to include > the number of expected matches, and to complain if that's not what we got, > rather than simply checking for zero. Also, further experimentation shows that there are about 30 entries in the brinopers table that g

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > Alvaro Herrera writes: > > Evidently there is a problem right there. If I simply add an "order by > > tenthous" as proposed by Peter, many more errors appear; and what errors > > appear differs if I change shared_buffers. I think the real fix for > > this is to change the hand-

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > I wrote: > > I think it would be a good idea to extend the brinopers table to include > > the number of expected matches, and to complain if that's not what we got, > > rather than simply checking for zero. > > Also, further experimentation shows that there are about 30 entries i

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 06/04/2015 11:33 AM, Jim Nasby wrote: On 6/4/15 8:43 AM, Andrew Dunstan wrote: You are conflating two different things here, quite pointlessly. The RH operand of ?| is not a path, whereas the RH operand of this - variant is. The fact that they are both text arrays doesn't mean that they shou

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Tom Lane wrote: >> I may be confused, but why would the physical ordering of the table >> entries make a difference to the correct answers for this test? >> (I can certainly see why that might break the brin code, but not >> why it should change the seqscan's answers.) >

Re: [HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Hi, On 2015-06-04 12:57:42 -0400, Robert Haas wrote: > + /* > + * Do we need an emergency autovacuum? If we're not sure, assume yes. > + */ > + return !oldestOffsetKnown || > + (nextOffset - oldestOffset > MULTIXACT_MEMBER_SAFE_THRESHOLD); I think without teaching a

Re: [HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Thu, Jun 4, 2015 at 1:27 PM, Andres Freund wrote: > On 2015-06-04 12:57:42 -0400, Robert Haas wrote: >> + /* >> + * Do we need an emergency autovacuum? If we're not sure, assume yes. >> + */ >> + return !oldestOffsetKnown || >> + (nextOffset - oldestOffset > MULTI

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Tom Lane wrote: >> Also, further experimentation shows that there are about 30 entries in the >> brinopers table that give rise to seqscan plans even when we're commanding >> a bitmap scan, presumably because those operators aren't brin-indexable. >> They're not the proble

Re: [HACKERS] RFC: Remove contrib entirely

On Thu, Jun 4, 2015 at 11:49 AM, Joshua D. Drake wrote: > Except, that is kind of the point. Why are we adding to it? If you don't know the answer to that question already, then you probably shouldn't be proposing to get rid of the thing. I think it's because there are some things we want to inc

Re: [HACKERS] Minor issue with BRIN regression tests

Peter Geoghegan writes: > Attached patch adjusts BRIN regression tests to make a non-obvious > dependency on tuple order explicit. Currently, an index-only scan plan > is used by the query that I've adjusted. I'd rather be sure that that > continues. Applied with a correction: the ordering that w

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 10:34 AM, Robert Haas wrote: On Thu, Jun 4, 2015 at 11:49 AM, Joshua D. Drake wrote: Except, that is kind of the point. Why are we adding to it? If you don't know the answer to that question already, then you probably shouldn't be proposing to get rid of the thing. I know t

Re: [HACKERS] RFC: Remove contrib entirely

On Thu, Jun 4, 2015 at 1:57 PM, Joshua D. Drake wrote: >> I think it's because there are some things we want to include in the >> core distribution without baking them irrevocably into the server. > > I have mentioned before isn't really what this discussion is about. Stephen > Frost and I even we

Re: [HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Alvaro Herrera wrote: > Robert Haas wrote: > > > So here's a patch taking a different approach. > > I tried to apply this to 9.3 but it's messy because of pgindent. Anyone > would have a problem with me backpatching a pgindent run of multixact.c? Done. -- Álvaro Herrerahttp://

Re: [HACKERS] RFC: Remove contrib entirely

On 06/04/2015 11:01 AM, Robert Haas wrote: On Thu, Jun 4, 2015 at 1:57 PM, Joshua D. Drake wrote: I think it's because there are some things we want to include in the core distribution without baking them irrevocably into the server. I have mentioned before isn't really what this discussion

Re: [HACKERS] xid wrap / optimize frozen tables?

On Wed, Jun 3, 2015 at 2:49 PM, Jeff Janes wrote: > I would not be surprised if it were the reading, not the writing, which > caused the performance problem. > Of course I screwed up that last sentence. I meant the opposite, it would not surprise me if it were the writing that caused the proble

Re: [HACKERS] RFC: Remove contrib entirely

On 2015-06-04 11:33:47 -0700, Joshua D. Drake wrote: > My argument was (after some preliminary discussion): > > 1. Review contrib > 2. All modules that are "core worthy" install by default > 3. Push all other contrib out into the wild > > Possibly: > > 1. Have a contrib project that sat outside

Re: [HACKERS] RFC: Remove contrib entirely

On 2015-06-04 20:41:46 +0200, Andres Freund wrote: > > 1. 15 years of the same argument (current source: pg_audit) > > I don't see getting rid of contrib helping with that. The only change > will then be whether something should be in core. > > And there's stuff that's just very hard to develop o

Re: [HACKERS] RFC: Remove contrib entirely

> On Jun 4, 2015, at 10:55 AM, Jim Nasby wrote: > > Personally, I'd rather we publish a list of formally vetted and approved > versions of PGXN modules. There are many benefits to that, and the downside > of not having that stuff as part of make check would be overcome by the > explicit testi

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Thu, Jun 4, 2015 at 6:43 AM, Andrew Dunstan wrote: >> I've noticed some more issues with the jsonb documentation, and the >> new jsonb stuff generally. I didn't set out to give Andrew feedback on >> the semantics weeks after feature freeze, but unfortunately this feels >> like another discussio

Re: [HACKERS] Further issues with jsonb semantics, documentation

I'm just skimming here, but if a jsonb_path type is being proposed, perhaps it would be better not to have operators that take text or text[] as second argument. We can provide that functionality with just functions. For example, it will be confusing to have jsonb 'some json value' - '{foo,bar}

Re: [HACKERS] brin regression test intermittent failures

I wrote: > The other cases that I found involve cidrcol, and seem to represent > an actual bug in the brin planning logic, ie failure to disregard a > no-op cast. I'll look closer. I leapt to the wrong conclusion on that one. The reason for failure to match to an index column had nothing to do w

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > I wrote: > > The other cases that I found involve cidrcol, and seem to represent > > an actual bug in the brin planning logic, ie failure to disregard a > > no-op cast. I'll look closer. > > I leapt to the wrong conclusion on that one. The reason for failure to > match to an in

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Thu, Jun 4, 2015 at 12:16 PM, Alvaro Herrera wrote: > I'm just skimming here, but if a jsonb_path type is being proposed, > perhaps it would be better not to have operators that take text or > text[] as second argument. We can provide that functionality with just > functions. For example, it

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Thu, Jun 4, 2015 at 1:02 PM, Peter Geoghegan wrote: > I would like these new-to-9.5 deletion operators to work at the top > level only, like "operator jsonb ? text" and "operator jsonb ?| text", > sharing their idea of a key, __including that string array elements > are keys__. We haven't got a

Re: [HACKERS] Publish autovacuum informations

2015-01-05 17:44 GMT+01:00 Guillaume Lelarge : > 2015-01-05 17:40 GMT+01:00 Robert Haas : > >> On Wed, Dec 31, 2014 at 12:46 PM, Tom Lane wrote: >> > I'd be all right with putting the data structure declarations in a file >> > named something like autovacuum_private.h, especially if it carried an

Re: [HACKERS] RFC: Remove contrib entirely

On Jun 4, 2015, at 11:53 AM, Neil Tiffin wrote: > I have looked at PGXN and would never install anything from it. Why? > Because it is impossible to tell, without inside knowledge or a lot of work, > what is actively maintained and tested, and what is an abandoned > proof-of-concept or idea.

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Jun 4, 2015, at 12:16 PM, Alvaro Herrera wrote: > I'm just skimming here, but if a jsonb_path type is being proposed, Is this not the purpose of JSQuery? https://code.google.com/p/gwtquery/wiki/JsQuery David smime.p7s Description: S/MIME cryptographic signature

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Thu, Jun 4, 2015 at 12:57 PM, Robert Haas wrote: > On Thu, Jun 4, 2015 at 9:42 AM, Robert Haas wrote: >> Thanks for the review. > > Here's a new version. I've fixed the things Alvaro and Noah noted, > and some compiler warnings about set but unused variables. > > I also tested it, and it does

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Thu, Jun 4, 2015 at 5:29 PM, Robert Haas wrote: > - Forces aggressive autovacuuming when the control file's > oldestMultiXid doesn't point to a valid MultiXact and enables member > wraparound at the next checkpoint following the correction of that > problem. Err, enables member wraparound *pro

Re: [HACKERS] [idea] more aggressive join pushdown on postgres_fdw

On Sat, May 30, 2015 at 9:03 PM, Kouhei Kaigai wrote: > Yesterday, JPUG held an unconference event at Tokyo, and > Hanada-san had a talk about join-pushdown feature of > postgres_fdw. > At this talk, someone proposed an interesting idea to > make join pushdown more aggressive/effective. > Let me s

Re: [HACKERS] Minor improvement to func.sgml

On Mon, Jun 1, 2015 at 10:44 PM, Etsuro Fujita wrote: > Here is a doc patch to add materialized views and foreign tables to > database objects that pg_table_is_visible() can be used with. Good catch, as usual. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise P

Re: [HACKERS] [PATCH] Fix documentation bug in how to calculate the quasi-unique pg_log session_id

On Tue, Jun 2, 2015 at 11:22 AM, Joel Jacobson wrote: > Fix documentation bug in how to calculate the quasi-unique pg_log session_id Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Fri, Jun 5, 2015 at 9:29 AM, Robert Haas wrote: > Here's a new version with some more fixes and improvements: > > - SetOffsetVacuumLimit was failing to set MultiXactState->oldestOffset > when the oldest offset became known if the now-known value happened to > be zero. Fixed. > > - SetOffsetVac

Re: [HACKERS] [CORE] Restore-reliability mode

On 4 June 2015 at 22:43, Stephen Frost wrote: > Josh, > > * Josh Berkus (j...@agliodbs.com) wrote: > > I would argue that if we delay 9.5 in order to do a 100% manual review > > of code, without adding any new automated tests or other non-manual > > tools for improving stability, then it's a wast

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 06/04/2015 04:13 PM, David E. Wheeler wrote: On Jun 4, 2015, at 12:16 PM, Alvaro Herrera wrote: I'm just skimming here, but if a jsonb_path type is being proposed, Is this not the purpose of JSQuery? https://code.google.com/p/gwtquery/wiki/JsQuery No, it doesn't seem to have anyth

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 06/04/2015 03:10 PM, Peter Geoghegan wrote: On Thu, Jun 4, 2015 at 6:43 AM, Andrew Dunstan wrote: I've noticed some more issues with the jsonb documentation, and the new jsonb stuff generally. I didn't set out to give Andrew feedback on the semantics weeks after feature freeze, but unfortun

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Thu, Jun 4, 2015 at 12:10 PM, Peter Geoghegan wrote: > jsonb_delete() should certainly be able to traverse objects, but it's > much less clear that it should be able to *traverse* arrays (affecting > arrays is a different story, though). That's why I proposed not > supporting traversing arrays

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Thu, Jun 4, 2015 at 5:31 PM, Andrew Dunstan wrote: > Just in case it's not clear: I am not at all happy. I've offered to help you with several of the issue I raised; I had intended to offer more help. The issues I raise seem pretty substantive to me. I'm trying to make sure that we don't end

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, Jun 4, 2015 at 8:43 PM, Andrew Dunstan wrote: > > On 06/04/2015 12:44 AM, Amit Kapila wrote: > >> >> Given that the function raises an error on failure, I think it >> will otherwise be OK as is. >> >> >> Please find an updated patch attached with this mail. >> >> >> > > No attachm

Re: [HACKERS] [idea] more aggressive join pushdown on postgres_fdw

> On Sat, May 30, 2015 at 9:03 PM, Kouhei Kaigai wrote: > > Yesterday, JPUG held an unconference event at Tokyo, and > > Hanada-san had a talk about join-pushdown feature of > > postgres_fdw. > > At this talk, someone proposed an interesting idea to > > make join pushdown more aggressive/effective

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Fri, Jun 5, 2015 at 11:47 AM, Thomas Munro wrote: > On Fri, Jun 5, 2015 at 9:29 AM, Robert Haas wrote: >> Here's a new version with some more fixes and improvements: >> >> - SetOffsetVacuumLimit was failing to set MultiXactState->oldestOffset >> when the oldest offset became known if the now-k

Re: [HACKERS] [idea] more aggressive join pushdown on postgres_fdw

On Thu, Jun 4, 2015 at 9:40 PM, Kouhei Kaigai wrote: >> Neat idea. This ties into something I've thought about and mentioned >> before: what if the innerrel is local, but there's a replicated copy >> on the remote server? Perhaps both cases are worth thinking about at >> some point. >> > I think

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On 06/04/2015 09:23 AM, Amit Kapila wrote: Okay, as we both seem to agree that it can be mostly used in tablespace symlinks context, so I have changed the name to remove_tablespace_symlink() and moved the function to tablespace.c. S_ISLINK check is used for non-windows code,

[HACKERS] Incorrect order of database-locking operations in InitPostgres()

I've been chasing the intermittent "cache lookup failed for access method 403" failure at session startup that's been seen lately in the buildfarm, for instance here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2015-06-04%2019%3A22%3A46 (Axolotl has shown this 3 times in the

Re: [HACKERS] [idea] more aggressive join pushdown on postgres_fdw

> On Thu, Jun 4, 2015 at 9:40 PM, Kouhei Kaigai wrote: > >> Neat idea. This ties into something I've thought about and mentioned > >> before: what if the innerrel is local, but there's a replicated copy > >> on the remote server? Perhaps both cases are worth thinking about at > >> some point. >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Fri, Jun 5, 2015 at 7:29 AM, Andrew Dunstan wrote: > > On 06/04/2015 09:23 AM, Amit Kapila wrote: > >> >> >> >> Okay, as we both seem to agree that it can be mostly used in >> tablespace symlinks context, so I have changed the name to >> remove_tablespace_symlink() and moved the fu

Re: [HACKERS] Memory leak with XLogFileCopy since de768844 (WAL file with .partial)

On Thu, Jun 4, 2015 at 10:40 PM, Fujii Masao wrote: > On Mon, Jun 1, 2015 at 4:24 PM, Michael Paquier > wrote: > > On Thu, May 28, 2015 at 9:09 PM, Michael Paquier > > wrote: > >> Since commit de768844, XLogFileCopy of xlog.c returns to caller a > >> pstrdup'd string that can be used afterwards

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On 06/04/2015 11:35 PM, Amit Kapila wrote: On Fri, Jun 5, 2015 at 7:29 AM, Andrew Dunstan > wrote: On 06/04/2015 09:23 AM, Amit Kapila wrote: Okay, as we both seem to agree that it can be mostly used in tablespace symlinks context, so

Re: [HACKERS] [CORE] Restore-reliability mode

On Fri, Jun 5, 2015 at 8:53 AM, Craig Ringer wrote: > > > On 4 June 2015 at 22:43, Stephen Frost wrote: >> >> Josh, >> >> * Josh Berkus (j...@agliodbs.com) wrote: >> > I would argue that if we delay 9.5 in order to do a 100% manual review >> > of code, without adding any new automated tests or ot

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Fri, Jun 5, 2015 at 9:57 AM, Andrew Dunstan wrote: > > On 06/04/2015 11:35 PM, Amit Kapila wrote: > >> >> Theoretically, I don't see much problem by changing the checks >> way you have done in patch, but it becomes different than what >> we have in destroy_tablespace_directories() and it is sl

[HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Thu, Jun 04, 2015 at 05:29:51PM -0400, Robert Haas wrote: > Here's a new version with some more fixes and improvements: I read through this version and found nothing to change. I encourage other hackers to study the patch, though. The surrounding code is challenging. > With this version, I'm

Re: [HACKERS] [CORE] Restore-reliability mode

On 3 June 2015 at 18:21, Josh Berkus wrote: > I would argue that if we delay 9.5 in order to do a 100% manual review > of code, without adding any new automated tests or other non-manual > tools for improving stability, then it's a waste of time; we might as > well just release the beta, and our