Re: [HACKERS] Asymmetry between parent and child wrt "false" quals

On Tue, Mar 21, 2017 at 2:19 PM, Amit Langote wrote: > On 2017/03/21 14:59, Ashutosh Bapat wrote: >> When I run a query like below on a child-less table, the plan comes out to be >> >> explain verbose SELECT * FROM uprt1_l WHERE a = 1 AND a = 2; >>

Re: [HACKERS] Potential data loss of 2PC files

On Wed, Mar 22, 2017 at 12:46 AM, Teodor Sigaev wrote: If that can happen, don't we have the same problem in many other places? Like, all the SLRUs? They don't fsync the directory either. >>> >>> Right, pg_commit_ts and pg_clog enter in this category. >> >> >>

[HACKERS] Possible regression with gather merge.

I accidently encountered a case where gather merge was picked as default but disabling same by setting max_parallel_workers_per_gather = 0; produced a non-parallel plan which was faster than gather merge, but its cost is marked too high when compared to gather merge. I guess we need some cost

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

On Tue, Mar 21, 2017 at 10:37 PM, Kuntal Ghosh wrote: > On Tue, Mar 21, 2017 at 10:52 AM, Michael Paquier > wrote: > We reserve a slot for each possible BackendId, plus one for each > possible auxiliary process type. For a non-auxiliary

Re: [HACKERS] Silence perl warning in check-world

On 3/13/17 16:51, Jeff Janes wrote: > In some older versions of perl (like v5.10), I get a warning that: > > Use of implicit split to @_ is deprecated at > src/test/recovery/t/006_logical_decoding.pl > line 26. > > Splitting into a dummy variable silences that

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

On 3/21/17 15:34, Robert Haas wrote: > So I tend to think that there should always be some explicit user > action to cause the creation of a slot, like --create-slot-if-needed > or --create-slot=name. That still won't prevent careless use of that > option but it's less dangerous than assuming

Re: [HACKERS] Aggregates and row types

Thomas Munro writes: > Is is expected that the first query below can be analysed and planned, > but the second can't? > explain select x from (select row(42)) s(x); > explain select count(x) from (select row(42)) s(x); > ERROR: record type has not been registered

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

On 3/17/17 13:56, Elvis Pranskevichus wrote: > Currently, clients wishing to know when the server exits hot standby > have to resort to polling, which is often suboptimal. > > This adds the new "in_hot_standby" GUC variable that is reported via a > ParameterStatus message. The terminology chosen

Re: [HACKERS] increasing the default WAL segment size

On Tue, Mar 21, 2017 at 11:49 PM, Robert Haas wrote: > I'm a little worried that this whole question of changing the file > naming scheme is a diversion which will result in torpedoing any > chance of getting some kind of improvement here for v11. I don't > think the patch

Re: [HACKERS] increasing the default WAL segment size

On Tue, Mar 21, 2017 at 8:10 PM, Stephen Frost wrote: >> We've already >> created quite a few incompatibilities in this release, and I'm not >> entirely eager to just keep cranking them out at top speed. > > That position would seem to imply that you're in favor of keeping the

Re: [HACKERS] PUBLICATIONS and pg_dump

On 2/26/17 14:25, Petr Jelinek wrote: > Yeah that was oversight in initial patch, publications and their > membership was supposed to be dumped only when table filter is not used. > I mistakenly made it check for data_only instead of using the > selectDumpableObject machinery. Committed. --

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Wed, Mar 22, 2017 at 1:53 PM, Seki, Eiji wrote: > > Thank you for your review, again. > > I think your proposals are better, so I reflected them. Thanks for the updated patch. Patch looks good to me. I marked it as "ready for committer". While reviewing this

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 15 March 2017 at 21:56, Stephen Frost wrote: > Greetings, > > * Sachin Kotwal (kotsac...@gmail.com) wrote: >> Thanks. I understand this is small but new feature and not bug fix. >> But we should be able to backpatch if there is no dependency. > > No, it's a new feature and

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 22 March 2017 at 09:49, Craig Ringer wrote: >> Overall, though, I think that 0001 looks far better than any previous >> iteration. It's simple. It looks safe. It seems unlikely to break >> anything that works now. Woo hoo! > > Funny that this started with "hey,

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Peter Eisentraut writes: > No answer. Can we remove this chunk? >> +if (no_role_passwords && binary_upgrade) Perhaps, but why? ISTM that trying to run pg_upgrade as non-superuser is a nonstarter for a number of reasons, while if you're superuser you do

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Mar 22, 2017 at 3:51 AM, Mithun Cy wrote: > On Tue, Mar 21, 2017 at 8:10 PM, Robert Haas > wrote: > > If the WAL writing hides the loss, then I agree that's not a big > > concern. But if the loss is still visible even when WAL is

