Re: [HACKERS] snapshot too old, configured by time

On Mon, May 2, 2016 at 03:50:36PM -0500, Kevin Grittner wrote: > >> Also, it seems we have similar behavior already in applying WAL on the > >> standby --- we delay WAL replay when there is a long-running > >> transaction. Once the time expires, we apply the WAL. Do we cancel the > >>

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

Hello, I'm unsure about switching enum to #define, could be an enum still with explicit values set, something like: An enum doesn't have a benefit for a bitmask imo - you can't "legally" use it as a type for functions accepting the bitmask. I do not understand. I suggested to use enum to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Mon, May 2, 2016 at 07:21:21AM -0700, Andres Freund wrote: > On 2016-05-02 09:03:19 -0400, Robert Haas wrote: > > On Fri, Apr 29, 2016 at 6:08 PM, Kevin Grittner wrote: > > > Now to continue with the performance benchmarks. I'm pretty sure > > > we've fixed the problems

[HACKERS] Re: [COMMITTERS] pgsql: Fix assorted inconsistencies in GIN opclass support function dec

On Mon, May 2, 2016 at 5:15 PM, Andres Freund wrote: > On 2016-05-02 17:12:41 -0400, Robert Haas wrote: >> On Mon, May 2, 2016 at 5:09 PM, Tom Lane wrote: >> > Alexander Korotkov writes: >> > But this is likely moot anyway,

[HACKERS] pgindent fixups

I spent some time going through the output of a trial pgindent run today. Some questions/problems: 1. Is pgindent supposed to touch DATA() lines? Because it does. 2. CustomPathMethods is not in the buildfarm's typedefs.list. Why not? I'm attaching a patch that fixes up a few other problems

Re: [HACKERS] About subxact and xact nesting level...

> ow...@postgresql.org] On Behalf Of Tom Lane > > Are there specific requirements or things to do/avoid in order to use > > subtransactions (at the PL API level)? > > There isn't, currently, any very hard-and-fast rule about what APIs > extensions should use or not use. My advice is to borrow

Re: [HACKERS] About subxact and xact nesting level...

"dandl" writes: > Are there specific requirements or things to do/avoid in order to use > subtransactions (at the PL API level)? There isn't, currently, any very hard-and-fast rule about what APIs extensions should use or not use. My advice is to borrow freely from existing PLs,

Re: [HACKERS] Fix for OpenSSL error queue bug

Peter Eisentraut writes: > On 04/27/2016 11:04 PM, Tom Lane wrote: >> Actually, git_changelog can merge identically-messaged commits despite >> intervening commits. It's set up to not merge commits more than 24 hours >> apart, though. We could loosen that requirement but I'm

Re: [HACKERS] Fix for OpenSSL error queue bug

On 04/27/2016 11:04 PM, Tom Lane wrote: >> There is no value in providing exact message matches when the backpatch >> occurs even after one other commit in the master branch. > > Actually, git_changelog can merge identically-messaged commits despite > intervening commits. It's set up to not

Re: [HACKERS] About subxact and xact nesting level...

> From: Tom Lane [mailto:t...@sss.pgh.pa.us] > >> The file xact.c contains references to sub-transactions (subxact) and > >> transaction nesting level, but no obvious documentation about what > >> these correspond to in SQL. > > > Subtransactions are used to implement SAVEPOINT, and also BEGIN

Re: [HACKERS] Reviewing freeze map code

Hi, some of the review items here are mere matters of style/preference. Feel entirely free to discard them, but I thought if I'm going through the change anyway... On 2016-05-02 14:48:18 -0700, Andres Freund wrote: > a892234 Change the format of the VM fork to add a second bit per page. TL;DR:

Re: [HACKERS] Is pg_control file crashsafe?

Hi, On 2016-04-28 21:58:00 +, Alex Ignatov wrote: > We have some issue with truncated pg_control file on Windows after > power failure.My questions is : 1) Is pg_control protected from say , > power crash or partial write? It should be. I think to make progress on this thread we're going to

Re: [HACKERS] Is pg_control file crashsafe?

