Re: [HACKERS] contrib modules and relkind check

Sorry about the absence on this thread. On 2017/02/14 15:30, Michael Paquier wrote: > On Tue, Feb 14, 2017 at 3:18 PM, Amit Langote wrote: >> >> Added more tests in pgstattuple and the new ones for pg_visibility, >> although I may have overdone the latter. > > A bonus idea is also to add tests

Re: [HACKERS] GUC for cleanup indexes threshold.

On Sat, Mar 4, 2017 at 4:37 AM, Peter Geoghegan wrote: > On Fri, Mar 3, 2017 at 8:13 AM, Masahiko Sawada wrote: >> Thank you for clarification. Let me check my understanding. IIUC, >> skipping second index vacuum path (lazy_cleanup_index) can not be >> cause

Re: [HACKERS] ANALYZE command progress checker

On Tue, Mar 7, 2017 at 5:01 PM, Michael Paquier wrote: > > @@ -496,7 +499,6 @@ do_analyze_rel(Relation onerel, int options, > VacuumParams *params, > numrows = (*acquirefunc) (onerel, elevel, > rows, targrows, >

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

On 2017/03/07 14:04, Tom Lane wrote: > Amit Langote writes: >> Also, I found out that alter_table.sql mistakenly forgot to drop >> partitioned table "p1". Patch 0002 takes care of that. > > While that might or might not have been intentional, I think it's an >

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

On Tue, Mar 7, 2017 at 11:18 AM, Amit Kapila wrote: > On Tue, Mar 7, 2017 at 10:22 AM, Ashutosh Sharma > wrote: >>> I also think that commit didn't intend to change the behavior, >>> however, the point is how sensible is it to keep such behavior

Re: [HACKERS] ANALYZE command progress checker

On Mon, Mar 6, 2017 at 3:58 PM, Andres Freund wrote: > On 2017-03-03 15:33:15 -0500, David Steele wrote: >> On 3/1/17 1:25 PM, Andres Freund wrote: >> > On 2017-03-01 10:20:41 -0800, David Fetter wrote: >> >> On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: >>

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

On Tue, Mar 7, 2017 at 10:22 AM, Ashutosh Sharma wrote: >> I also think that commit didn't intend to change the behavior, >> however, the point is how sensible is it to keep such behavior after >> Parallel Append. I am not sure if this is the right time to consider >> it

Re: [HACKERS] allow referring to functions without arguments when unique

On Fri, Mar 3, 2017 at 4:12 PM, Michael Paquier wrote: > On Wed, Mar 1, 2017 at 11:50 AM, Peter Eisentraut > wrote: >> This is the "grand finale" that goes on top of the "DROP FUNCTION of >> multiple functions" patch set. The purpose

Re: [HACKERS] [NOVICE] opr_charset rule in gram.y

Neha Khatri writes: > I was going through the grammer rule for Character types in gram.y and > found an optional sub rule in is "opt_charset" This question seems quite off-topic for pgsql-novice, so I've redirected it to pgsql-hackers. > CharacterWithLength: character

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

Hi, there has been discussion at the logical replication initial copy thread [1] about making apply work with sync commit off by default for performance reasons and adding option to change that per subscription. Here I propose patch to implement this - it adds boolean column subssynccommit to

Re: [HACKERS] increasing the default WAL segment size

Hi, I took a look at this patch. Overall, the patch looks good to me. However, there are some review comments that I would like to share, 1. I think the macro 'PATH_MAX' used in pg_waldump.c file is specific to Linux. It needs to be changed to some constant value or may be MAXPGPATH inorder to

Re: [HACKERS] Partitioned tables and relfilenode

I see that all the changes by Amit and myself to what was earlier 0003 patch are now part of 0002 patch. The patch looks ready for committer. Some comments about 0003 patch. CREATE TABLE syntax seems to allow specifying reloptions for a partitioned table. But extractRelOptions() and

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

Amit Langote writes: > Also, I found out that alter_table.sql mistakenly forgot to drop > partitioned table "p1". Patch 0002 takes care of that. While that might or might not have been intentional, I think it's an astoundingly bad idea to not leave any partitioned

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

On 2017/03/07 10:49, Michael Paquier wrote: > On Tue, Mar 7, 2017 at 10:37 AM, Amit Langote > wrote: >> On 2017/03/07 7:28, Tom Lane wrote: >>> Kevin Grittner writes: With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`,

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

> I also think that commit didn't intend to change the behavior, > however, the point is how sensible is it to keep such behavior after > Parallel Append. I am not sure if this is the right time to consider > it or shall we wait till Parallel Append is committed. > >> I think the problem here is

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Mon, Mar 6, 2017 at 3:57 PM, Andres Freund wrote: > I'm ok with not immediately doing so, but I think Peter's design isn't > in line with achieving something like this. I would be okay with doing this if we had a grab-bag of expensive checks, that all pretty much require

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On Tue, Mar 7, 2017 at 9:33 AM, Etsuro Fujita wrote: > On 2017/03/06 21:22, Ashutosh Bapat wrote: >> >> On Mon, Mar 6, 2017 at 1:29 PM, David Rowley >> wrote: >>> >>> On 6 March 2017 at 18:51, Etsuro Fujita

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 2 March 2017 at 16:06, Amit Kapila wrote: > On Wed, Mar 1, 2017 at 5:32 PM, David Rowley > wrote: >> Hackers, >> >> I've attached a small patch which aims to improve the performance of >> AccessExclusiveLock when there are many

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On 2017/03/06 21:22, Ashutosh Bapat wrote: On Mon, Mar 6, 2017 at 1:29 PM, David Rowley wrote: On 6 March 2017 at 18:51, Etsuro Fujita wrote: On 2017/03/06 11:05, David Rowley wrote: I looked over yours and was surprised to see: +

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

On Tue, Mar 7, 2017 at 3:24 AM, Robert Haas wrote: > On Sun, Mar 5, 2017 at 9:41 PM, Amit Kapila wrote: >>> RCA: >>> >>> From "Replace min_parallel_relation_size with two new GUCs" commit >>> onwards, we are not assigning parallel workers for

Re: [HACKERS] Logical replication existing data copy

On 06/03/17 23:40, Erik Rijkers wrote: > On 2017-03-06 16:10, Erik Rijkers wrote: >> On 2017-03-06 11:27, Petr Jelinek wrote: >>> Hi, >>> >>> updated and rebased version of the patch attached. >>> >> >> I compiled with /only/ this one latest patch: >>

Re: [HACKERS] Report the number of skipped frozen pages by manual VACUUM

On Mon, Mar 6, 2017 at 12:12 PM, Yugo Nagata wrote: > Hi, > > I think this is good since the information is useful and it is > a little change. Thank you for reviewing this patch! > > One thing I'm bothered is that even when the number of frozen page is > one, it will say

Re: [HACKERS] Re: check failure with -DRELCACHE_FORCE_RELEASE -DCLOBBER_FREED_MEMORY

On 03/06/2017 05:14 PM, Tom Lane wrote: > I wrote: >> I fixed that, and the basic regression tests no longer crash outright with >> these settings, but I do see half a dozen errors that all seem to be in >> RLS-related tests. > Those turned out to all be the same bug in DoCopy. "make

Re: [HACKERS] Small fix to postgresql.conf.sample's comment on max_parallel_workers

On 7 March 2017 at 15:21, Amit Kapila wrote: > +1. How about changing the description of > max_parallel_workers_per_gather to "taken from max_worker_processes, > limited by max_parallel_workers"? Thanks for looking. Seems more accurate to say that it's "taken from

Re: [HACKERS] Small fix to postgresql.conf.sample's comment on max_parallel_workers

On Tue, Mar 7, 2017 at 6:39 AM, David Rowley wrote: > While scanning over postgresql.conf I happened to notice something > that didn't ring quite true about max_parallel_workers. The comment > confuses worker_processes with parallel workers. > +1. How about

Re: [HACKERS] adding an immutable variant of to_date

On 03/03/2017 10:41 PM, Sven R. Kunze wrote: What do you think? I have some thoughts: 1) I do not think we currently allow setting the locale like this anywhere, so this will introduce a new concept to PostgreSQL. And you will probably need to add support for caching per locale. 2) As far

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On Tue, Mar 7, 2017 at 5:03 AM, Peter Eisentraut wrote: > On 3/3/17 20:30, Michael Paquier wrote: >> Yeah, it looks sensible to me to keep "replication" for physical >> replication, and switch logical replication checks to match a database >> name in hba

Re: [HACKERS] wait events for disk I/O

On Tue, Mar 7, 2017 at 5:27 AM, Robert Haas wrote: > On Mon, Mar 6, 2017 at 3:27 AM, Rushabh Lathia > wrote: >> Yes, I thought of adding wait event only for the sync but then recording the >> wait event for both write and sync. I understand that

Re: [HACKERS] Restricting maximum keep segments by repslots

On 28 February 2017 at 12:27, Petr Jelinek wrote: >> This patch adds a GUC to put a limit to the number of segments >> that replication slots can keep. Hitting the limit during >> checkpoint shows a warining and the segments older than the limit >> are removed. >>

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/03/06 17:22, Michael Paquier wrote: > On Mon, Mar 6, 2017 at 4:18 PM, Amit Langote > wrote: >> About autovacuum_* parameters - we currently don't handle partitioned >> tables in autovacuum.c, because no statistics are reported for them. That >> is,

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

Hi Aleksander, On 2017/03/07 0:22, Aleksander Alekseev wrote: > Hello. > > OK, here is a patch. > > Benchmark, before: > > ``` > number of transactions actually processed: 1823 > latency average = 1153.495 ms > latency stddev = 154.366 ms > tps = 6.061104 (including connections establishing) >

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

On Tue, Mar 7, 2017 at 10:37 AM, Amit Langote wrote: > On 2017/03/07 7:28, Tom Lane wrote: >> Kevin Grittner writes: >>> With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`, >>> `make install-world`, a fresh default initdb, a start

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

On 2017/03/07 7:28, Tom Lane wrote: > Kevin Grittner writes: >> With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`, >> `make install-world`, a fresh default initdb, a start with default >> config, `make installcheck`, connected to the regression database >> with

[HACKERS] Small fix to postgresql.conf.sample's comment on max_parallel_workers

While scanning over postgresql.conf I happened to notice something that didn't ring quite true about max_parallel_workers. The comment confuses worker_processes with parallel workers. The attached aims to put this right. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 2017-03-06 19:45:27 -0500, Tom Lane wrote: > Stephen Frost writes: > > * Andres Freund (and...@anarazel.de) wrote: > >> I'm not quite sure what the best way to attack this is, but I think we > >> need to do something. > > > I tend to agree with this, though I haven't got

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, Mar 7, 2017 at 3:21 AM, Robert Haas wrote: > On Sat, Mar 4, 2017 at 10:32 AM, Tom Lane wrote: >> Without having actually looked at this patch, I would say that if it added >> a direct call of fopen() to backend-side code, that was already the

Re: [HACKERS] Need a builtin way to run all tests faster manner

Stephen Frost writes: > * Andres Freund (and...@anarazel.de) wrote: >> I'm not quite sure what the best way to attack this is, but I think we >> need to do something. > I tend to agree with this, though I haven't got any great answers, > unfortunately. I don't want to reduce

Re: [HACKERS] dump a comment of a TSDictionary

Giuseppe Broccolo writes: > I've seen that pg_dump execute the dump of an eventual comment of a > TSDictionary without specifying the namespace where it is defined: > https://github.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_dump.c#L13542 Yup, this is

[HACKERS] on_dsm_detach() callback and parallel tuplesort BufFile resource management

Recap = A design goal of parallel tuplesort is that the parallel case be as close to possible as the serial case is already. Very little new code is needed in tuplesort.c and logtape.c, most of which is about using a new lower-level facility which is very well encapsulated. And, even

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > >> Can you provide some references on how other systems provide this feature? > > > > Oracle doesn't. > > Really? Sorry, my sentence was misleading. I meant by "Oracle/MySQL doesn't"

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-06 18:59:02 -0500, Robert Haas wrote: > On Mon, Mar 6, 2017 at 5:19 PM, Andres Freund wrote: > > The whole performance issue trigger this thread only exists when the > > hashtable sizes are mis-estimated, right? Turns out that after applying > > the just-committed

Re: [HACKERS] wait events for disk I/O

On Tue, Mar 7, 2017 at 8:57 AM, Robert Haas wrote: > On Mon, Mar 6, 2017 at 3:27 AM, Rushabh Lathia > wrote: >> Yes, I thought of adding wait event only for the sync but then recording the >> wait event for both write and sync. I understand that

Re: [HACKERS] Performance degradation in TPC-H Q18

On Mon, Mar 6, 2017 at 5:19 PM, Andres Freund wrote: > The whole performance issue trigger this thread only exists when the > hashtable sizes are mis-estimated, right? Turns out that after applying > the just-committed changes, that "fixing" the bad-mixing and/or doing >

Re: [HACKERS] wait events for disk I/O

On Mon, Mar 6, 2017 at 3:27 AM, Rushabh Lathia wrote: > Yes, I thought of adding wait event only for the sync but then recording the > wait event for both write and sync. I understand that OS level writes are > cheap but it still have some cost attached to that. Also I

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 2017-02-13 12:05:21 -0500, Robert Haas wrote: > On Fri, Feb 10, 2017 at 8:39 PM, Peter Geoghegan wrote: > > On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund wrote: > >> Except that the proposed names aren't remotely like that... ;). > > > > Revision attached --

Re: [HACKERS] contrib modules and relkind check

On Tue, Mar 7, 2017 at 3:10 AM, Corey Huinker wrote: > Michael, do you want to add yourself as a reviewer? Yes, thanks for the reminder. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Proposal : Parallel Merge Join

On Mon, Mar 6, 2017 at 8:15 AM, Dilip Kumar wrote: > On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas wrote: >> I'm not happy with the way this patch can just happen to latch on to a >> path that's not parallel-safe rather than one that is and then just

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

Hi, On 2017-02-13 11:52:53 -0500, Robert Haas wrote: > On Thu, Feb 9, 2017 at 5:32 PM, Andres Freund wrote: > >> > Again, some parts of the code doing something bad isn't a good argument > >> > for doing again. Releasing locks early is a bad pattern, because backend > >> >

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

On Tue, Mar 7, 2017 at 7:16 AM, Robert Haas wrote: > On Mon, Mar 6, 2017 at 3:26 PM, Peter Eisentraut > wrote: >> On 3/4/17 02:09, Michael Paquier wrote: >>> Well, that's one reason why I was thinking that having an independent >>> in-core

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-02 22:51:09 +0100, Tomas Vondra wrote: > Attaches is the last part of the patch series, rebased to current master and > adopting the new chunk header approach. Something seems to have gone awry while sending that - the attachement is a whopping 0 bytes... -- Sent via pgsql-hackers

Re: [HACKERS] rename pg_log directory?

On 02/27/2017 03:05 PM, Peter Eisentraut wrote: How about changing the default for log_directory from 'pg_log' to, say, 'log'? I have attached a patch which does this. I do not care much about which name is picked as long as we get rid off the "pg_" prefix. Btw, is there a reason for why

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-03-06 23:32:30 +0100, Tomas Vondra wrote: > > > The question however is whether this won't make the optimization > > > pointless. > > > I also, wonder how much we save by this optimization and how widely it's > > > used? Can someone point me to some numbers? > > > > I don't recall

Re: [HACKERS] Logical replication existing data copy

On 2017-03-06 16:10, Erik Rijkers wrote: On 2017-03-06 11:27, Petr Jelinek wrote: Hi, updated and rebased version of the patch attached. I compiled with /only/ this one latest patch: 0001-Logical-replication-support-for-initial-data-copy-v6.patch Is that correct, or are other patches

Re: [HACKERS] PATCH: two slab-like memory allocators

On 03/06/2017 08:08 PM, Andres Freund wrote: Hi, On 2017-03-06 19:49:56 +0100, Tomas Vondra wrote: On 03/06/2017 07:05 PM, Robert Haas wrote: On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote: On 2017-03-06 12:40:18 -0500, Robert Haas wrote: On Wed, Mar 1, 2017 at

Re: [HACKERS] Need a builtin way to run all tests faster manner

Andres, * Andres Freund (and...@anarazel.de) wrote: > There's also some tests simply taking way too long, e.g. the pg_dump > tests just do largely redundant tests for 30s. About half of the time in the pg_dump case, at least, appears to be in 010_dump_connstr.pl. I've not looked into it, but

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

Kevin Grittner writes: > With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`, > `make install-world`, a fresh default initdb, a start with default > config, `make installcheck`, connected to the regression database > with psql as the initial superuser, and ran:

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-06 16:58:23 -0500, Robert Haas wrote: > On Mon, Mar 6, 2017 at 3:32 PM, Andres Freund wrote: > >> I think DEBUG1 is far too high for something that could occur with > >> some frequency on a busy system; I'm fairly strongly of the opinion > >> that you ought to

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

On Mon, Mar 6, 2017 at 3:26 PM, Peter Eisentraut wrote: > On 3/4/17 02:09, Michael Paquier wrote: >> Well, that's one reason why I was thinking that having an independent >> in-core option to clean up the tail of the oldest segments is >> interesting: users don't

[HACKERS] Need a builtin way to run all tests faster manner

Hi, Right now check-world, a sensible thing to run before commits that aren't very narrow, takes a long time. To the point it seems to impact development velocity enough that it's more sensible to just skip it, and rely on the buildfarm. That's not a great solution. A large amount of the time

Re: [HACKERS] Re: check failure with -DRELCACHE_FORCE_RELEASE -DCLOBBER_FREED_MEMORY

I wrote: > I fixed that, and the basic regression tests no longer crash outright with > these settings, but I do see half a dozen errors that all seem to be in > RLS-related tests. Those turned out to all be the same bug in DoCopy. "make check-world" passes for me now with

Re: [HACKERS] dump a comment of a TSDictionary

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Do you want to deal with this whole mess, or shall I have a go at it? > > > I'm just about to push the pg_upgrade fixes for large object comments > > and security

Re: [HACKERS] Performance degradation in TPC-H Q18

On Mon, Mar 6, 2017 at 3:32 PM, Andres Freund wrote: >> I think DEBUG1 is far too high for something that could occur with >> some frequency on a busy system; I'm fairly strongly of the opinion >> that you ought to downgrade that by a couple of levels, say to DEBUG3 >> or so.

Re: [HACKERS] dump a comment of a TSDictionary

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Do you want to deal with this whole mess, or shall I have a go at it? > I'm just about to push the pg_upgrade fixes for large object comments > and security labels, followed not too far behind by the fix for

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

On Sun, Mar 5, 2017 at 9:41 PM, Amit Kapila wrote: >> RCA: >> >> From "Replace min_parallel_relation_size with two new GUCs" commit >> onwards, we are not assigning parallel workers for the child rel with >> zero heap pages. This means we won't be able to create a

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 03/06/2017 10:13 PM, Peter Eisentraut wrote: On 3/3/17 09:03, Tomas Vondra wrote: Attached is v2, fixing both issues. I wonder if + bytea *raw_page = PG_GETARG_BYTEA_P(0); + uargs->page = VARDATA(raw_page); is expected to work reliably, without copying the argument to a

[HACKERS] WARNING: relcache reference leak: relation "p1" not closed

With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`, `make install-world`, a fresh default initdb, a start with default config, `make installcheck`, connected to the regression database with psql as the initial superuser, and ran: regression=# vacuum freeze analyze; WARNING:

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

[original message held up for review -- should be along eventualy...] On Mon, Mar 6, 2017 at 3:11 PM, Kevin Grittner wrote: > With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`, > `make install-world`, a fresh default initdb, a start with default > config,

Re: [HACKERS] dump a comment of a TSDictionary

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Giuseppe Broccolo (giuseppe.brocc...@2ndquadrant.it) wrote: > >> I've seen that pg_dump execute the dump of an eventual comment of a > >> TSDictionary without specifying the namespace where it is defined: >

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 3/3/17 09:03, Tomas Vondra wrote: > Attached is v2, fixing both issues. I wonder if + bytea *raw_page = PG_GETARG_BYTEA_P(0); + uargs->page = VARDATA(raw_page); is expected to work reliably, without copying the argument to a different memory context. I think it would be better

Re: [HACKERS] dump a comment of a TSDictionary

Stephen Frost writes: > * Giuseppe Broccolo (giuseppe.brocc...@2ndquadrant.it) wrote: >> I've seen that pg_dump execute the dump of an eventual comment of a >> TSDictionary without specifying the namespace where it is defined: > Great catch! One of my smarter CS professors

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-04 11:09:40 +0530, Robert Haas wrote: > On Sat, Mar 4, 2017 at 5:56 AM, Andres Freund wrote: > > attached is a patch to address this problem, and the one reported by > > Dilip. I ran a lot of TPC-H and other benchmarks, and so far this > > addresses all the

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

On 3/4/17 02:09, Michael Paquier wrote: > Well, that's one reason why I was thinking that having an independent > in-core option to clean up the tail of the oldest segments is > interesting: users don't need to maintain their own infra logic to do > anything. Now this end-segment command can as

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

2017-03-06 19:45 GMT+01:00 Peter Eisentraut : > On 3/5/17 05:40, Jan Michálek wrote: > > jelen=# \pset linestyle rst > > Line style is rst. > > jelen=# \pset format wrapped > > Output format is wrapped. > > jelen=# SELECT repeat('Goodnight Irene ', 30); > >

Re: [HACKERS] rename pg_log directory?

Andreas Karlsson writes: > On 03/01/2017 05:49 AM, Peter Eisentraut wrote: >> On 2/27/17 09:51, Tom Lane wrote: >>> No objection to the basic point, but "log" seems perhaps a little too >>> generic to me. Would something like "server_log" be better? >> Well, "log" is pretty

Re: [HACKERS] Faster methods for getting SPI results

On 3/5/17 16:07, Jim Nasby wrote: >> There is nothing that requires us to materialize the results into an >> actual list of actual rows. We could wrap the SPI_tuptable into a >> Python object and implement __getitem__ or __iter__ to emulate sequence >> or mapping access. > Would it be possible to

Re: [HACKERS] rename pg_log directory?

On 03/01/2017 05:49 AM, Peter Eisentraut wrote: On 2/27/17 09:51, Tom Lane wrote: No objection to the basic point, but "log" seems perhaps a little too generic to me. Would something like "server_log" be better? Well, "log" is pretty well established. There is /var/log, and if you unpack a,

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 3/3/17 20:30, Michael Paquier wrote: > Yeah, it looks sensible to me to keep "replication" for physical > replication, and switch logical replication checks to match a database > name in hba comparisons. I think we are OK to move ahead with this. Another question would be why only enable

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

On Mon, Mar 6, 2017 at 9:36 AM, Robert Haas wrote: > On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan wrote: > > In my opinion, we expose query id (and dbid, and userid) as the > > canonical identifier for each pg_stat_statements entry, and have done > > so

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

Hi, This issue has bothered me in non-partitioned use-cases recently, so thanks for taking it up. On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote: > diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c > index 2fb9a8bf58..fa906e7930 100644 > ---

Re: [HACKERS] RADIUS fallback servers

On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell wrote: >>> I wonder if removing the complexity of maintaining two separate lists >>> for the server and port would be a better/less complex approach. For >>> instance, why not go with a list of typical 'host:port'

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-03-06 19:49:56 +0100, Tomas Vondra wrote: > On 03/06/2017 07:05 PM, Robert Haas wrote: > > On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote: > > > On 2017-03-06 12:40:18 -0500, Robert Haas wrote: > > > > On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund

Re: [HACKERS] Parallel Index Scans

On 07/03/17 02:46, Amit Kapila wrote: On Mon, Mar 6, 2017 at 6:49 PM, Robert Haas wrote: On Mon, Mar 6, 2017 at 6:33 AM, Amit Kapila wrote: I was going to do it after index and index-only scans and parallel bitmap heap scan were committed, but

Re: [HACKERS] PATCH: two slab-like memory allocators

On 03/06/2017 07:05 PM, Robert Haas wrote: On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote: On 2017-03-06 12:40:18 -0500, Robert Haas wrote: On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote: The issue was that on 32bit platforms the Datum

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

On 3/5/17 05:40, Jan Michálek wrote: > jelen=# \pset linestyle rst > Line style is rst. > jelen=# \pset format wrapped > Output format is wrapped. > jelen=# SELECT repeat('Goodnight Irene ', 30); > +-+ > |

Re: [HACKERS] DROP FUNCTION of multiple functions

On 2/27/17 01:46, Michael Paquier wrote: > On Sat, Feb 25, 2017 at 10:27 PM, Peter Eisentraut > wrote: >> Here is a new patch set that addresses your comments. The structure is >> still the same, just a bunch of things have been renamed based on >> suggestions.

Re: [HACKERS] Statement-level rollback

On Fri, Mar 3, 2017 at 2:15 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut >> On 2/28/17 02:39, Tsunakawa, Takayuki wrote: >> > I'd like to propose

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Sat, Mar 4, 2017 at 10:32 AM, Tom Lane wrote: > Without having actually looked at this patch, I would say that if it added > a direct call of fopen() to backend-side code, that was already the wrong > thing. Almost always, AllocateFile() would be a better choice, not only

Re: [HACKERS] contrib modules and relkind check

On Tue, Feb 14, 2017 at 1:30 AM, Michael Paquier wrote: > Hm... It may be a good idea to be consistent on the whole system and > refer to "partitioned table" as a table without storage and used as an > entry point for partitions. The docs use this term in CREATE TABLE,

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

On Mon, Mar 6, 2017 at 12:53 PM, Stephen Frost wrote: > Regarding 02, I certainly see that as valuable for the reasons which > David outlined in his initial email. I can certainly take point on > getting it committed, but I wouldn't complain if someone else does > either.

Re: [HACKERS] PATCH: two slab-like memory allocators

On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote: > On 2017-03-06 12:40:18 -0500, Robert Haas wrote: >> On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote: >> > The issue was that on 32bit platforms the Datum returned by some >> > functions

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

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Sat, Mar 4, 2017 at 9:12 AM, David Steele wrote: > > Yes, that makes sense. Attached are two patches as requested: > > > > 01 - Just marks pg_stop_backup() variants as parallel restricted > > 02 - Add the

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

On Sat, Mar 4, 2017 at 9:12 AM, David Steele wrote: > Yes, that makes sense. Attached are two patches as requested: > > 01 - Just marks pg_stop_backup() variants as parallel restricted > 02 - Add the wait_for_archive param to pg_stop_backup(). > > These apply cleanly on

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-06 12:40:18 -0500, Robert Haas wrote: > On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote: > > The issue was that on 32bit platforms the Datum returned by some > > functions (int2int4_sum in this case) isn't actually a separately > > allocated Datum, but rather

Re: [HACKERS] PATCH: two slab-like memory allocators

On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote: > The issue was that on 32bit platforms the Datum returned by some > functions (int2int4_sum in this case) isn't actually a separately > allocated Datum, but rather just something embedded in a larger > struct. That,

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan wrote: > On Sat, Mar 4, 2017 at 8:02 AM, Tom Lane wrote: >>> Perhaps there could be a choice of behaviors. Even if we all agreed >>> that parameter notation was better in theory, there's something to be >>> said

Re: [HACKERS] perlcritic

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. >> Especially welcome

Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

David Christensen writes: >> Hi David, >> >> Here's a review of your patch. > > Hi Ilmari, thanks for your time and review. I’m fine with the revised > version. Okay, I've marked the patch as Ready For Committer. Thanks, Ilmari -- "The surreality of the universe tends

[HACKERS] Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

> Hi David, > > Here's a review of your patch. Hi Ilmari, thanks for your time and review. I’m fine with the revised version. Best, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

[HACKERS] [GSoC] Push-based query executor discussion

Hello, I would like to work on push-based executor [1] during GSoC, so I'm writing to introduce myself and start the discussion of the project. I think I should mention beforehand that the subject is my master's thesis topic, and I have already started working on it. This letter is not

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

2017-03-06 16:25 GMT+01:00 Pavel Stehule : > > > 2017-03-06 16:17 GMT+01:00 Jan Michálek : > >> >> >> 2017-03-06 15:19 GMT+01:00 Pavel Stehule : >> >>> >>> >>> 2017-03-06 0:26 GMT+01:00 Jan Michálek

  1   2   >