Re: [HACKERS] RFC: Remove contrib entirely

On Fri, May 29, 2015 at 3:20 PM, Guillaume Lelarge wrote: > Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit : >> >> Hi >> >> I am not sure if PGXN can substitute contrib - mainly due deployment - It >> doesn't helps with MS Windows. Installing necessary software for compilation >> there is terrib

Re: [HACKERS] RFC: Remove contrib entirely

2015-05-29 8:20 GMT+02:00 Guillaume Lelarge : > Le 29 mai 2015 8:10 AM, "Pavel Stehule" a > écrit : > > > > Hi > > > > I am not sure if PGXN can substitute contrib - mainly due deployment - > It doesn't helps with MS Windows. Installing necessary software for > compilation there is terrible. > >

Re: [HACKERS] RFC: Remove contrib entirely

Le 29 mai 2015 8:01 AM, "Fabien COELHO" a écrit : > > >> FWIW, I don't mind which one we put in core and which one we put out of >> core. But I like Joshua's idea of getting rid of contribs and pushing them >> out as any other extensions. > > > Hmmm. > > I like the contrib directory as a living ex

Re: [HACKERS] RFC: Remove contrib entirely

Le 29 mai 2015 8:10 AM, "Pavel Stehule" a écrit : > > Hi > > I am not sure if PGXN can substitute contrib - mainly due deployment - It doesn't helps with MS Windows. Installing necessary software for compilation there is terrible. > I agree it's hard to compile an extension on Windows, but that's

Re: [HACKERS] RFC: Remove contrib entirely

Hi I am not sure if PGXN can substitute contrib - mainly due deployment - It doesn't helps with MS Windows. Installing necessary software for compilation there is terrible. Regards Pavel 2015-05-28 18:19 GMT+02:00 Joshua D. Drake : > > Hello, > > This is a topic that has come up in various way

Re: [HACKERS] RFC: Remove contrib entirely

FWIW, I don't mind which one we put in core and which one we put out of core. But I like Joshua's idea of getting rid of contribs and pushing them out as any other extensions. Hmmm. I like the contrib directory as a living example of "how to do an extension" directly available in the source

Re: [HACKERS] RFC: Remove contrib entirely