Alex Ignatov writes: > I think that rename can help a little bit. At least on some FS it is > atomic operation. Writing a single sector ought to be atomic too. I'm very skeptical that it'll be an improvement to just move the risk from one filesystem operation to

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

Hi, On 2016-05-03 00:05:35 +0200, Fabien COELHO wrote: > Maybe consider checking for the exclusivity explicitely? I thought about it, and decided it's not worth it. Requiring one of those to be specified seems stringent enough. > I'm unsure about switching enum to #define, could be an enum

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

Hello Andres, I'm not sure this is the best way to go about this. I can see valid arguments for *always* using _mdfd_openseg() in mdsync(); and I'm wondering whether we shouldn't make EXTENSION_* into a bitmask (extend,extend_recovery,return_null,open_deleted). I thought about that when I

Re: [HACKERS] Naming of new tsvector functions

On Mon, May 02, 2016 at 01:58:11PM -0400, Tom Lane wrote: > I wrote: > > I think we'd be better off to rename these to tsvector_delete() > > and tsvector_filter() while we still can. > > ... although I now notice that hstore already exposes a function > named delete(), so that ship may have

Re: [HACKERS] Is pg_control file crashsafe?

On 01.05.2016 0:55, Bruce Momjian wrote: On Thu, Apr 28, 2016 at 09:58:00PM +, Alex Ignatov wrote: Hello everyone! We have some issue with truncated pg_control file on Windows after power failure. My questions is : 1) Is pg_control protected from say , power crash or partial write? 2) How

[HACKERS] Reviewing freeze map code

Hi, The freeze map changes, besides being very important, seem to be one of the patches with a high risk profile in 9.6. Robert had asked whether I'd take a look. I thought it'd be a good idea to review that while running tests for

Re: [HACKERS] pg_upgrade and toasted pg_largeobject

Alvaro Herrera writes: > Robert Haas wrote: >> On Mon, May 2, 2016 at 12:30 PM, Alvaro Herrera >> wrote: >>> A customer of ours was unable to pg_upgrade a database, with this error: old and new databases "postgres" have a mismatched number

Re: [HACKERS] old_snapshot_threshold's interaction with hash index

On Sun, May 1, 2016 at 1:43 AM, Amit Kapila wrote: > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila wrote: >> >> Currently we do the test for old snapshot (TestForOldSnapshot) for hash >> indexes while scanning them. Does this test makes any sense

Re: [HACKERS] snapshot too old, configured by time

On Sun, May 1, 2016 at 11:54 PM, Bruce Momjian wrote: > On Sat, Apr 23, 2016 at 10:20:19AM -0400, Bruce Momjian wrote: >> On Sat, Apr 23, 2016 at 12:48:08PM +0530, Amit Kapila wrote: >>> On Sat, Apr 23, 2016 at 8:34 AM, Bruce Momjian wrote: I kind of

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-05-02 22:00:14 +0200, Fabien COELHO wrote: > I'm wondering that if _mdfd_openseg may return NULL, then ISTM that > "opened_directly" should logically be false, because it was not opened? > > If so, maybe consider something like: > > opened_directy = (seg != NULL); Hm, don't care

[HACKERS] Pg_stop_backup process does not run - Backup Intervals

