Re: [HACKERS] Possible regression with gather merge.

Thanks for reporting, I am looking into this. On Wed, Mar 22, 2017 at 11:51 AM, Mithun Cy wrote: > Adding more rows to table make gather merge execution time very slow > when compared to non-parallel plan we get after disabling gather > merge. > > create table test as (select id, (random()*1

Re: [HACKERS] Possible regression with gather merge.

Adding more rows to table make gather merge execution time very slow when compared to non-parallel plan we get after disabling gather merge. create table test as (select id, (random()*1)::int as v1, random() as v2 from generate_series(1,1) id); postgres=# set max_parallel_workers_per_

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; >> QUERY PLAN >> -

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. >> >> >> Implemented as attached. >>

[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 adju

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 process, > BackendId is used to refer the backend status in

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 war

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 that

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 Well, ideally that wouldn't ha

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 is all that far from be

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 > current default of

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. -- Pete

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 patch, I found that PGXACT->vacu

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 won't be back-patched

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, here's a simple, non-invasiv

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 not need --no-role-passwords.

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 written, > > then I'm not so sure. > > The tests table sc

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 fixes it? If the first o

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 to fix the markup rules to not do >>

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 */ > > >+/* Ignore vacuum backe

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 & Service

[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 some, for exampl

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 xlog. I don't see any po

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 >> which are not marked FD_TEMPO

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 documenta

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 have to admit that I am beginning to get drawn into

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 a

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 ap

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 the new header comments i

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] 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 Suppo

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 solve

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 inet.sql so it was only 16 rows even wi

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 IDENTITY

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 Steele > >

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 if you took over parallel CREATE

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 postulated in > advance

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 ve

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 all other wal-seg-siz

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 | 10.1.2.3/8 > 10.0.0.0/32

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 define an automatic mode

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 seem > > reasonable? >

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 associated with the same

[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 somet

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 pay attention to the results of th

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 anyway. I think changi

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 used here > > [-Wuninitialized] > > Hm, on

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 tak

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 http://www.2ndQua

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 copyObject(obj) ((typeof(obj))

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 that will use it. Sure, here are t

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 = plpy.execute(p

[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 wh

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 Pavan has posted [1], henc

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 comes to WAL file names

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 actually no > practical alternative way

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. I'm going to experiment with refactori

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] about making apply work with sy

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 loo

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 enthusiasm from committers on the thread >> Stephen at le

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 h

[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: http://www

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 that

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 across cooperating workers is not a g

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 everytim

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 (pgsql-ha

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 wrote: > Dmitry Dolgov <9erthali...

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; ERROR: identity column type must be sm

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 t

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 w

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 c

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 addition

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 going to come up over an

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 > mechani

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 no

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 by accident. I'm afra

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 || !fcache->returnsSet) >>> postquel_end(es); >>> >>> When the SQL function

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 bit surprising to me

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 writing the patch. Better than

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 not make unrel

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 they'

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 n

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 >> regression tests, apparently.

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 wrote: >> I think you need to take a seco

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 member

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 artificial scenarios here. It will be very use

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 instructions below still apply. Esp

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 st

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 c

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 hear that I agree. :-) -- Rober

  1   2   3   >