Re: [HACKERS] segfault in hot standby for hash indexes

On Tue, Mar 21, 2017 at 11:49 PM, Ashutosh Sharma wrote: >> >> I can confirm that that fixes the seg faults for me. > > Thanks for confirmation. > >> >> Did you mean you couldn't reproduce the problem in the first place, or that >> you could reproduce it and now the patch

Re: [HACKERS] Questionable tag usage

Peter Eisentraut writes: >> On 1/4/17 11:50 PM, Tom Lane wrote: >>> Anyway, bottom line is I'm not terribly excited about fixing just this >>> one place. I think we need to decide whether we like the new more-verbose >>> output for links. If we don't, we need

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On 2017-03-21 07:46:47 Haribabu Kommi wrote: >On Tue, Mar 21, 2017 at 3:16 PM, Seki, Eiji wrote: >+/* Use these flags in GetOldestXmin as "flags" */ > >How about some thing like the following. >/* Use the following flags as an input "flags" to GetOldestXmin function */ >

Re: [HACKERS] Logical decoding on standby

Hi all Updated timeline following patch attached. There's a change in read_local_xlog_page to ensure we maintain ThisTimeLineID properly, otherwise it's just comment changes. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &

[HACKERS] Replication status in logical replication

Hi all, When using logical replication, I ran into a situation where the pg_stat_replication.state is not updated until any wal record is sent after started up. For example, I set up logical replication with 2 subscriber and restart the publisher server, but I see the following status for a while

Re: [HACKERS] logical replication access control patches

On 3/20/17 15:10, Petr Jelinek wrote: > Hmm but REPLICATION role can do basebackup/consume wal, so how does > giving it limited publication access help? Wouldn't we need some > SUBSCRIPTION role/grant used instead for logical replication connections > instead of REPLICATION for this to make sense?

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Tue, Mar 21, 2017 at 7:18 PM, Peter Geoghegan wrote: >> As shown in 0008-hj-shared-buf-file-v8.patch. Thoughts? > > A less serious issue I've also noticed is that you add palloc() calls, > implicitly using the current memory context, within buffile.c. > BufFileOpenTagged() has

Re: [HACKERS] Logical decoding on standby