Hi, On alternate days my backup is failing, by the pg_stop_backup process () does not perform or quit. Version PostgreSQL: 9.1.6 The following backup script: PGDATA=/dados SAVE_BASE_DIR=/backup/diario backup="'bkpfull'" data=$(date +'%d%m%y') WAL_DIR=/backup/archive mv $WAL_DIR/*

Re: [HACKERS] pg_upgrade and toasted pg_largeobject

Robert Haas wrote: > On Mon, May 2, 2016 at 12:30 PM, Alvaro Herrera > wrote: > > A customer of ours was unable to pg_upgrade a database, with this error: > > > > old and new databases "postgres" have a mismatched number of relations > > Failure, exiting > > > >

Re: [HACKERS] pg_upgrade and toasted pg_largeobject

On Mon, May 2, 2016 at 12:30 PM, Alvaro Herrera wrote: > A customer of ours was unable to pg_upgrade a database, with this error: > > old and new databases "postgres" have a mismatched number of relations > Failure, exiting > > After some research, it turned out that

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

Hello Andres, Sure, attached. For what it is worth, it works for me on head. I'm wondering that if _mdfd_openseg may return NULL, then ISTM that "opened_directly" should logically be false, because it was not opened? If so, maybe consider something like: opened_directy = (seg !=

Re: [HACKERS] More inaccurate results from numeric pow()

On 2 May 2016 at 19:40, Robert Haas wrote: > On Mon, May 2, 2016 at 1:02 PM, Dean Rasheed wrote: >> Doing some more testing of the numeric code patched in [1] I noticed >> another case where the result is inaccurate -- computing 0.12 ^ >> -2345.6

Re: [HACKERS] Rename max_parallel_degree?

On Mon, May 2, 2016 at 12:14 PM, Robert Haas wrote: > On Mon, May 2, 2016 at 2:44 PM, David G. Johnston > wrote: > > Does this apply to the extent that a value of 1 is likely worse than 0 > since > > the leader is now tasked with accumulating

Re: [HACKERS] Timeline following for logical slots

Andres Freund wrote: > - /* oldest LSN that the client has acked receipt for */ > + /* > +* Oldest LSN that the client has acked receipt for. This is used as the > +* start_lsn point in case the client doesn't specify one, and also as a > +* safety measure to back off in case the

Re: [HACKERS] Rename max_parallel_degree?

On Mon, May 2, 2016 at 3:18 PM, Christoph Berg wrote: > Re: Robert Haas 2016-05-02 > >> max_parallel_degree -> max_parallel_workers >> parallel_degree -> parallel_workers >> >> I would prefer to keep it as

Re: [HACKERS] Timeline following for logical slots

On 2016-05-02 16:12:53 -0300, Alvaro Herrera wrote: > I pushed a fix to some comments, including the ones being discussed in > this subthread, which should hopefully close things here. > > I'm now going to go over Craig's pg_recvlogical changes and the proposed > for that problem. - /* oldest

Re: [HACKERS] Rename max_parallel_degree?

Re: Robert Haas 2016-05-02 > max_parallel_degree -> max_parallel_workers > parallel_degree -> parallel_workers > > I would prefer to keep it as "degree". It's a reasonable term of art, > and it also improves grep-ability.

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On Sat, Apr 30, 2016 at 1:35 PM, Tom Lane wrote: > Julien Rouhaud writes: >> On 29/04/2016 18:05, Tom Lane wrote: >>> Julien Rouhaud writes: The segfault is caused by quals_match_foreign_key() calling get_leftop()

Re: [HACKERS] Rename max_parallel_degree?

On Mon, May 2, 2016 at 2:44 PM, David G. Johnston wrote: > Does this apply to the extent that a value of 1 is likely worse than 0 since > the leader is now tasked with accumulating but there is only one process > actually working to provide the leader data? I don't

Re: [HACKERS] Timeline following for logical slots

I pushed a fix to some comments, including the ones being discussed in this subthread, which should hopefully close things here. I'm now going to go over Craig's pg_recvlogical changes and the proposed for that problem. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL

[HACKERS] max_worker_processes missing some documentation

I noticed that postgresql.conf.sample doesn't say that changing max_worker_processes requires a restart. Patch attached. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index

Re: [HACKERS] Rename max_parallel_degree?

On Sun, Apr 24, 2016 at 8:01 PM, Robert Haas wrote: > > Of course, we could make this value 1-based rather than 0-based, as > Peter Geoghegan suggested a while back. But as I think I said at the > time, I think that's more misleading than helpful. The leader >

Re: [HACKERS] More inaccurate results from numeric pow()

On Mon, May 2, 2016 at 1:02 PM, Dean Rasheed wrote: > Doing some more testing of the numeric code patched in [1] I noticed > another case where the result is inaccurate -- computing 0.12 ^ > -2345.6 gives a very large number containing 2162 digits, but only the > first

Re: [HACKERS] Naming of new tsvector functions

On Mon, May 2, 2016 at 1:58 PM, Tom Lane wrote: > I wrote: >> I think we'd be better off to rename these to tsvector_delete() and >> tsvector_filter() while we still can. > > ... although I now notice that hstore already exposes a function named > delete(), so that ship may

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas wrote: > On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote: >> Robert Haas writes: >>> I still think >>> max_parallel_workers is confusingly similar to max_worker_processes, >>> but

Re: [HACKERS] Naming of new tsvector functions

I wrote: > I think we'd be better off to rename these to tsvector_delete() and > tsvector_filter() while we still can. ... although I now notice that hstore already exposes a function named delete(), so that ship may have sailed already. But I'm more troubled by filter() anyhow, since that

Re: [HACKERS] More inaccurate results from numeric pow()

Dean Rasheed writes: > In fact it's possible to predict exactly how large we need to allow > "val" to become, since the final result is computed using exp_var(), > which accepts inputs up to 6000, so the result weight "val" can be up > to around log10(exp(6000)) ~= 2606

Re: [HACKERS] Naming of new tsvector functions

On 05/02/2016 10:27 AM, Tom Lane wrote: I noticed that 6943a946c introduces some new functions named delete() and filter(). This does not seem like a terribly bright idea to me. They may not be formally ambiguous with the corresponding keywords, but it's not very hard to imagine how small typos

[HACKERS] Naming of new tsvector functions

I noticed that 6943a946c introduces some new functions named delete() and filter(). This does not seem like a terribly bright idea to me. They may not be formally ambiguous with the corresponding keywords, but it's not very hard to imagine how small typos could lead to the parser taking the

[HACKERS] More inaccurate results from numeric pow()

Doing some more testing of the numeric code patched in [1] I noticed another case where the result is inaccurate -- computing 0.12 ^ -2345.6 gives a very large number containing 2162 digits, but only the first 2006 correct, while the last 156 digits are wrong. The reason is this code in

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-05-02 12:44:53 -0400, Robert Haas wrote: > On Mon, May 2, 2016 at 12:41 PM, Andres Freund wrote: > > On 2016-05-02 12:29:45 -0400, Robert Haas wrote: > >> On Fri, Apr 29, 2016 at 7:58 PM, Andres Freund wrote: > >> > Basically the reason for the

Re: [HACKERS] Rename max_parallel_degree?

On Sat, Apr 30, 2016 at 4:54 AM, David Rowley wrote: >> Right, but they're probably not doing the SAME work. You can look at >> EXPLAIN (ANALYZE, VERBOSE, BUFFERS) to see. Of course, all the work >> above the Gather node is being done by the leader, but the stuff

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On Mon, May 2, 2016 at 12:41 PM, Andres Freund wrote: > On 2016-05-02 12:29:45 -0400, Robert Haas wrote: >> On Fri, Apr 29, 2016 at 7:58 PM, Andres Freund wrote: >> > Basically the reason for the problem is that mdsync() needs to access >> > "formally

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-05-02 12:29:45 -0400, Robert Haas wrote: > On Fri, Apr 29, 2016 at 7:58 PM, Andres Freund wrote: > > Basically the reason for the problem is that mdsync() needs to access > > "formally non-existant segments" (as in ones where previous segments are > > < RELSEG_SIZE),

[HACKERS] pg_upgrade and toasted pg_largeobject

Hi, A customer of ours was unable to pg_upgrade a database, with this error: old and new databases "postgres" have a mismatched number of relations Failure, exiting After some research, it turned out that pg_largeobject had acquired a toast table. After some more research, we determined

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On Fri, Apr 29, 2016 at 7:58 PM, Andres Freund wrote: > On 2016-04-28 17:41:29 +0100, Thom Brown wrote: >> I've noticed another breakage, which I can reproduce consistently. > >> 2016-04-28 17:36:08 BST [18108]: [47-1] user=,db=,client= DEBUG: could not >> fsync file

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

On Fri, Apr 29, 2016 at 9:45 AM, Tom Lane wrote: >> It will >> be helpful if you can find the offending query or plan corresponding to it? > > I presume the lack of debug_query_string data is because nothing is > bothering to set debug_query_string in a worker process. Should

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Mon, May 2, 2016 at 4:04 PM, Andrew Dunstan wrote: > > On 05/02/2016 04:56 AM, Shulgin, Oleksandr wrote: > >> On Sun, May 1, 2016 at 3:22 AM, Andrew Dunstan > > wrote: >> >> On 04/29/2016 06:11 PM, Merlin Moncure

Re: [HACKERS] 9.6 and fsync=off

On Mon, May 2, 2016 at 12:04 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-05-02 10:07:50 -0400, Robert Haas wrote: >>> - If that flag is set on a subsequent startup, say: >>> WARNING: Recovery was previously performed with fsync=off; this >>>

Re: [HACKERS] 9.6 and fsync=off

Andres Freund writes: > On 2016-05-02 10:07:50 -0400, Robert Haas wrote: >> - If that flag is set on a subsequent startup, say: >> WARNING: Recovery was previously performed with fsync=off; this >> cluster may be irretrievably corrupted. > Well, the problem with that is that

Re: [HACKERS] 9.6 and fsync=off

Hi, On 2016-05-02 10:07:50 -0400, Robert Haas wrote: > I also think that it would be a swell idea to detect whether a system > has ever crashed with fsync=off, and do something about that, like > maybe bleat on every subsequent startup for the lifetime of the > cluster. I think Andres may have

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-05-02 18:15:40 +0300, Ants Aasma wrote: > On Mon, May 2, 2016 at 5:21 PM, Andres Freund wrote: > > On 2016-05-02 09:03:19 -0400, Robert Haas wrote: > >> On Fri, Apr 29, 2016 at 6:08 PM, Kevin Grittner wrote: > >> > Now to continue with the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Mon, May 2, 2016 at 5:21 PM, Andres Freund wrote: > On 2016-05-02 09:03:19 -0400, Robert Haas wrote: >> On Fri, Apr 29, 2016 at 6:08 PM, Kevin Grittner wrote: >> > Now to continue with the performance benchmarks. I'm pretty sure >> > we've fixed the

Re: [HACKERS] Accidentally parallel unsafe functions

On Fri, Apr 29, 2016 at 6:06 PM, Andreas Karlsson wrote: > I am currently looking into adding the correct parallel options to all > functions in the extensions and I noticed that some built-in functions seems > to have been marked as unsafe by accident. The main culprit is >

Re: [HACKERS] 9.6 and fsync=off

Craig Ringer writes: > On 2 May 2016 at 22:07, Robert Haas wrote: >> I also think that it would be a swell idea to detect whether a system >> has ever crashed with fsync=off, and do something about that, like >> maybe bleat on every subsequent

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Mon, May 2, 2016 at 10:21 AM, Andres Freund wrote: > On 2016-05-02 09:03:19 -0400, Robert Haas wrote: >> On Fri, Apr 29, 2016 at 6:08 PM, Kevin Grittner wrote: >> > Now to continue with the performance benchmarks. I'm pretty sure >> > we've fixed the

Re: [HACKERS] About subxact and xact nesting level...

> From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] > > The file xact.c contains references to sub-transactions (subxact) and > > transaction nesting level, but no obvious documentation about what > > these correspond to in SQL. A search shows that plpython supports > > something called

Re: [HACKERS] 9.6 and fsync=off

On 2 May 2016 at 22:07, Robert Haas wrote: > > I also think that it would be a swell idea to detect whether a system > has ever crashed with fsync=off, and do something about that, like > maybe bleat on every subsequent startup for the lifetime of the > cluster. Yes.

Re: [HACKERS] Refactor pg_dump as a library?

Robert Haas writes: > On Mon, May 2, 2016 at 10:00 AM, Tom Lane wrote: >> Robert Haas writes: >>> On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane wrote: The problem with that approach is that then you are

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-05-02 09:03:19 -0400, Robert Haas wrote: > On Fri, Apr 29, 2016 at 6:08 PM, Kevin Grittner wrote: > > Now to continue with the performance benchmarks. I'm pretty sure > > we've fixed the problems when the feature is disabled > > (old_snapshot_threshold = -1), and there

Re: [HACKERS] About subxact and xact nesting level...

> From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] > > The file xact.c contains references to sub-transactions (subxact) and > > transaction nesting level, but no obvious documentation about what > > these correspond to in SQL. A search shows that plpython supports > > something called

Re: [HACKERS] Refactor pg_dump as a library?

On Mon, May 2, 2016 at 10:00 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane wrote: >>> The problem with that approach is that then you are talking about building >>> duplicate copies of

Re: [HACKERS] 9.6 and fsync=off

On Fri, Apr 29, 2016 at 9:49 AM, Tom Lane wrote: > Abhijit Menon-Sen writes: >> Do you want a patch along those lines now, or is it too late? > > We're certainly not going to consider fooling with this in 9.6. > The situation for manual fsync-twiddling

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On 05/02/2016 04:56 AM, Shulgin, Oleksandr wrote: On Sun, May 1, 2016 at 3:22 AM, Andrew Dunstan > wrote: On 04/29/2016 06:11 PM, Merlin Moncure wrote: This is a simple matter of removing spaces in the occasional C string

Re: [HACKERS] Subtle bug in autoconf flex version test

Daniel Gustafsson writes: >> On 02 May 2016, at 15:38, Tom Lane wrote: >> Hm, is that a popular flex version? I wonder whether we will get >> complaints if we start warning about it. > Sorry, I missed half the sentence there. What I meant was that I can

Re: [HACKERS] Refactor pg_dump as a library?

Robert Haas writes: > On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane wrote: >> The problem with that approach is that then you are talking about building >> duplicate copies of entire layers of the system. For example, namespace.c >> would have to be

Re: [HACKERS] Timeline following for logical slots

Robert Haas wrote: > On Tue, Apr 26, 2016 at 4:37 PM, Alvaro Herrera > wrote: > > I failed to meet this deadline, for which I apologize. This week is > > going to be hectic around here, so my new deadline is to get these two > > patches applied on Friday 29th. Ok? >

Re: [HACKERS] Subtle bug in autoconf flex version test

> On 02 May 2016, at 15:38, Tom Lane wrote: > > Daniel Gustafsson writes: >> The PGAC_PATH_FLEX version test in config/programs.m4 tests the major and >> minor >> versions with = rather than == which unless I’m missing something is >> performing >>

Re: [HACKERS] Timeline following for logical slots

On Tue, Apr 26, 2016 at 4:37 PM, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Noah Misch wrote: >> >> > The above-described topic is currently a PostgreSQL 9.6 open item. Alvaro, >> > since you committed the patch believed to have created it, you own this >> > open

Re: [HACKERS] Subtle bug in autoconf flex version test

Daniel Gustafsson writes: > The PGAC_PATH_FLEX version test in config/programs.m4 tests the major and > minor > versions with = rather than == which unless I’m missing something is > performing > assignment rather than testing equality? Huh. That's been broken since forever

Re: [HACKERS] Detrimental performance impact of ringbuffers on performance

On Fri, Apr 29, 2016 at 7:08 AM, Bruce Momjian wrote: > On Wed, Apr 6, 2016 at 12:57:16PM +0200, Andres Freund wrote: >> While benchmarking on hydra >> (c.f. >> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de), >> which has quite

Re: [HACKERS] pg_xlog -> pg_xjournal?

On Thu, Apr 28, 2016 at 11:46 PM, Craig Ringer wrote: > On 29 April 2016 at 10:12, Bruce Momjian wrote: >> My larger question was, was 9.6 an ideal time to do this, and if so, why >> did this issue not get done. If 9.6 wasn't in some way ideal, we can do

Re: [HACKERS] Refactor pg_dump as a library?

On Mon, Apr 18, 2016 at 11:04 AM, Tom Lane wrote: > Robert Haas writes: >> I think that we could have an alternate set of functions which have >> the same interface as the syscache functions but using the transaction >> snapshot and don't actually cache

Re: [HACKERS] Refactor pg_dump as a library?

On Fri, Apr 29, 2016 at 5:02 PM, Bruce Momjian wrote: >> > I think pg_dump is reasonably proof against DDL on tables. It is not >> > at all proof against DDL on other sorts of objects, such as functions, >> > because of the fact that the syscache will follow catalog updates

Re: [HACKERS] Use %u to print user mapping's umid and userid

On Thu, Apr 28, 2016 at 7:59 AM, Etsuro Fujita wrote: > On 2016/03/14 17:56, Ashutosh Bapat wrote: >> On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita >> > wrote: > >> /* >> * Build the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, Apr 29, 2016 at 6:08 PM, Kevin Grittner wrote: > Now to continue with the performance benchmarks. I'm pretty sure > we've fixed the problems when the feature is disabled > (old_snapshot_threshold = -1), and there are several suggestions > for improving performance

[HACKERS] Re: [COMMITTERS] pgsql: Fix planner crash from pfree'ing a partial path that a GatherPat

On Sat, Apr 30, 2016 at 12:29 PM, Tom Lane wrote: > Fix planner crash from pfree'ing a partial path that a GatherPath uses. > > We mustn't run generate_gather_paths() during add_paths_to_joinrel(), > because that function can be invoked multiple times for the same target >

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 27 April 2016 at 08:36, Dean Rasheed wrote: > Here is a rough patch based on the way pg_dump handles this. It still > needs a bit of polishing -- in particular I think fmtReloptionsArray() > (copied from pg_dump) should probably be moved to string_utils.c so > that it

Re: [HACKERS] WIP: Covering + unique indexes.

On Wed, Apr 27, 2016 at 5:47 PM, David Steele wrote: > On 4/27/16 5:08 PM, Peter Geoghegan wrote: >> So, in case it needs to be >> said, I'll say it: You've chosen a very ambitious set of projects to >> work on, by any standard. I think it's a good thing that you've been >>

Re: [HACKERS] pg_dump dump catalog ACLs

On Fri, Apr 22, 2016 at 3:30 AM, Peter Geoghegan wrote: > On Fri, Apr 22, 2016 at 12:25 AM, Noah Misch wrote: >> Folks run clusters with ~1000 databases; we previously accepted at least one >> complex performance improvement[1] based on that use case. On the

Re: [HACKERS] what does function EmitWarningsOnPlaceholders?

2016-05-02 13:54 GMT+02:00 Craig Ringer : > On 2 May 2016 at 18:51, Pavel Stehule wrote: > >> Hi >> >> what is sense of this function? There is not any comment. >> >> > What it does IIRC is complain about defined GUCs nobody registered an >

Re: [HACKERS] Processes and caches in postgresql

On Wed, Apr 27, 2016 at 7:07 AM, Anastasia Lubennikova wrote: > Hi, hackers. > There's a couple of questions about processes. > > I found EXEC_BACKEND flag, while reading the code. > As I understood, it exists because we have to emulate fork() on WIN32. > And also it

Re: [HACKERS] what does function EmitWarningsOnPlaceholders?

On 2 May 2016 at 18:51, Pavel Stehule wrote: > Hi > > what is sense of this function? There is not any comment. > > What it does IIRC is complain about defined GUCs nobody registered an interest in. So you can say EmitWarningsOnPlaceholders("bdr") and any GUC with

[HACKERS] Dirtying replication slots when confirm_lsn is updated (trivial, 9.7)

Hi all Currently replication slots are not dirtied when the client sends confirmation of replay. So when we checkpoint we don't bother writing out the updated slot state unless the restart_lsn has also changed as a result of the replay confirmation. That's pretty fuss free for the walsender

[HACKERS] what does function EmitWarningsOnPlaceholders?

Hi what is sense of this function? There is not any comment. Regards Pavel

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Sun, May 1, 2016 at 3:22 AM, Andrew Dunstan wrote: > > On 04/29/2016 06:11 PM, Merlin Moncure wrote: > > This is a simple matter of removing spaces in the occasional C string >> literal in the serialization routines and adding a json_pretty >> function. >> > > I spent a

[HACKERS] Subtle bug in autoconf flex version test

The PGAC_PATH_FLEX version test in config/programs.m4 tests the major and minor versions with = rather than == which unless I’m missing something is performing assignment rather than testing equality? The attached diff makes the test trigger the expected warning on major/minor version on my OS X

Re: [HACKERS] Unused macros in contrib code

On 28/04/16 16:06, Daniel Gustafsson wrote: While doing some archaeology I came across a couple of macros in pgstattuple and pageinspect contrib code which seems to have been unused for some time. CHECK_PAGE_OFFSET_RANGE is unused in both modules and commit 6405842 which introduced