Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Feb 15, 2017 at 3:11 PM, Masahiko Sawada wrote: > On Mon, Feb 6, 2017 at 10:48 PM, Masahiko Sawada > wrote: >> On Wed, Feb 1, 2017 at 8:25 PM, Robert Haas wrote: >>> On Mon, Jan 30, 2017 at 2:30 AM, Masahiko Sawada

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

Hi, *preliminary* patch attached. This needs a good bit of polishing (primarily comment work, verifying that valgrind works), but I'm too tired now. I'm not quite sure how to deal with mmgr/README - it's written as kind of a historical document, and the "Mechanisms to Allow Multiple Types of

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

On Fri, Feb 24, 2017 at 1:30 AM, Masahiko Sawada wrote: > Hi all, > > The autovacuum reports the number of skipped frozen pages to the > VACUUM output. But these information is not appeared by manual VACUUM. > This information is useful for the user to check efficiency of

[HACKERS] Statement-level rollback

Hello, As I stated here and at the PGConf.ASIA developer meeting last year, I'd like to propose statement-level rollback feature. To repeat myself, this is requested for users to migrate from other DBMSs to PostgreSQL. They expect that a failure of one SQL statement should not abort the

Re: [HACKERS] Keep ECPG comment for log_min_duration_statement

Michael Meskes wrote: > > Michael Meskes wrote: > > > The other option I can see, albeit without looking into details, is > > > allowing all comments and then testing it for the right syntax after > > > parsing. This could potentially also solve the above mentioned > > > option problem. > > > >

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Mon, Feb 27, 2017 at 11:53:17PM -0500, Stephen Frost wrote: > * Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote: > > I suppose it is for suggesting what kind of word should come > > there, or avoiding silence for a tab. Or for symmetry with other > > types of manipulation, like DROP.

Re: [HACKERS] Logical replication existing data copy

On 2017-02-27 15:08, Petr Jelinek wrote: The performance was why in original patch I wanted the apply process to default to synchronous_commit = off as without it the apply performance (due to applying transactions individually and in sequences) is quite lackluster. It can be worked around

Re: [HACKERS] timeouts in PostgresNode::psql

On Mon, Feb 27, 2017 at 11:28 AM, Craig Ringer wrote: > Amended patch attached after a few Perl-related comments I got on > private mail. Out of curiosity, what are they? > Instead of > > $exc_save !~ /^$timeout_exception.*/ > > I've updated to: > > $exc_save !~

Re: [HACKERS] Radix tree for character conversion

On Mon, Feb 27, 2017 at 5:37 PM, Kyotaro HORIGUCHI wrote: > At Wed, 22 Feb 2017 16:06:14 +0900, Michael Paquier > wrote in > >> In order to conduct sanity checks on

Re: [HACKERS] Partitioned tables and relfilenode

Thanks for the review. I was just about to send a new version of the patches. On 2017/02/28 12:20, Robert Haas wrote: > On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote > wrote: >> Thanks for the review. > > In 0001, the documentation which you are patching has a

[HACKERS] WAL Consistency checking for hash indexes

Hello everyone, I've attached a patch which implements WAL consistency checking for hash indexes. This feature is going to be useful for developing and testing of WAL logging for hash index. Note that, this patch should be applied on top of the following WAL logging for hash index patch:

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

Andres Freund writes: > Hm, that should be doable with something like > #if MAXIMUM_ALIGNOF > 4 && SIZEOF_VOID_P == 4 > which'd probably be better documentation than a macro that hides this > (arguing internally whether SIZEOF_VOID_P or SIZEOF_SIZE_T) is better. Not sure

[HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY

Here's another small patch, this time from Simon Riggs. Maybe he already posted it for this commitfest, but I didn't find it in a quick look so here it is. This patch reduces the amount of bloat you get from running CREATE INDEX CONCURRENTLY by destroying the snapshot taken in the first phase,

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

Hi, On 2017-02-27 22:57:24 -0500, Tom Lane wrote: > If the slab allocator would be happier with just a MemoryContext pointer > as chunk header, I think we should push in this direction rather than > invent some short-term hack. It would - it really doesn't need the size, because it's the same

Re: [HACKERS] increasing the default WAL segment size

On Tue, Feb 28, 2017 at 9:45 AM, Jim Nasby wrote: > On 2/24/17 6:30 AM, Kuntal Ghosh wrote: > >> * You're considering any WAL file with a power of 2 as valid. Suppose, >> the correct WAL seg size is 64mb. For some reason, the server >> generated a 16mb invalid WAL

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/28 13:52, Ashutosh Bapat wrote: > Amit's original patch had an assertion failure in > extract_autovac_opts(). His patch adds partitioned tables in the list > of tables to be auto-analyzed. But there's an assertion in > extract_autovac_opts(), which did not consider partitioned tables. >

[HACKERS] BRIN de-summarize ranges

Here's a small patch to make a BRIN page range unsummarized. This is useful if data has been deleted, and the heap pages are now used for completely different data. -- Álvaro Herrera diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c index b22563b..fd7c323 100644 ---

[HACKERS] Re: new high availability feature for the system with both asynchronous and synchronous replication

Hi all, I create POC patch for my proposal of new feature for high availability. I want to discuss about this feature. But this feature might be PG11 because discussion is not enough. This patch enables walsender for async to wait until walsender for sync confirm WAL is flashed to Disk.

Re: [HACKERS] help to identify the reason that extension's C function returns array get segmentation fault

=?UTF-8?B?6ZKx5paw5p6X?= writes: > I have written an extension to manage openstreetmap data. There is a C > function to perform spatial top k query on several tables and return an > array of int8 type as result. The code skeleton of this function is as > follows: There are

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote: > I suppose it is for suggesting what kind of word should come > there, or avoiding silence for a tab. Or for symmetry with other > types of manipulation, like DROP. Another possibility is creating > multiple objects with similar names,

Re: [HACKERS] Partitioned tables and relfilenode

Amit's original patch had an assertion failure in extract_autovac_opts(). His patch adds partitioned tables in the list of tables to be auto-analyzed. But there's an assertion in extract_autovac_opts(), which did not consider partitioned tables. When a partitioned table is created, the assertion

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Feb 6, 2017 at 3:34 PM, Ashutosh Bapat wrote: > PartitionScheme is shared across multiple relations, join or base, > partitioned similarly. Obviously it can't and does not need to point > partition bound informations (which should all be same) of all those

Re: [HACKERS] increasing the default WAL segment size

On Tue, Feb 28, 2017 at 9:45 AM, Jim Nasby wrote: > On 2/24/17 6:30 AM, Kuntal Ghosh wrote: >> >> * You're considering any WAL file with a power of 2 as valid. Suppose, >> the correct WAL seg size is 64mb. For some reason, the server >> generated a 16mb invalid WAL

Re: [HACKERS] Restricting maximum keep segments by repslots

On Tue, Feb 28, 2017 at 1:16 PM, Kyotaro HORIGUCHI wrote: > It is doable without a plugin and currently we are planning to do > in the way (Maybe such plugin would be unacceptable..). Killing > walsender (which one?), removing the slot and if failed.. The PID and

[HACKERS] help to identify the reason that extension's C function returns array get segmentation fault

I have written an extension to manage openstreetmap data. There is a C function to perform spatial top k query on several tables and return an array of int8 type as result. The code skeleton of this function is as follows: Datum vquery(PG_FUNCTION_ARGS) { int array_len = PG_GETARG_INT32(0);

Re: [HACKERS] Restricting maximum keep segments by repslots

On 28/02/17 04:27, Kyotaro HORIGUCHI wrote: > Hello. > > Although replication slot is helpful to avoid unwanted WAL > deletion, on the other hand it can cause a disastrous situation > by keeping WAL segments without a limit. Removing the causal > repslot will save this situation but it is not

Re: [HACKERS] Radix tree for character conversion

Hello, At Tue, 28 Feb 2017 08:00:22 +0530, Robert Haas wrote in > On Mon, Feb 27, 2017 at 2:07 PM, Kyotaro HORIGUCHI > wrote: > >> +# make_charmap - convert charset

Re: [HACKERS] Wrong variable type in KeepLogSeg

At Tue, 28 Feb 2017 12:17:07 +0900, Michael Paquier wrote in > On Tue, Feb 28, 2017 at 11:17 AM, Kyotaro HORIGUCHI > wrote: > > slotSegNo should be a XLogSegNo. Both

Re: [HACKERS] Restricting maximum keep segments by repslots

Thank you for the opinion. At Tue, 28 Feb 2017 12:42:32 +0900, Michael Paquier wrote in

Re: [HACKERS] increasing the default WAL segment size

On 2/24/17 6:30 AM, Kuntal Ghosh wrote: * You're considering any WAL file with a power of 2 as valid. Suppose, the correct WAL seg size is 64mb. For some reason, the server generated a 16mb invalid WAL file(maybe it crashed while creating the WAL file). Your code seems to treat this as a valid

[HACKERS] Disallowing multiple queries per PQexec()

This assignment is on todo list and has a benefit of providing an additional defense against SQL-injection attacks. Previous mailing list discussion is here and I attach a small patch that fix the issue by checking whether query

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/28 12:29, Michael Paquier wrote: > On Tue, Feb 28, 2017 at 12:23 PM, Bruce Momjian wrote: >> I am a little confused by the above. Is a partitioned table the parent >> or the children? Reading the code it seems it is the parent, which >> explains why it works. Can I

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

Andres Freund writes: > Independently of this, we really should redefine StandardChunkHeader to > be only the MemoryContext. There's no need to have size/requested_size > part of StandardChunkHeader, given there's > MemoryContextMethods->get_chunk_space(). Yeah, perhaps.

Re: [HACKERS] logical replication access control patches

On 28/02/17 04:10, Stephen Frost wrote: > Peter, > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 2/18/17 18:06, Stephen Frost wrote: >>> I'm not convinced that it really makes sense to have PUBLICATION of a >>> table be independent from the rights an owner of a table has.

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

On 2017-02-28 01:44:42 +0100, Tomas Vondra wrote: > On 02/27/2017 06:42 PM, Andres Freund wrote: > > Yea, I hadn't yet realized when writing that that termite actually, > > despite running on ppc64, compiles a 32bit postgres. Will thus > > duplicate StandardChunkHeader's contents in to slab.c :( -

Re: [HACKERS] Restricting maximum keep segments by repslots

On Tue, Feb 28, 2017 at 12:27 PM, Kyotaro HORIGUCHI wrote: > Although replication slot is helpful to avoid unwanted WAL > deletion, on the other hand it can cause a disastrous situation > by keeping WAL segments without a limit. Removing the causal > repslot will

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Feb 28, 2017 at 12:23 PM, Bruce Momjian wrote: > I am a little confused by the above. Is a partitioned table the parent > or the children? Reading the code it seems it is the parent, which > explains why it works. Can I clarify that? As I understand things, a

[HACKERS] Restricting maximum keep segments by repslots

Hello. Although replication slot is helpful to avoid unwanted WAL deletion, on the other hand it can cause a disastrous situation by keeping WAL segments without a limit. Removing the causal repslot will save this situation but it is not doable if the standby is active. We should do a rather

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Feb 28, 2017 at 11:53:16AM +0900, Amit Langote wrote: > > I don't think we are doing this, but if the parent table doesn't have a > > physical file pg_upgrade will need to be taught that. We have that case > > now for unlogged tables on standby servers that we need to address. > >

Re: [HACKERS] Partitioned tables and relfilenode

On Thu, Feb 23, 2017 at 11:19 AM, Amit Langote wrote: > Thanks for the review. In 0001, the documentation which you are patching has a section for limitations that apply only to both partitioning and constraint exclusion, and another for limitations that apply only

Re: [HACKERS] Wrong variable type in KeepLogSeg

On Tue, Feb 28, 2017 at 11:17 AM, Kyotaro HORIGUCHI wrote: > slotSegNo should be a XLogSegNo. Both types share the same > intrinsic type so it doesn't harm anything. Nice catch! -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] logical replication access control patches

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/18/17 18:06, Stephen Frost wrote: > > I'm not convinced that it really makes sense to have PUBLICATION of a > > table be independent from the rights an owner of a table has. We don't > > allow other ALTER commands on

Re: [HACKERS] rename pg_log directory?

On Mon, Feb 27, 2017 at 09:51:26AM -0500, Tom Lane wrote: > Peter Eisentraut writes: > > How about changing the default for log_directory from 'pg_log' to, say, > > 'log'? > > > We have been emphasizing that the prefix "pg_" is for things reserved to > >

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/02/28 3:54, Bruce Momjian wrote: > On Fri, Feb 10, 2017 at 03:19:47PM +0900, Amit Langote wrote: >> The new partitioned tables do not contain any data by themselves. Any >> data inserted into a partitioned table is routed to and stored in one of >> its partitions. In fact, it is

Re: [HACKERS] bytea_output output of base64

On Mon, Feb 27, 2017 at 09:28:10PM +0530, Robert Haas wrote: > I don't think Bruce was seriously proposing a change in this area > anyway. I think he was just asking a question. That is correct. I was asking if we made an obvious mistake, and most people are saying no. Also, base64 is less

[HACKERS] Unhelpful typesetting of callouts in example queries in the docs

Hi A novice user asked me about the last example here, which kept producing errors: https://www.postgresql.org/docs/9.6/static/tutorial-agg.html? It turned out that the 'callout' was causing confusion because it sticks "(1)" into the middle of the query in approximately the same typeface:

[HACKERS] Final commitfest for 10.0 almost underway

Submissions for patches to be included in PostgresSQL 10.0 will be accepted until 2017-03-01 00:00 AoE (UTC-12). Get 'em in while you can! -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Radix tree for character conversion

On Mon, Feb 27, 2017 at 2:07 PM, Kyotaro HORIGUCHI wrote: >> +# make_charmap - convert charset table to charmap hash >> +# with checking duplicate source code >> Maybe this should be "with checking of duplicated source codes". > > Even though I'm not good

[HACKERS] Wrong variable type in KeepLogSeg

Hello, I found a variable definition with wrong type specification in KeepLogSeg, which doesn't harm anything. > static void > KeepLogSeg(XLogRecPtr recptr, XLogSegNo *logSegNo) > { > ... > /* then check whether slots limit removal further */ > if (max_replication_slots > 0 && keep !=

Re: [HACKERS] utility commands benefiting from parallel plan

On Sat, Feb 25, 2017 at 3:21 AM, Robert Haas wrote: > On Fri, Feb 24, 2017 at 11:43 AM, Haribabu Kommi > wrote: > > Here I attached an implementation patch that allows > > utility statements that have queries underneath such as > > CREATE TABLE

Re: [HACKERS] pg_upgrade loses security lables and COMMENTs on blobs

On Thu, Feb 23, 2017 at 10:36:37AM -0500, Stephen Frost wrote: > All, > > * Stephen Frost (sfr...@snowman.net) wrote: > > Just wanted to get a note out to -hackers about the issue, I'll see > > about getting a fix written up for it soon. > > Attached is a patch which addresses this issue. I'm

Re: [HACKERS] utility commands benefiting from parallel plan

On Sat, Feb 25, 2017 at 2:45 AM, Dilip Kumar wrote: > On Fri, Feb 24, 2017 at 11:43 AM, Haribabu Kommi > wrote: > > Here I attached an implementation patch that allows > > utility statements that have queries underneath such as > > CREATE TABLE

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-27 17:00:23 -0800, Joshua D. Drake wrote: > On 02/22/2017 02:45 PM, Tom Lane wrote: > > Andres Freund writes: > > > On 2017-02-22 08:43:28 -0500, Tom Lane wrote: > > > > (To be concrete, I'm suggesting dropping --disable-integer-datetimes > > > > in HEAD, and just

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 02/22/2017 02:45 PM, Tom Lane wrote: Andres Freund writes: On 2017-02-22 08:43:28 -0500, Tom Lane wrote: (To be concrete, I'm suggesting dropping --disable-integer-datetimes in HEAD, and just agreeing that in the back branches, use of replication protocol with

Re: [HACKERS] Replication vs. float timestamps is a disaster

On Mon, Feb 20, 2017 at 09:07:33AM -0500, Tom Lane wrote: > The question to be asked is whether there is still anybody out there > using float timestamps. I'm starting to get dubious about it myself. > Certainly, no packager that I'm aware of has shipped a float-timestamp > build since we

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

On 2/27/17 7:50 PM, Michael Paquier wrote: > On Tue, Feb 28, 2017 at 9:42 AM, David Steele wrote: >> On 2/27/17 7:38 PM, Michael Paquier wrote: >>> On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote: I also marked the pg_stop_* functions as

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

On Tue, Feb 28, 2017 at 9:42 AM, David Steele wrote: > On 2/27/17 7:38 PM, Michael Paquier wrote: >> On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote: >>> I also marked the pg_stop_* functions as parallel restricted, the same >>> as pg_start_backup().

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

On 02/27/2017 06:42 PM, Andres Freund wrote: On 2017-02-27 12:27:48 -0500, Tom Lane wrote: Andres Freund writes: The best theory I have so far that I have is that slab.c's idea of StandardChunkHeader's size doesn't match what mcxt.c think it is (because slab.c simply

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

On 2/27/17 7:38 PM, Michael Paquier wrote: > On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote: >> I also marked the pg_stop_* functions as parallel restricted, the same >> as pg_start_backup(). Previously they were parallel safe which I don't >> believe is accurate for

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

On Tue, Feb 28, 2017 at 9:25 AM, David Steele wrote: > I also marked the pg_stop_* functions as parallel restricted, the same > as pg_start_backup(). Previously they were parallel safe which I don't > believe is accurate for the non-exclusive version at the very least, >

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On 2/27/17 7:27 PM, Michael Paquier wrote: > On Tue, Feb 28, 2017 at 9:21 AM, David Steele wrote: >> Looks like it's me, then. I don't seem to have admin privileges to >> close the commitfest or I don't know where the option is located. >> >> Can somebody grant privileges or

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Tue, Feb 28, 2017 at 9:21 AM, David Steele wrote: > Looks like it's me, then. I don't seem to have admin privileges to > close the commitfest or I don't know where the option is located. > > Can somebody grant privileges or close the CF at 3/1 12AM AoE (UTC-12) > for me?

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

on 2017-02-24 04:41:09 Simon Riggs wrote: > ...you didn't comment at all on the accuracy and usefulness of the > gathered statistics, when the sample is biased towards non-updated > data. In my understanding, the sample for statistics is not biased at least in our use case because the conversion

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

Currently pg_stop_backup() will wait for all WAL to be archived before returning. If there is a problem with the archive command or a large backlog it may not return for a very long time (if ever). Backup software is faced with the choice of cancelling the query and hoping the stop backup record

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On 2/27/17 6:40 PM, Michael Paquier wrote: > On Tue, Feb 28, 2017 at 2:43 AM, Andres Freund wrote: >> On 2017-02-27 23:09:40 +0530, Robert Haas wrote: >>> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: I'm happy to be CFM. Somehow I doubt

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Tue, Feb 28, 2017 at 2:43 AM, Andres Freund wrote: > On 2017-02-27 23:09:40 +0530, Robert Haas wrote: >> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: >> > I'm happy to be CFM. Somehow I doubt there will be a lot of objections! >> >> No.

Re: [HACKERS] GSoC 2017

On Tue, Feb 28, 2017 at 11:42 AM, Alexander Korotkov wrote: > Hi all! > > It seems that PostgreSQL has passed to GSoC mentoring organizations this > year! > https://summerofcode.withgoogle.com/organizations/4558465230962688/ > Congratulations! Very cool! By the way,

Re: [HACKERS] Polyphase merge is obsolete

On Mon, Jan 16, 2017 at 5:56 PM, Peter Geoghegan wrote: > On Wed, Oct 12, 2016 at 10:16 AM, Heikki Linnakangas wrote: >> The number of *input* tapes we can use in each merge pass is still limited, >> by the memory needed for the tape buffers and the merge heap,

Re: [HACKERS] GSoC 2017

Hi all! It seems that PostgreSQL has passed to GSoC mentoring organizations this year! https://summerofcode.withgoogle.com/organizations/4558465230962688/ Congratulations! -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Mon, Feb 27, 2017 at 05:31:21PM -0500, Tom Lane wrote: > Michael Paquier writes: > > I don't object to the addition of this patch in next CF as this > > presents no new concept. Still per the complications this patch and > > because it is a complicated patch I was

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Michael Paquier writes: > I don't object to the addition of this patch in next CF as this > presents no new concept. Still per the complications this patch and > because it is a complicated patch I was wondering if people are fine > to include it in this last CF. The

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Tue, Feb 28, 2017 at 5:29 AM, Bruce Momjian wrote: > On Fri, Feb 17, 2017 at 11:05:31PM +0900, Michael Paquier wrote: >> On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson wrote: >> > Thinking about this makes me wonder about why you decided to use a >> >

Re: [HACKERS] removing tsearch2

​There is also a mechanism for the results of the Perl module's "make test" to be reported to a site which aggregates and reports them by Perl version and OS - a sort of distributed build farm. See for example http://matrix.cpantesters.org/?dist=DBD-Pg+3.5.3

Re: [HACKERS] removing tsearch2

On Feb 27, 2017, at 1:53 PM, Bruce Momjian wrote: > Oh, does CPAN distribute compiled modules or requires users to compile > them. Like PGXN, it formally does not care, but its implementation expects source code distributions what will be built and installed by users. Note

Re: [HACKERS] removing tsearch2

On Mon, Feb 27, 2017 at 01:00:20PM -0800, David E. Wheeler wrote: > On Feb 27, 2017, at 12:04 PM, Bruce Momjian wrote: > > > Just stating the obvious, but one of the reasons CPAN works so well is > > that most of the modules are written in Perl and hence don't need > >

Re: [HACKERS] btree_gin and btree_gist for enums

Andrew Dunstan writes: > OK, here's the whole series of patches. I've not tested it at all, but this looks generally sane in a quick once-over. A minor quibble is that in 0003, you weren't terribly consistent about argument order --- in some places you have the

Re: [HACKERS] Documentation improvements for partitioning

On 27/02/17 07:59, Amit Langote wrote: > On 2017/02/27 3:18, Petr Jelinek wrote: >> On 24/02/17 07:15, Robert Haas wrote: >>> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote: The good news is that logical replication DOES work with partitioning, but only for a

Re: [HACKERS] btree_gin and btree_gist for enums

On 02/26/2017 04:09 PM, Andrew Dunstan wrote: > > On 02/26/2017 03:26 PM, Tom Lane wrote: >> Andrew Dunstan writes: >>> This works for the btree_gin case. However, there's a difficulty for >>> btree_gist - in the puicksplit routine the cmp function is passed to

Re: [HACKERS] removing tsearch2

On Feb 27, 2017, at 12:04 PM, Bruce Momjian wrote: > Just stating the obvious, but one of the reasons CPAN works so well is > that most of the modules are written in Perl and hence don't need > per-platform compilation. There are a *lot* of C-baded modules on CPAN; and my

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Thu, Feb 23, 2017 at 3:08 AM, Thom Brown wrote: > On 23 January 2017 at 11:56, Ivan Kartyshov > wrote: >> >> Thank you for reading, will be glad to get your feedback. > > Could you please rebase your patch as it no longer applies cleanly. +1 --

Re: [HACKERS] I propose killing PL/Tcl's "modules" infrastructure

Andrew Dunstan writes: > On 02/26/2017 02:54 PM, Tom Lane wrote: >> * I'm not terribly comfortable about what the permissions levels of the >> GUCs ought to be. > plperl's on_plperl_init and on_plperlu_init settings are both SUSET. > In practice with PLv8 this is

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Fri, Feb 17, 2017 at 11:05:31PM +0900, Michael Paquier wrote: > On Fri, Feb 17, 2017 at 10:43 PM, Andreas Karlsson wrote: > > Thinking about this makes me wonder about why you decided to use a > > transaction per index in many of the steps rather than a transaction per > >

Re: [HACKERS] removing tsearch2

On Fri, Feb 17, 2017 at 09:54:37AM +0100, Magnus Hagander wrote: > If we could somehow integrate PGXN with both the RPM build process, the DEB > build process and a Windows build process (whether driven by PGXN or just "fed > enough data" by PGXN is a different question), I think that would go a

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Feb 10, 2017 at 03:19:47PM +0900, Amit Langote wrote: > The new partitioned tables do not contain any data by themselves. Any > data inserted into a partitioned table is routed to and stored in one of > its partitions. In fact, it is impossible to insert *any* data before a > partition

Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter

+Vladimir On 27 February 2017 at 11:36, Andres Freund wrote: > On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote: > > On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund > wrote: > > > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote: > > > > I bumped

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Sun, Feb 26, 2017 at 12:32 PM, Magnus Hagander wrote: > > On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck > wrote: > >> Hi, >> >> Am Dienstag, den 14.02.2017, 18:18 -0500 schrieb Robert Haas: >> > On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera

Re: [HACKERS] Poor memory context performance in large hash joins

On 02/27/2017 12:55 PM, Andres Freund wrote: On 2017-02-24 15:18:04 -0800, Andres Freund wrote: On 2017-02-24 15:12:37 -0800, Andres Freund wrote: On 2017-02-24 18:04:18 -0500, Tom Lane wrote: Concretely, something like the attached. This passes regression tests but I've not pushed on it any

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-27 19:20:56 +0100, Tomas Vondra wrote: > On 02/27/2017 12:55 PM, Andres Freund wrote: > > On 2017-02-24 15:18:04 -0800, Andres Freund wrote: > > > On 2017-02-24 15:12:37 -0800, Andres Freund wrote: > > > > On 2017-02-24 18:04:18 -0500, Tom Lane wrote: > > > > > Concretely, something

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

On 02/27/2017 04:07 PM, Andres Freund wrote: On February 27, 2017 6:14:20 AM PST, Tomas Vondra wrote: On 02/27/2017 01:02 PM, Andres Freund wrote: Hi, On 2017-02-27 03:17:32 -0800, Andres Freund wrote: I'll work on getting slab committed first, and then

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On 26 February 2017 at 20:55, Magnus Hagander wrote: > What do others think? Changing the output behaviour of a command isn't something we usually do as a backpatch. This change doesn't affect the default behaviour so probably wouldn't make a difference to the outcome of

Re: [HACKERS] GUC for cleanup indexes threshold.

On Sat, Feb 25, 2017 at 10:51 PM, Robert Haas wrote: > The thing that strikes me based on what you wrote is that our page > recycling seems to admit of long delays even as things stand. There's > no bound on how much time could pass between one index vacuum and the > next,

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

On 02/27/2017 06:40 PM, Andres Freund wrote: On 2017-02-27 18:04:41 +0100, Petr Jelinek wrote: On 27/02/17 18:00, Andres Freund wrote: FWIW I think the ppc64 machines are failing because of unrelated issue (changes to integer timestamps). We should probably look at 32bit machines first.

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On 2/27/17 12:40 PM, Robert Haas wrote: > On Mon, Feb 27, 2017 at 11:09 PM, Robert Haas wrote: >> On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: >>> I'm happy to be CFM. Somehow I doubt there will be a lot of objections! >> >> No. Aren't you

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On 2017-02-27 23:09:40 +0530, Robert Haas wrote: > On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: > > I'm happy to be CFM. Somehow I doubt there will be a lot of objections! > > No. Aren't you the guy who did a good job with it last year and just > about perished in

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

On 2017-02-27 12:27:48 -0500, Tom Lane wrote: > Andres Freund writes: > > The best theory I have so far that I have is that slab.c's idea of > > StandardChunkHeader's size doesn't match what mcxt.c think it is > > (because slab.c simply embeds StandardChunkHeader, but mcxt

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

Andres Freund writes: > The best theory I have so far that I have is that slab.c's idea of > StandardChunkHeader's size doesn't match what mcxt.c think it is > (because slab.c simply embeds StandardChunkHeader, but mcxt uses > MAXALIGN(sizeof(StandardChunkHeader))). That's

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

On 2017-02-27 18:04:41 +0100, Petr Jelinek wrote: > On 27/02/17 18:00, Andres Freund wrote: > > > >> FWIW I think the ppc64 machines are failing because of unrelated issue > >> (changes to integer timestamps). We should probably look at 32bit machines > >> first. > > > > Don't think so - termite

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Mon, Feb 27, 2017 at 11:09 PM, Robert Haas wrote: > On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: >> I'm happy to be CFM. Somehow I doubt there will be a lot of objections! > > No. Aren't you the guy who did a good job with it last year and

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: > I'm happy to be CFM. Somehow I doubt there will be a lot of objections! No. Aren't you the guy who did a good job with it last year and just about perished in the process? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Feb 16, 2017 at 8:16 PM, Amit Kapila wrote: > Attached are refactoring patches. WAL patch needs some changes based > on above comments, so will post it later. After some study, I have committed 0001, and also committed 0002 and 0003 as a single commit, with only

  1   2   >