On 21 March 2017 at 09:05, Craig Ringer wrote: > Thanks, that's a helpful point. The commit in question is 978b2f65. I > didn't notice that it introduced XLogReader use in twophase.c, though > I should've realised given the discussion about fetching recent 2pc > info from

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Tue, Mar 21, 2017 at 5:07 AM, Thomas Munro wrote: >> buffile.c should stop pretending to care about anything other than >> temp files, IMV. 100% of all clients that want temporary files go >> through buffile.c. 100% of all clients that want non-temp files (files

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 3/13/17 16:41, Peter Eisentraut wrote: > Why this? No answer. Can we remove this chunk? > + if (no_role_passwords && binary_upgrade) > + { > + fprintf(stderr, _("%s: options --no-role-passwords and > --binary-upgrade cannot be used together\n"), > +

Re: [HACKERS] Updating the "tool sets" documentation for modern FreeBSD

On 3/13/17 21:16, Thomas Munro wrote: > For several operating systems we give handy package manager one-liners > to install all the requirements for building our documentation. All > current production FreeBSD releases have a friendly new package > manager a bit like apt/yum, so here's a

Re: [HACKERS] Speedup twophase transactions

On Fri, Mar 17, 2017 at 5:15 PM, Michael Paquier wrote: > On Fri, Mar 17, 2017 at 5:00 PM, Nikhil Sontakke > wrote: >> Micheal, it looks like you are working on a final version of this patch? I >> will wait to review it from my end, then. > > I

Re: [HACKERS] Unacccented Fractions

On 3/13/17 23:01, David E. Wheeler wrote: > I noticed that unaccent.rules has spaces in front of the unaccented > representation of fraction glyphs: > This makes sense to me, as I’d like “1¼”, for example to become “1 1/4”. > However, that’s not what seems to happen: These leading spaces come

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

On Tue, Mar 7, 2017 at 4:09 PM, Ideriha, Takeshi < ideriha.take...@jp.fujitsu.com> wrote: > > Attached 004_declareStmt_test_v5.patch is a rebased one. > The rest of patches are same as older version. > Thanks for the update patch. I started reviewing the patches. There was a minor conflict in

Re: [HACKERS] Questionable tag usage

On 1/11/17 11:55, Peter Eisentraut wrote: > On 1/4/17 11:50 PM, Tom Lane wrote: >> Anyway, bottom line is I'm not terribly excited about fixing just this >> one place. I think we need to decide whether we like the new more-verbose >> output for links. If we don't, we need to fix the markup rules

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 22 March 2017 at 01:49, Robert Haas wrote: > /me smacks forehead. Actually, it should be CLogTruncationLock, with > a capital L, for consistency with CLogControlLock. Will do. > The new lock needs to be added to the table in monitoring.sgml. Same. > I don't think

Re: [HACKERS] Logical replication existing data copy

This patch is looking pretty good to me, modulo the failing pg_dump tests. Attached is a fixup patch. I have mainly updated some comments and variable naming for (my) clarity. No functional changes. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] Logical replication existing data copy

On 3/20/17 19:54, Petr Jelinek wrote: > Here is fixed version, also rebased on top of all the changes to pg_dump > tests. Subscriptions are dumped unless --no-subscriptions is specified. The problem with that is that pg_dump will now fail for unprivileged users. That's a separate problem to

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Wed, Mar 22, 2017 at 5:38 AM, Thomas Munro wrote: > Isn't that one row short? What happened to this one? > > 10.0.0.0/8 | 10::/8 Actually, In my last test I did not connect to regression database, I have simply taken table and the few rows from

Re: [HACKERS] identity columns

On 3/21/17 16:11, Vitaly Burovoy wrote: > I've just checked and still get an error about a type, not about > absence of a column: > test=# CREATE TABLE itest3 (a int generated by default as identity, b text); > CREATE TABLE > test=# ALTER TABLE itest3 ALTER COLUMN o ADD GENERATED ALWAYS AS

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

>>I like the idea taking advantage of linestyle utilities >>to implement rst and markdown format efficiently instead of newly developing >>pset format things. >>But I'm thinking two comments below needs change to something about not >>focusing only linestyle. >>That's because they really take

Re: [HACKERS] patch proposal

On Tue, Mar 21, 2017 at 8:46 AM, David Steele wrote: > Hi Venkata, > > On 2/28/17 11:59 PM, Venkata B Nagothi wrote: > >> On Wed, Mar 1, 2017 at 1:14 AM, Venkata B Nagothi > > wrote: >> On Tue, Jan 31, 2017 at 6:49 AM, David

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Mar 21, 2017 at 2:49 PM, Thomas Munro wrote: > I'm going to experiment with refactoring the v10 parallel CREATE INDEX > patch to use the SharedBufFileSet interface from > hj-shared-buf-file-v8.patch today and see what problems I run into. I would be happy

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Mar 21, 2017 at 12:15 PM, Robert Haas wrote: > Wouldn't it break on-disk compatibility with existing btree indexes? Yes, it would, but see my later remarks on pd_prune_xid. I think that that would be safe. > I think we're still trying to solve a problem that Simon

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, Am Mittwoch, den 22.03.2017, 00:40 +0100 schrieb Michael Banck: > I guess if we decide (physical) slots should not be created implicitly, > then using the same UI as pg_receivewal makes sense for the sake of > consistency, i.e. "--slot=name --create-slot [--if-not-exists]". That is > rather

Re: [HACKERS] increasing the default WAL segment size

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Mar 21, 2017 at 6:02 PM, David Steele wrote: > > The biggest downside I can see is that this would change the naming scheme > > for the default of 16MB compared to previous versions of Postgres. However, > > for

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Wed, Mar 22, 2017 at 1:21 AM, Dilip Kumar wrote: > postgres=# SELECT * FROM inet_tbl WHERE i <> '192.168.1.0/24'::cidr > ORDER BY i; > c |i > +-- > 10.0.0.0/8 | 9.1.2.3/8 > 10.0.0.0/8 |

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On Wed, Mar 22, 2017 at 1:56 AM, David Steele wrote: > Hi Michael, > > On 3/10/17 9:15 AM, Peter Eisentraut wrote: >> >> On 3/9/17 17:03, Michael Paquier wrote: >>> >>> Having something like --limit-retained-segments partially addresses >>> it, as long as there is a way to

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Am Dienstag, den 21.03.2017, 15:34 -0400 schrieb Robert Haas: > On Sun, Mar 19, 2017 at 12:01 PM, Magnus Hagander wrote: > > I think maybe we should output a message when the slot is created, at least > > in verbose mode, to make sure people realize that happened. Does that

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Mar 21, 2017 at 2:03 PM, Robert Haas wrote: > I agree that the extent to which code reuse is possible here is > somewhat unclear, but I am 100% confident that the answer is non-zero. > You and Thomas both need BufFiles that can be shared across multiple > backends

[HACKERS] Aggregates and row types

Hi, Is is expected that the first query below can be analysed and planned, but the second can't? explain select x from (select row(42)) s(x); explain select count(x) from (select row(42)) s(x); ERROR: record type has not been registered That may be a strange thing to want to do, but it's

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On 3/21/17 2:34 PM, Fujii Masao wrote: On Tue, Mar 21, 2017 at 11:03 AM, Tsunakawa, Takayuki wrote: From: David Steele [mailto:da...@pgmasters.net] Well, that's embarrassing. When I recreated the function to add defaults I messed up the AS clause and did not

Re: [HACKERS] increasing the default WAL segment size

On Tue, Mar 21, 2017 at 6:02 PM, David Steele wrote: > The biggest downside I can see is that this would change the naming scheme > for the default of 16MB compared to previous versions of Postgres. However, > for all other wal-seg-size values changes would need to be made

Re: [HACKERS] [PATCH] Removes uninitialized variable compiler warning

We can disregard this patch. It appears that PointerGetDatum initializes lenlemm. On Mon, Mar 20, 2017 at 10:04 AM, Tom Lane wrote: > Todd Sedano writes: > > This patch removes a compiler warning. > > warning: variable 'lenlemm' is uninitialized when

Re: [HACKERS] increasing the default WAL segment size

On 3/21/17 15:22, Robert Haas wrote: > If you take the approach that Beena did, then you lose the > correspondence with LSNs, which is admittedly not great but there are > already helper functions available to deal with LSN -> filename > mappings and I assume those will continue to work. If you

Re: [HACKERS] Monitoring roles patch

On 2/24/17 05:14, Dave Page wrote: > - Adds a default role called pg_read_all_gucs > - Allows members of pg_read_all_gucs to, well, read all GUCs > - Grants pg_read_all_gucs to pg_monitor Maybe pg_read_all_settings? Consistent with pg_settings. -- Peter Eisentraut

Re: [HACKERS] cast result of copyNode()

> On Mar 21, 2017, at 2:13 PM, David Steele wrote: > > Hi Mark, > > On 3/9/17 3:34 PM, Peter Eisentraut wrote: >> On 3/7/17 18:27, Mark Dilger wrote: >>> You appear to be using a #define macro to wrap a function of the same name >>> with the code: >>> >>> #define

Re: [HACKERS] [PATCH] few fts functions for jsonb

> On 21 March 2017 at 03:03, Andrew Dunstan wrote: > > However, I think it should probably be broken up into a couple of pieces - > one for the generic json/jsonb transforms infrastructure (which probably > needs some more comments) and one for the FTS functions

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 03/16/2017 05:32 PM, David Steele wrote: > On 2/25/17 1:27 PM, Peter Eisentraut wrote: >> Something that has been bothering me in PL/Python for a long time is the >> non-object-oriented way in which plans are prepared and executed: >> >> plan = plpy.prepare(...) >> res =

[HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

Hi Alexander, On 3/11/17 7:06 AM, Pavel Stehule wrote: I am sending a updated version with separated sort direction in special variable There is a question. Has desc direction sense for columns like schema or table name? Using desc, asc for size is natural. But for tablename? Do you know

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 8:10 PM, Robert Haas wrote: > If the WAL writing hides the loss, then I agree that's not a big > concern. But if the loss is still visible even when WAL is written, > then I'm not so sure. The tests table schema was taken from earlier tests what

Re: [HACKERS] increasing the default WAL segment size

On 3/21/17 3:22 PM, Robert Haas wrote: On Tue, Mar 21, 2017 at 9:04 AM, Stephen Frost wrote: In short, I'm also concerned about this change to make WAL file names no longer match up with LSNs and also about the odd stepping that you get as a result of this change when it

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On Wed, Mar 22, 2017 at 6:24 AM, Andrew Dunstan wrote: > This is really a pretty small patch all things considered, and pretty > low-risk (although I haven;t been threough the code in fine detail yet). > In the end I'm persuaded by Andres' point that there's

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Mar 22, 2017 at 10:03 AM, Robert Haas wrote: > On Tue, Mar 21, 2017 at 3:50 PM, Peter Geoghegan wrote: >> I disagree with that. It is a >> trade-off, I suppose. I have now run out of time to work through it >> with you or Thomas, though. > > Bummer.

Re: [HACKERS] logical replication apply to run with sync commit off by default

On 21/03/17 18:54, Robert Haas wrote: > On Mon, Mar 20, 2017 at 7:56 PM, Petr Jelinek > wrote: >> On 18/03/17 13:31, Petr Jelinek wrote: >>> On 07/03/17 06:23, Petr Jelinek wrote: there has been discussion at the logical replication initial copy thread [1]

Re: [HACKERS] PATCH: recursive json_populate_record()

On 3/21/17 2:31 PM, Andrew Dunstan wrote: On 03/21/2017 01:37 PM, David Steele wrote: >> This thread has been idle for months since Tom's review. The submission has been marked "Returned with Feedback". Please feel free to resubmit to a future commitfest. Please revive. I am planning to

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On 03/04/2017 01:08 AM, Robert Haas wrote: > On Thu, Mar 2, 2017 at 5:02 AM, Michael Paquier > wrote: >> On Thu, Mar 2, 2017 at 2:26 AM, David Steele wrote: >>> This patch is in need of a committer. Any takers? >>> I didn't see a lot of

Re: [HACKERS] Should we cacheline align PGXACT?

Hi Alexander On 3/10/17 8:08 AM, Alexander Korotkov wrote: Results look good for me. Idea of committing both of patches looks attractive. We have pretty much acceleration for read-only case and small acceleration for read-write case. I'll run benchmark on 72-cores machine as well. Have you

[HACKERS] Re: Declarative partitioning optimization for large amount of partitions

On 3/10/17 7:16 AM, Aleksander Alekseev wrote: Thanks a lot for the review! Anyone want to take a crack at reviewing this new version? Thanks, -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] cast result of copyNode()

Hi Mark, On 3/9/17 3:34 PM, Peter Eisentraut wrote: On 3/7/17 18:27, Mark Dilger wrote: You appear to be using a #define macro to wrap a function of the same name with the code: #define copyObject(obj) ((typeof(obj)) copyObject(obj)) Yeah, that's a bit silly. Here is an updated version

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Mar 21, 2017 at 3:50 PM, Peter Geoghegan wrote: > On Tue, Mar 21, 2017 at 12:06 PM, Robert Haas wrote: >> From my point of view, the main point is that having two completely >> separate mechanisms for managing temporary files that need to be >> shared

Re: [HACKERS] [COMMITTERS] pgsql: Add missing support for new node fields

Hello Robert, IMHO, what would be a lot more useful than something that generates {read,equal,copy,out}funcs.c automatically would be something that just checks them for trivial errors of omission. Hmmm. Checking for errors is actually more complicated than generating the function: basically

Re: [HACKERS] [COMMITTERS] pgsql: Add missing support for new node fields

Hello Andres, It is not done yet, but it looks that it can work in the end with limited effort. Currently it works for copy & equal. It'd have to do out/read as well imo. Sure. This part is WIP, though. Is there some interest to generate the x00kB of sources rather than edit them

Re: [HACKERS] Monitoring roles patch

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Looks good. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [PATCH] Generic type subscripting

> On 21 March 2017 at 18:16, David Steele wrote: > > This thread has been idle for over a week. Yes, sorry for the late reply. I'm still trying to find a better solution for some of the problems, that arose in this patch. > On 15 March 2017 at 00:10, Tom Lane

Re: [HACKERS] identity columns

I haven't seen a patch (I'll do it later), just few notes: On 3/21/17, Peter Eisentraut wrote: 3. Strange error (not about absence of a column; but see pp.5 and 8): test=# ALTER TABLE idnt ALTER COLUMN o ADD GENERATED ALWAYS AS IDENTITY;

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Thomas Munro wrote: > What is your motivation for using DSA? It seems you are creating an > area and then using it to make exactly one allocation of a constant > size known up front to hold your fixed size workitems array. You > don't do any dynamic allocation at runtime, apart from the detail

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 04:56:16PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Tue, Mar 21, 2017 at 04:43:58PM -0300, Alvaro Herrera wrote: > > > Bruce Momjian wrote: > > > > > > > I don't think it makes sense to try and save bits and add complexity > > > > when we have no idea if

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

Thomas Munro wrote: > Another thought about this design: Why autovacuum? One reason is that autovacuum is already there, so it's convenient to give it the responsibility for this kind of task. Another reason is that autovacuum is already doing this, via vacuum. I don't see the need to have a

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Bruce Momjian wrote: > On Tue, Mar 21, 2017 at 04:43:58PM -0300, Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > > > I don't think it makes sense to try and save bits and add complexity > > > when we have no idea if we will ever use them, > > > > If we find ourselves in dire need of

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Mar 21, 2017 at 12:06 PM, Robert Haas wrote: > From my point of view, the main point is that having two completely > separate mechanisms for managing temporary files that need to be > shared across cooperating workers is not a good decision. That's a > need that's

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 04:43:58PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > I don't think it makes sense to try and save bits and add complexity > > when we have no idea if we will ever use them, > > If we find ourselves in dire need of additional bits, there is a known >

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Bruce Momjian wrote: > I don't think it makes sense to try and save bits and add complexity > when we have no idea if we will ever use them, If we find ourselves in dire need of additional bits, there is a known mechanism to get back 2 bits from old-style VACUUM FULL. I assume that the reason

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

On Sun, Mar 19, 2017 at 12:01 PM, Magnus Hagander wrote: > I think maybe we should output a message when the slot is created, at least > in verbose mode, to make sure people realize that happened. Does that seem > reasonable? Slots are great until you leave one lying around

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Tue, Mar 21, 2017 at 6:36 AM, Dilip Kumar wrote: > On Tue, Mar 21, 2017 at 3:36 PM, Rafia Sabih > wrote: >> On Wed, Mar 15, 2017 at 8:55 PM, Robert Haas wrote: >>> Note this: >>> >>> if (completed ||

Re: [HACKERS] increasing the default WAL segment size

On Tue, Mar 21, 2017 at 9:04 AM, Stephen Frost wrote: > In short, I'm also concerned about this change to make WAL file names no > longer match up with LSNs and also about the odd stepping that you get > as a result of this change when it comes to WAL file names. OK, that's a

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Mar 14, 2017 at 6:10 PM, Peter Geoghegan wrote: > On Tue, Mar 14, 2017 at 2:48 PM, Peter Geoghegan wrote: >> I think that that's safe, but it is a little disappointing that it >> does not allow us to skip work in the case that you really had in mind >> when

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Mar 21, 2017 at 2:03 PM, Peter Geoghegan wrote: > I think that since the comment refers to code from before 1999, it can > go. Any separate patch to remove it would have an entirely negative > linediff. It's a good general principle that a patch should do one thing well and

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 11:54:25PM +0530, Pavan Deolasee wrote: > We can also save HEAP_WARM_UPDATED flag since this is required only for > abort-handling case. We can find a way to push that information down to the > old > tuple if UPDATE aborts and we detect the broken chain. Again, not fully

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 11:45:09PM +0530, Pavan Deolasee wrote: > Early in the discussion we talked about allowing multiple changes per > WARM chain if they all changed the same index and were in the same > direction so there were no duplicates, but it was complicated.  There > was

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 07:05:15PM +0100, Petr Jelinek wrote: > >> Well, I don't want to rule it out either, but if we do a release to > >> which you can't pg_upgrade, it's going to be really painful for a lot > >> of users. Many users can't realistically upgrade using pg_dump, ever. > >> So

Re: [HACKERS] Supporting huge pages on Windows

On 3/8/17 8:36 PM, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Sharma To start with, I ran the regression test-suite and didn't find any failures. But, then I am not sure if huge_pages are getting used or

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On 3/7/17 9:42 PM, Pavan Deolasee wrote: Fair point. I'm not going to "persist" with the idea too long. It seemed like a good, low-risk feature to me which can benefit certain use cases quite reasonably. It's not uncommon to create indexes (or reindex existing indexes to remove index bloats) on

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On Tue, Mar 21, 2017 at 11:03 AM, Tsunakawa, Takayuki wrote: > From: David Steele [mailto:da...@pgmasters.net] >> Well, that's embarrassing. When I recreated the function to add defaults >> I messed up the AS clause and did not pay attention to the results of the

Re: [HACKERS] PATCH: recursive json_populate_record()

On 03/21/2017 01:37 PM, David Steele wrote: > On 3/16/17 11:54 AM, David Steele wrote: >> On 2/1/17 12:53 AM, Michael Paquier wrote: >>> On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote: Nikita Glukhov writes: > On 25.01.2017 23:58, Tom Lane

Re: [HACKERS] Freeze on Cygwin w/ concurrency

On 03/20/2017 11:47 PM, Noah Misch wrote: > "pgbench -i -s 50; pgbench -S -j2 -c16 -T900 -P5" freezes consistently on > Cygwin 2.2.1 and Cygwin 2.6.0. (I suspect most other versions are affected.) > I've pinged[1] the Cygwin bug thread with some additional detail. If a Cygwin > buildfarm

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 10:34 PM, Robert Haas wrote: > On Tue, Mar 21, 2017 at 12:49 PM, Bruce Momjian wrote: > > On Tue, Mar 21, 2017 at 09:25:49AM -0400, Robert Haas wrote: > >> On Tue, Mar 21, 2017 at 8:41 AM, Pavan Deolasee > >> > TBH I see many

Re: [HACKERS] [WIP] RE: DECLARE STATEMENT setting up a connection in ECPG

Hi Haribabu, On 3/7/17 12:09 AM, Ideriha, Takeshi wrote: I tried applying your patches. But it failed... The error messages are as below. Attached 004_declareStmt_test_v5.patch is a rebased one. The rest of patches are same as older version. Regards, Ideriha, Takeshi You are signed up to

Re: [HACKERS] perlcritic

Hi Daniel, On 3/6/17 12:02 PM, Dagfinn Ilmari Mannsåker wrote: ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: Hi Peter, Peter Eisentraut writes: I posted this about 18 months ago but then ran out of steam. [ ] Here is an updated patch. The testing

Re: [HACKERS] segfault in hot standby for hash indexes

Hi Jeff, > > I can confirm that that fixes the seg faults for me. Thanks for confirmation. > > Did you mean you couldn't reproduce the problem in the first place, or that > you could reproduce it and now the patch fixes it? If the first of those, I > forget to say you do have to wait for hot

Re: [HACKERS] Page Scan Mode in Hash Index

Hi, On 02/14/2017 12:27 AM, Ashutosh Sharma wrote: Currently, Hash Index scan works tuple-at-a-time, i.e. for every qualifying tuple in a page, it acquires and releases the lock which eventually increases the lock/unlock traffic. For example, if an index page contains 100 qualified tuples, the

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 2:03 PM, Petr Jelinek wrote: > This is why I like the idea of pluggable storage, if we ever get that it > would buy us ability to implement completely different heap format > without breaking pg_upgrade. You probably won't be surprised to

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Mar 21, 2017 at 1:21 PM, Simon Riggs wrote: >> The decision not to require the attribute numbers to match doesn't >> necessarily mean we can't get rid of the Append node, though. First >> of all, in a lot of practical cases the attribute numbers will all >> match.

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 21, 2017 at 10:47 PM, Bruce Momjian wrote: > On Tue, Mar 21, 2017 at 01:04:14PM -0400, Robert Haas wrote: > > > I know we have talked about it, but not recently, and if everyone else > > > is fine with it, I am too, but I have to ask these questions. > > > > I think

  1   2   3   >