Le 29 mai 2015 5:33 AM, "Joshua D. Drake" a écrit : > > > On 05/28/2015 08:10 PM, Stephen Frost wrote: >> >> JD, > > This seems reasonable to me. It's in line with the recent move from contrib to bin. It'll just be quite a bit bigger of an undertaking. (50 threads to discuss the m

Re: [HACKERS] hstore_plpython regression test does not work on Python 3

29.05.2015, 03:12, Peter Eisentraut kirjoitti: > On 5/26/15 5:19 PM, Oskari Saarenmaa wrote: >>> [1] http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguarundi&br=HEAD >> >> Looks like that animal uses Python 3.4. Python 3.3 and newer versions >> default to using a random seed for hashing object

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Abhijit Menon-Sen writes: >> I have to leave shortly, so I'll look at the initdb cleanup tomorrow. > Here's a revision of that patch that's more along the lines of what you > committed. Will look at that tomorrow ... > It occurred to me that we should probably also silently skip EACCES on > ope

Re: [HACKERS] useless assignment pointer argument

Andres Freund writes: > On 2015-05-28 20:14:33 +, Gaetano Mendola wrote: >> src/backend/commands/explain.c:1692 >> src/backend/commands/explain.c:1874 >> src/backend/commands/explain.c:1986 >> >> there is the following assignment: >> >> ancestors = list_delete_first(ancestors); >> >> but it

Re: [HACKERS] auto_explain sample rate

Craig Ringer writes: > It's sometimes desirable to collect auto_explain data with ANALYZE in order > to track down hard-to-reproduce issues, but the performance impacts can be > pretty hefty on the DB. > I'm inclined to add a sample rate to auto_explain so that it can trigger > only on x percent

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 08:10 PM, Stephen Frost wrote: JD, This seems reasonable to me. It's in line with the recent move from contrib to bin. It'll just be quite a bit bigger of an undertaking. (50 threads to discuss the merits of each module separately?) Maybe start by picking the top 5 and sort t

Re: [HACKERS] hstore_plpython regression test does not work on Python 3

Peter Eisentraut writes: > On 5/26/15 5:19 PM, Oskari Saarenmaa wrote: >> Looks like that animal uses Python 3.4. Python 3.3 and newer versions >> default to using a random seed for hashing objects into dicts which >> makes the order of dict elements random; see >> https://docs.python.org/3/using

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

On Thu, May 28, 2015 at 10:41 PM, Alvaro Herrera wrote: >> 2. If you pg_upgrade to 9.3.7 or 9.4.2, then you may have datminmxid >> values which are equal to the next-mxid counter instead of the correct >> value; in other words, they are too new. > > [ discussion of how the control file's oldestMul

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-28 17:37:16 -0400, t...@sss.pgh.pa.us wrote: > > I've committed this after some mostly-cosmetic rearrangements. Thank you. > I have to leave shortly, so I'll look at the initdb cleanup tomorrow. Here's a revision of that patch that's more along the lines of what you committed. It occ

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

Alvaro Herrera wrote: > Robert Haas wrote: > > > 2. If you pg_upgrade to 9.3.7 or 9.4.2, then you may have datminmxid > > values which are equal to the next-mxid counter instead of the correct > > value; in other words, they are too new. > > What you describe is what happens if you upgrade from 9

Re: [HACKERS] RFC: Remove contrib entirely

JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > On 05/28/2015 06:50 PM, Peter Eisentraut wrote: > >On 5/28/15 3:35 PM, Stephen Frost wrote: > >>What we would need for this is an 'extensions' directory, or similar, > >>and a clear definition of what the requirements are around getting into

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

Robert Haas wrote: > 2. If you pg_upgrade to 9.3.7 or 9.4.2, then you may have datminmxid > values which are equal to the next-mxid counter instead of the correct > value; in other words, they are too new. What you describe is what happens if you upgrade from 9.2 or earlier. For this case we use

Re: [HACKERS] RFC: Remove contrib entirely

On 2015-05-29 AM 11:14, Joshua D. Drake wrote: > > pg_trgm has been in contrib for a decade of not more. Either rip it out or > include it by default. > There are jsonb gin operator class related files in src/backend/utils/adt/. Perhaps, trgm_gin.c, trgm_gist.c, trgm_op.c could be moved there. S

[HACKERS] [PATCH] Document that directly callable functions may use fn_extra

Hi all I was a puzzled by src/backend/utils/fmgr/README and fmgr.h's descriptions of fcinfo->flinfo->fn_extra (FmgrInfo.fn_extra) as they seem to conflict with actual usage. The docs suggest that fl_extra is for the use of function call handlers, but in practice it's also used heavily by functio

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 06:50 PM, Peter Eisentraut wrote: On 5/28/15 3:35 PM, Stephen Frost wrote: What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module currently i

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 06:25 PM, Andrew Dunstan wrote: I'd be ok with installing it by default. But the case that's a lot harder to require to be always installed is pgcrypto, as has often been discussed in the past. It used to be but IIRC we don't have those restrictions anymore. If so, then we n

Re: [HACKERS] RFC: Remove contrib entirely

On 5/28/15 3:35 PM, Stephen Frost wrote: > What we would need for this is an 'extensions' directory, or similar, > and a clear definition of what the requirements are around getting into > it are. With that, we could decide for each module currently in contrib > if it should go into the 'extension

[HACKERS] auto_explain sample rate

Hi all It's sometimes desirable to collect auto_explain data with ANALYZE in order to track down hard-to-reproduce issues, but the performance impacts can be pretty hefty on the DB. I'm inclined to add a sample rate to auto_explain so that it can trigger only on x percent of queries, and also add

Re: [HACKERS] Free indexed_tlist memory explicitly within set_plan_refs()

On Thu, May 28, 2015 at 2:37 PM, Peter Geoghegan wrote: > A second attached patch fixes another, largely independent bug. I > noticed array assignment with ON CONFLICT DO UPDATE was broken. See > commit message for full details. Finally, here is a third patch, fixing the final bug that I discusse

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 04:22 PM, Joshua D. Drake wrote: On 05/28/2015 01:11 PM, Andrew Dunstan wrote: This seems to come up regularly. Maybe we should put it in an FAQ somewhere. The barriers to making non-core types into core types are very very high, possibly insurmountable. This is pretty much not

Re: [HACKERS] pg_upgrade resets timeline to 1

On 29/05/15 12:59, Noah Misch wrote: On Thu, May 28, 2015 at 05:26:56PM +0200, Christoph Berg wrote: Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com> To clarify for the archives, the 2015-05-16 changes did not revert to 9.3 and earlier behavior. Rather, they standardiz

Re: [HACKERS] [PATCH] readlink missing nul-termination in pg_rewind

On Fri, May 29, 2015 at 1:46 AM, Tom Lane wrote: > Abhijit Menon-Sen writes: >> P.S. Also in passing, I note that pg_rewind will follow links under any >> directory anywhere named pg_tblspc (which probably doesn't matter), and >> does not follow pg_xlog if it's a symlink (which probably does). If

Re: [HACKERS] pg_upgrade resets timeline to 1

On Thu, May 28, 2015 at 05:26:56PM +0200, Christoph Berg wrote: > Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com> > > To clarify for the archives, the 2015-05-16 changes did not revert to 9.3 > > and > > earlier behavior. Rather, they standardized on the > > {9.0,9.1,9.

Re: [HACKERS] Patch to improve a few appendStringInfo* calls

On 5/12/15 4:33 AM, David Rowley wrote: > Shortly after I sent the previous patch I did a few more searches and > also found some more things that are not quite right. > Most of these are to use the binary append method when the length of the > string is already known. For these cases it might be

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Tue, May 26, 2015 at 10:06:59PM -0400, Robert Haas wrote: > On Sat, May 23, 2015 at 8:14 PM, Noah Misch wrote: > > On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote: > >> A protocol extension avoids all of that trouble, and can be target for > >> 9.6 just like any other approach we mi

Re: [HACKERS] hstore_plpython regression test does not work on Python 3

On 5/26/15 5:19 PM, Oskari Saarenmaa wrote: >> [1] http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguarundi&br=HEAD > > Looks like that animal uses Python 3.4. Python 3.3 and newer versions > default to using a random seed for hashing objects into dicts which > makes the order of dict element

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

On Thu, May 28, 2015 at 4:06 PM, Joshua D. Drake wrote: > FTR: Robert, you have been a Samurai on this issue. Our many thanks. Thanks! I really appreciate the kind words. So, in thinking through this situation further, it seems to me that the situation is pretty dire: 1. If you pg_upgrade to 9

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

On Fri, May 29, 2015 at 7:56 AM, Robert Haas wrote: > On Thu, May 28, 2015 at 8:51 AM, Robert Haas wrote: >> [ speculation ] > > [...] However, since > the vacuum did advance relfrozenxid, it will call vac_truncate_clog, > which will call SetMultiXactIdLimit, which will propagate the bogus > dat

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

Robert Haas wrote: > On Thu, May 28, 2015 at 8:51 AM, Robert Haas wrote: > > [ speculation ] > > OK, I finally managed to reproduce this, after some off-list help from > Steve Kehlet (the reporter), Alvaro, and Thomas Munro. Here's how to > do it: It's a long list of steps, but if you consider

Re: [HACKERS] Free indexed_tlist memory explicitly within set_plan_refs()

On Sun, May 24, 2015 at 6:17 PM, Peter Geoghegan wrote: > Attached patch adds such a pfree() call. Attached, revised version incorporates this small fix, while adding an additional big fix, and a number of small style tweaks. This is mainly concerned with fixing the bug I was trying to fix when

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Abhijit Menon-Sen writes: > Here's an updated patch for the fsync problem(s). I've committed this after some mostly-cosmetic rearrangements. > 4. As a partial aside, why does fsync_fname use OpenTransientFile? It >looks like it should use BasicOpenFile as pre_sync_fname does. We >close t

Re: [HACKERS] PGCon hacker lounge

On 5/28/15 9:43 AM, Dan Langille wrote: It seems it goes unused, and I was trying to see if anyone found it useful in the past. At BSDCan, for example, you can find people there every night discussing and working. Or perhaps just socializing. It's a major gathering point. ISTM that essential

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

On 5/22/15 6:35 AM, Pavel Stehule wrote: > we support SET ROLE name and SET ROLE TO name. Second form isn't > supported by tabcomplete. Attached trivial patch fixes it. We don't tab-complete everything we possibly could. The documentation only lists the first form, so I don't think we necessarily

Re: [HACKERS] useless assignment pointer argument

If the compiler is good the assignment is elided indeed, that's not what I meant to point out. On Thu, 28 May 2015 at 22:17 Andres Freund wrote: > On 2015-05-28 20:14:33 +, Gaetano Mendola wrote: > > src/backend/commands/explain.c:1692 > > src/backend/commands/explain.c:1874 > > src/backend/

Re: [HACKERS] Possible pointer dereference

While at it the assert(cnfa != NULL && cnfa->nstates != 0); at src/backend/regex/rege_dfa.c:282 is issued too late indeed at line 278 and 279 cnfa was already dereferenced. Same for assert(t != NULL) in src/backend/regex/regexec.c:821 is issued way too late. On Thu, 28 May 2015 at 15:59 Tom

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 01:11 PM, Andrew Dunstan wrote: This seems to come up regularly. Maybe we should put it in an FAQ somewhere. The barriers to making non-core types into core types are very very high, possibly insurmountable. This is pretty much not an option. O.k., then either: * We install i

Re: [HACKERS] useless assignment pointer argument

On 2015-05-28 20:14:33 +, Gaetano Mendola wrote: > src/backend/commands/explain.c:1692 > src/backend/commands/explain.c:1874 > src/backend/commands/explain.c:1986 > > there is the following assignment: > >ancestors = list_delete_first(ancestors); > > but it has no effect at all being tha

[HACKERS] useless assignment pointer argument

Hi, in the following spots: src/backend/commands/explain.c:1692 src/backend/commands/explain.c:1874 src/backend/commands/explain.c:1986 there is the following assignment: ancestors = list_delete_first(ancestors); but it has no effect at all being that a function parameter and not used anymor

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 04:05 PM, Joshua D. Drake wrote: On 05/28/2015 12:35 PM, Stephen Frost wrote: JD, What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module c

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

On 05/28/2015 12:56 PM, Robert Haas wrote: FTR: Robert, you have been a Samurai on this issue. Our many thanks. Sincerely, jD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended"

Re: [HACKERS] RFC: Remove contrib entirely

On 05/28/2015 12:35 PM, Stephen Frost wrote: JD, What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module currently in contrib if it should go into the 'ext

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

On Thu, May 28, 2015 at 8:51 AM, Robert Haas wrote: > [ speculation ] OK, I finally managed to reproduce this, after some off-list help from Steve Kehlet (the reporter), Alvaro, and Thomas Munro. Here's how to do it: 1. Install any pre-9.3 version of the server and generate enough multixacts to

Re: [HACKERS] Improving GEQO

On Fri, May 29, 2015 at 12:59 AM, Merlin Moncure wrote: > On Wed, May 27, 2015 at 3:06 PM, boix wrote: > > Hello, my partner and me are working with the goal of improve the GEQO's > > performance, we tried with Ant Colony Optimization, but it does not > improve, > > actually we are trying with a

Re: [HACKERS] RFC: Remove contrib entirely

JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > Contrib according to the docs is: > > "These include porting tools, analysis utilities, and plug-in > features that are not part of the core PostgreSQL system, mainly > because they address a limited audience or are too experimental to > be

Re: [HACKERS] Improving GEQO

On Wed, May 27, 2015 at 3:06 PM, boix wrote: > Hello, my partner and me are working with the goal of improve the GEQO's > performance, we tried with Ant Colony Optimization, but it does not improve, > actually we are trying with a new variant of Genetic Algorithm, specifically > Micro-GA. This alg

Re: [HACKERS] Improving GEQO

We follow your advice, our goal is improve the quality of the solution and we made it,however the total query execution time is higher. Regards. On 05/27/2015 04:36 PM, Tom Lane wrote: boix writes: Hello, my partner and me are working with the goal of improve the GEQO's performance, we tried

Re: [HACKERS] About that re-release ...

On 5/28/2015 7:10 PM, Josh Berkus wrote: On 05/28/2015 02:37 AM, Marco Atzeri wrote: On 5/28/2015 5:00 AM, Tom Lane wrote: Assuming that we can get a fix for the fsync-failure-during-restart problem committed by the end of the week, there will be a new set of back-branch minor releases next wee

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On Thu, May 28, 2015 at 1:04 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 28, 2015 at 10:26 AM, Abhijit Menon-Sen >> wrote: >>> 2. Robert, are you comfortable with what fsync_pgdata() does in xlog.c? >>> I wasn't sure if I should move that to fd.c as well. I think it's >>> borderlin

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

At 2015-05-28 19:56:15 +0530, a...@2ndquadrant.com wrote: > > I have a separate patch to initdb with the corresponding changes, which > I will post after dinner and a bit more testing. Here's that patch too. I was a bit unsure how far to go with this. It fixes the problem of not following pg_xlog

Re: [HACKERS] About that re-release ...

On 05/28/2015 02:37 AM, Marco Atzeri wrote: > On 5/28/2015 5:00 AM, Tom Lane wrote: >> Assuming that we can get a fix for the fsync-failure-during-restart >> problem committed by the end of the week, there will be a new set of >> back-branch minor releases next week. Usual schedule, wrap Monday >>

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Robert Haas writes: > On Thu, May 28, 2015 at 10:26 AM, Abhijit Menon-Sen > wrote: >> 2. Robert, are you comfortable with what fsync_pgdata() does in xlog.c? >> I wasn't sure if I should move that to fd.c as well. I think it's >> borderline OK for now. > I think if the function is specific as f

Re: [HACKERS] [PATCH] readlink missing nul-termination in pg_rewind

Abhijit Menon-Sen writes: > P.S. Also in passing, I note that pg_rewind will follow links under any > directory anywhere named pg_tblspc (which probably doesn't matter), and > does not follow pg_xlog if it's a symlink (which probably does). If you > want, I can submit a trivial patch for the latte

Re: [HACKERS] rhel6 rpm file locations

Hi, On Thu, 2015-05-28 at 08:54 -0500, Ted Toth wrote: > Are there any other packagers following the Fedora 'standards' that > you are aware of? It is not about following the standards or not. Unlike distro RPMs, you can install multiple PostgreSQL versions into the same box using community RPMS.

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On Thu, May 28, 2015 at 10:26 AM, Abhijit Menon-Sen wrote: > 2. Robert, are you comfortable with what fsync_pgdata() does in xlog.c? >I wasn't sure if I should move that to fd.c as well. I think it's >borderline OK for now. I think if the function is specific as fsync_pgdata(), fd.c is n

[HACKERS] RFC: Remove contrib entirely

Hello, This is a topic that has come up in various ways over the years. After the long thread on pg_audit, I thought it might be time to bring it up again. Contrib according to the docs is: "These include porting tools, analysis utilities, and plug-in features that are not part of the core

Re: [HACKERS] rhel6 rpm file locations

> On May 27, 2015, at 12:40 PM, Robert Haas wrote: > > On Wed, May 27, 2015 at 3:25 PM, Ted Toth wrote: >> On Wed, May 27, 2015 at 1:31 PM, Robert Haas wrote: >>> On Wed, May 27, 2015 at 11:35 AM, Ted Toth wrote: I'm trying to use a newer version than is available from RH in our cus

Re: [HACKERS] About that re-release ...

On Wed, May 27, 2015 at 11:08 PM, Robert Haas wrote: >>> What about >>> http://www.postgresql.org/message-id/20150527222142.ge5...@postgresql.org >>> ? >> >>> I believe that is also a 9.4.2 regression, and a serious one. >> >> Oh? There was nothing in the thread that suggested to me that it was

Re: [HACKERS] [PATCH] readlink missing nul-termination in pg_rewind

Abhijit Menon-Sen writes: > This is just something I noticed in passing. (I did a quick check of all > the other uses of readlink in the source, and they do get this right.) There's more random inconsistency than just this. I think we should standardize on the coding exhibited at, eg, basebackup

Re: [HACKERS] WIP: Enhanced ALTER OPERATOR

Alexander Korotkov writes: > Could we address both this problems by denying changing existing > commutators and negator? ISTM that setting absent commutator and negator is > quite enough for ALTER OPERATOR. User extensions could need setting of > commutator and negator because they could add new o

[HACKERS] [PATCH] readlink missing nul-termination in pg_rewind

This is just something I noticed in passing. (I did a quick check of all the other uses of readlink in the source, and they do get this right.) -- Abhijit P.S. Also in passing, I note that pg_rewind will follow links under any directory anywhere named pg_tblspc (which probably doesn't matter), an

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com> > On Thu, May 28, 2015 at 10:20:58AM -0400, Bruce Momjian wrote: > > On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote: > > > What we should be saying is that the last timeline doesn't need a history > > > file. >

[HACKERS] proleakproof vs opr_sanity test

In view of http://www.postgresql.org/message-id/CAM2+6=u5ylzbre3v3wf9fful0gxr1ega3miph1gu0jpseud...@mail.gmail.com I went trawling for other places where the LEAKPROOF patch might have overlooked something, by dint of grepping for prosecdef and seeing if there was or should be parallel code for pro

Re: [HACKERS] pg_upgrade resets timeline to 1

On Thu, May 28, 2015 at 10:20:58AM -0400, Bruce Momjian wrote: > On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote: > > What we should be saying is that the last timeline doesn't need a history > > file. > > Then no change is needed here. > > Yes, that would make a lot more sense than w

Re: [HACKERS] pg_upgrade resets timeline to 1

On Thu, May 28, 2015 at 10:39:15AM -0400, Noah Misch wrote: > > > It looks like an upgrade from 9.1.x to 9.3.0 or later has always set the > > > new > > > timeline identifier (TLI) to 1. My testing confirms this for an upgrade > > > from > > > 9.1.16 to 9.4.1 and for an upgrade from 9.1.16 to 9.

Re: [HACKERS] PGCon hacker lounge

> On May 27, 2015, at 12:06 PM, Alexander Korotkov > wrote: > > On Wed, May 27, 2015 at 7:00 PM, Dan Langille > wrote: > Have you been to PGCon before? Do you remember the hacker lounge? Do you > remember going there to work on stuff? Do you recall anything about

Re: [HACKERS] pg_upgrade resets timeline to 1

On Thu, May 28, 2015 at 10:18:18AM +0200, Christoph Berg wrote: > Re: Noah Misch 2015-05-28 <20150528072721.ga4102...@tornado.leadboat.com> > > > I've just had trouble getting barman to work again after a 9.1->9.4.2 > > > upgrade, and I think part of the problem was that the WAL for this > > > clus

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Hi. Here's an updated patch for the fsync problem(s). A few points that may be worth considering: 1. I've made the ReadDir → ReadDirExtended change, but in retrospect I don't think it's really worth it. Using ReadDir and letting it die is probably fine. (Aside: I left ReadDirExtended stati

Re: [HACKERS] pg_upgrade resets timeline to 1

On Thu, May 28, 2015 at 10:13:14AM +0200, Christoph Berg wrote: > Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us> > > Well, if you used pg_dump/pg_restore, you would have had even larger > > problems as the file names would have matched. > > True, but even here it's possible that f

Re: [HACKERS] pg_upgrade resets timeline to 1

On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote: > We could have pg_upgrade increment the timeline and allow for missing > history files, but that doesn't fix problems with non-pg_upgrade > upgrades, which also should never be sharing WAL files from previous > major vers

Re: [HACKERS] [BUGS] pg_get_functiondef() does not show LEAKPROOF for leakproof functions

Michael Paquier writes: > On Thu, May 28, 2015 at 5:52 PM, Jeevan Chalke > wrote: >> If function is created with the LEAKPROOF option, then pg_get_functiondef() >> does not show that in the returned definition. >> Is it expected OR are we missing that option in pg_get_functiondef(). > Agreed. I

Re: [HACKERS] [Proposal] More Vacuum Statistics

Naoya Anzai writes: > In my much experience up until now,I have an idea that we can add > 2 new vacuum statistics into pg_stat_xxx_tables. Adding new stats in that way requires adding per-table counters, which bloat the statistics files (especially in database with very many tables). I do not th

Re: [HACKERS] Possible pointer dereference

Robert Haas writes: > On Wed, May 27, 2015 at 8:57 PM, Haribabu Kommi > wrote: >> By correcting the following way will solve the problem. >> return ts ? (*ts != 0) : false; instead of retun *ts != 0; >> Attached a patch for it. > If the only caller always passes a valid pointer, there's no point

Re: [HACKERS] rhel6 rpm file locations

Are there any other packagers following the Fedora 'standards' that you are aware of? On Wed, May 27, 2015 at 2:40 PM, Robert Haas wrote: > On Wed, May 27, 2015 at 3:25 PM, Ted Toth wrote: >> On Wed, May 27, 2015 at 1:31 PM, Robert Haas wrote: >>> On Wed, May 27, 2015 at 11:35 AM, Ted Toth wro

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

On Thu, May 28, 2015 at 8:03 AM, Robert Haas wrote: >> Steve, is there any chance we can get your pg_controldata output and a >> list of all the files in pg_clog? > > Err, make that pg_multixact/members, which I assume is at issue here. > You didn't show us the DETAIL line from this message, which

Re: [HACKERS] [BUGS] pg_get_functiondef() does not show LEAKPROOF for leakproof functions

On Thu, May 28, 2015 at 5:52 PM, Jeevan Chalke wrote: > If function is created with the LEAKPROOF option, then pg_get_functiondef() > does not show that in the returned definition. > Is it expected OR are we missing that option in pg_get_functiondef(). > > However only superuser can define a leakp

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

Hi all, 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 it happens that the result string is never freed at all, leaking memory. Attached is a patch to fix the problem. Rega

Re: [HACKERS] Possible pointer dereference

On Wed, May 27, 2015 at 8:57 PM, Haribabu Kommi wrote: > On Thu, May 28, 2015 at 6:07 AM, Gaetano Mendola wrote: >> I'm playing with a static analyzer and it's giving out some real error >> analyzing postgresql code base like the following one >> >> src/backend/access/transam/commit_ts.c >>re

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

On Thu, May 28, 2015 at 8:01 AM, Robert Haas wrote: > On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera > wrote: >> Steve Kehlet wrote: >>> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we >>> just dropped new binaries in place) but it wouldn't start up. I found this >>> i

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Heikki, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 05/28/2015 11:14 AM, Stephen Frost wrote: > >* Heikki Linnakangas (hlinn...@iki.fi) wrote: > >>1. it's not flexible enough. How do you specify that all READs on > >>super_secret table must be logged, but on less_secret table, it's > >>enou

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

On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera wrote: > Steve Kehlet wrote: >> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we >> just dropped new binaries in place) but it wouldn't start up. I found this >> in the logs: >> >> waiting for server to start2015-05-27 1

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

On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera wrote: > Steve Kehlet wrote: >> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we >> just dropped new binaries in place) but it wouldn't start up. I found this >> in the logs: >> >> waiting for server to start2015-05-27 1

[HACKERS] [Proposal] More Vacuum Statistics

Hello, hackers! I'm a technical support engineer of PostgreSQL. In my much experience up until now,I have an idea that we can add 2 new vacuum statistics into pg_stat_xxx_tables. Features I hope is following. MORE VACUUM STATISTICS == Design & Motivation --- 1. Show abo

Re: [HACKERS] About that re-release ...

On 5/28/2015 5:00 AM, Tom Lane wrote: Assuming that we can get a fix for the fsync-failure-during-restart problem committed by the end of the week, there will be a new set of back-branch minor releases next week. Usual schedule, wrap Monday for public announcement Thursday.

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

On 05/28/2015 11:14 AM, Stephen Frost wrote: * Heikki Linnakangas (hlinn...@iki.fi) wrote: 1. it's not flexible enough. How do you specify that all READs on super_secret table must be logged, but on less_secret table, it's enough to log only WRITEs? This is actually what that pg_audit.role set

[HACKERS] pg_get_functiondef() does not show LEAKPROOF for leakproof functions

Hi, If function is created with the LEAKPROOF option, then pg_get_functiondef() does not show that in the returned definition. Is it expected OR are we missing that option in pg_get_functiondef(). However only superuser can define a leakproof function. Was this the reson we are not showing that i

Re: [HACKERS] Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

On 2015/05/25 9:16, Peter Geoghegan wrote: AddForeignUpdateTargets() actually won't be called with ON CONFLICT DO UPDATE, and so it isn't exactly true that the only obstacle to making FDWs support ON CONFLICT DO UPDATE is around inference of arbiter unique indexes on the foreign side. It's *almos

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

All, Replying to Heikki's email as it's quite late here and I want to respond. Barring any further commentary, I'm planning to pull pg_audit out tomorrow (it wouldn't be intelligent for me to attempt to do so now). I really do appreciate all of the excellent feedback and comments, the excellent d

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Noah Misch 2015-05-28 <20150528072721.ga4102...@tornado.leadboat.com> > > I've just had trouble getting barman to work again after a 9.1->9.4.2 > > upgrade, and I think part of the problem was that the WAL for this > > cluster got reset from timeline 2 to 1, which made barman's incoming > > WAL

Re: [HACKERS] WIP: Enhanced ALTER OPERATOR

On Wed, May 27, 2015 at 9:28 PM, Robert Haas wrote: > On Mon, May 18, 2015 at 10:21 AM, Tom Lane wrote: > > Uriy Zhuravlev writes: > >> I have attached a patch that extends ALTER OPERATOR to support > COMMUTATOR, > >> NEGATOR, RESTRICT and JOIN. > > > > There are fairly significant reasons why

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Simon Riggs 2015-05-28 > Hmm, it looks like the change to TimeLine 1 is just a kludge anyway. The > rule that TimeLine 1 doesn't need a history file is itself a hack. > > What we should be saying is that the last timeline doesn't need a history > file. Then no change is needed here. IMHO it

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Heikki, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 05/28/2015 06:04 AM, Joshua D. Drake wrote: > >On 05/27/2015 07:02 PM, Stephen Frost wrote: > >>regardless of if they are included in the main git repo > >>or not. Being in the repo represents the support of the overall > >>community and

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us> > Well, if you used pg_dump/pg_restore, you would have had even larger > problems as the file names would have matched. True, but even here it's possible that files get overwritten. If you had a server running on TL 1 for files 000100

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

On 05/28/2015 06:04 AM, Joshua D. Drake wrote: On 05/27/2015 07:02 PM, Stephen Frost wrote: regardless of if they are included in the main git repo or not. Being in the repo represents the support of the overall community and PGDG, which is, understandably in my view, highly valuable to the org

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 27 May 2015 at 14:51, Stephen Frost wrote: > >> On 27 May 2015 at 02:42, Stephen Frost wrote: > >> > Now, looking at the code, I'm actually failing to see a case where we > >> > use the RowSecurityPolicy->policy_name.. Perhaps *that's*

  1   2   >