Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Dec 28, 2016 at 9:20 AM, Etsuro Fujita wrote: > On 2016/12/27 22:03, Ashutosh Bapat wrote: >> >> If mergejoin_allowed is true and mergeclauselist is non-NIL but >> hashclauselist is NIL (that's rare but there can be types has merge >> operators but not hash

Re: [HACKERS] Parallel Index-only scan

On Wed, Dec 28, 2016 at 12:18 PM, Rafia Sabih wrote: > Rebased patch of parallel-index only scan based on the latest version of > parallel index scan [1] is attached. > > [1] >

Re: [HACKERS] Parallel Index-only scan

Rebased patch of parallel-index only scan based on the latest version of parallel index scan [1] is attached. [1] https://www.postgresql.org/message-id/CAA4eK1LiNi7_Z1% 2BPCV4y06o_v%3DZdZ1UThE%2BW9JhthX4B8uifnA%40mail.gmail.com On Sat, Dec 24, 2016 at 7:55 PM, Rafia Sabih

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

>> >> We allow creating user attribute with name "oid" so you do not want to >> search system attribute oid by name. Instead search by attribute id >> ObjectIdAttributeNumber. > > Good point. Although, there can only be one of the two in a table at any > given time - either the "oid" system

[HACKERS] parallelize queries containing subplans

Currently, queries that have references to SubPlans or AlternativeSubPlans are considered parallel-restricted. I think we can lift this restriction in many cases especially when SubPlans are parallel-safe. To make this work, we need to propagate the parallel-safety information from path node to

Re: [HACKERS] Hooks

On Wed, Dec 28, 2016 at 2:14 PM, David Fetter wrote: > Here's everything that matches ^\w+_hook$ that I've found so far in > git master. There are very likely false positives in this list. > > [... long list of hooks ...] > > Some appear to be client-side, some server-side. I

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Wed, Dec 28, 2016 at 3:12 AM, Magnus Hagander wrote: > On Tue, Dec 27, 2016 at 1:16 PM, Michael Paquier > wrote: >> On Tue, Dec 27, 2016 at 6:34 PM, Magnus Hagander >> wrote: >> > On Tue, Dec 27, 2016 at 2:23 AM, Michael

Re: [HACKERS] Hooks

On Tue, Dec 27, 2016 at 10:15:55PM -0600, Jim Nasby wrote: > On 12/27/16 7:41 PM, David Fetter wrote: > > I see it as larger in scope than mine because it changes how we do > > things as a project. An example of the kind of thing that this raises > > is enforcement. Will something (or someone)

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

> > I'm looking forward to seeing your patch. > I created a patch. I marked [WIP] to the title because some documentation is lacked and format needs some fixing. I'm going to post this patch to the January CF. But it's my first time to send a patch so please excuse me if there's something

Re: [HACKERS] Faster methods for getting SPI results

On 12/27/16 9:10 PM, Craig Ringer wrote: On 28 December 2016 at 09:58, Jim Nasby wrote: I've looked at this some more, and ITSM that the only way to do this without some major surgery is to create a new type of Destination specifically for SPI that allows for the

Re: [HACKERS] Some thoughts about multi-server sync rep configurations

On Wed, Dec 28, 2016 at 4:21 PM, Craig Ringer wrote: > On 28 December 2016 at 08:14, Thomas Munro > wrote: > >> 3. No server must allow a transaction to be visible that hasn't been >> flushed on N standby servers. We already prevent that on

Re: [HACKERS] Hooks

On 28 December 2016 at 12:15, Jim Nasby wrote: > Can we reduce the scope of this to a manageable starting point? I'm guessing > that all existing hooks share certain characteristics that it'd be pretty > easy to detect. If you can detect the hook (which I guess means

Re: [HACKERS] Hooks

On 12/27/16 7:41 PM, David Fetter wrote: I see it as larger in scope than mine because it changes how we do things as a project. An example of the kind of thing that this raises is enforcement. Will something (or someone) check that new hooks have this? Will somebody check for comment skew

Re: [HACKERS] merging some features from plpgsql2 project

On 12/27/16 4:56 PM, Merlin Moncure wrote: On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule wrote: First I describe my initial position. I am strongly against introduction "new" language - plpgsql2 or new plpgsql, or any else. The trust of developers to us is important

Re: [HACKERS] postgres_fdw bug in 9.6

On 2016/12/27 22:03, Ashutosh Bapat wrote: If mergejoin_allowed is true and mergeclauselist is non-NIL but hashclauselist is NIL (that's rare but there can be types has merge operators but not hash operators), we will end up returning NULL. I think we want to create a merge join in that case. I

Re: [HACKERS] proposal: session server side variables

Fabien, I don't really see the point of "persistent variables". What benefit do they add over relations? You can add a simple function to fetch a tuple if you want it not to look like a subquery. Do it with heap access in C if you like, save the (trivial) planning costs. I do see value to two

[HACKERS] Add doc advice about systemd RemoveIPC

Here is a patch to add some information about the systemd RemoveIPC issue to the documentation, sort of in the spirit of the OOM discussion nearby. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From

Re: [HACKERS] Some thoughts about multi-server sync rep configurations

On 28 December 2016 at 08:14, Thomas Munro wrote: > 3. No server must allow a transaction to be visible that hasn't been > flushed on N standby servers. We already prevent that on the primary Only if the primary doesn't restart. We don't persist the xact masking

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

On 28 December 2016 at 08:33, Tom Lane wrote: >> I would not say that the current patch is giant & invasive, if you >> abstract the two added fields to high-level statements. > > It's touching every single utility statement type, which is not only > pretty invasive in itself,

Re: [HACKERS] Faster methods for getting SPI results

On 28 December 2016 at 09:58, Jim Nasby wrote: > I've looked at this some more, and ITSM that the only way to do this without > some major surgery is to create a new type of Destination specifically for > SPI that allows for the execution of an arbitrary C function for

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro wrote: > But I'm starting to think that the best way might be to do BOTH of the > things I said in my previous message: make dsa.c register on > create/attach and also unregister before detaching iff the name was >

Re: [HACKERS] Faster methods for getting SPI results

On 12/21/16 8:21 AM, Jim Nasby wrote: On 12/20/16 10:14 PM, Jim Nasby wrote: It would be a lot more efficient if we could just grab datums from the executor and make a single copy into plpython (or R), letting the PL deal with all the memory management overhead. I briefly looked at using SPI

Re: [HACKERS] Hooks

On Wed, Dec 28, 2016 at 01:33:13AM +, Tsunakawa, Takayuki wrote: > From: David Fetter [mailto:da...@fetter.org] > > > How about putting a descriptive comment at the location where each > > > hook variable is defined, using some convention (e.g. like > > > Javadoc-style)? A separate document

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/27 19:07, Amit Langote wrote: > Attached should fix that. Here are the last two patches with additional information like other patches. Forgot to do that yesterday. Thanks, Amit >From 5a82b4caa6cec7845eb48e0397fab49c74b8dd98 Mon Sep 17 00:00:00 2001 From: amit

Re: [HACKERS] Hooks

From: David Fetter [mailto:da...@fetter.org] > > How about putting a descriptive comment at the location where each > > hook variable is defined, using some convention (e.g. like > > Javadoc-style)? A separate document such as README and wiki can fail > > to be updated. OTOH, if someone wants to

Re: [HACKERS] Hooks

On Wed, Dec 28, 2016 at 12:47:10AM +, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jim Nasby > > AFAIK there's no way to get a list of hooks today, short of > > something like `git grep hook`. I think a

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

On 2016/12/27 22:24, Ashutosh Bapat wrote: > On Mon, Dec 26, 2016 at 3:36 PM, Amit Langote > wrote: >> Attached patches modifies MergeAttributesIntoExisting() such that we >> increment attinhcount not only for user attributes, but also for the oid >> system column

Re: [HACKERS] Hooks

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jim Nasby > AFAIK there's no way to get a list of hooks today, short of something like > `git grep hook`. I think a simple list of what hooks we have, when they > fire and where to find them in code

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Fabien COELHO writes: >>> How? The issue is that stmtmulti silently skip some ';' when empty >>> statements are found, [...] >> Maybe you should undo that. > I was trying to be minimally invasive in the parser, i.e. not to change > any rules. That's fairly silly when the

Re: [HACKERS] proposal: session server side variables

On Tue, Dec 27, 2016 at 6:55 PM, Pavel Stehule wrote: > > > 2016-12-27 21:38 GMT+01:00 Fabrízio de Royes Mello < fabriziome...@gmail.com>: >> >> >> On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway wrote: >> > >> > >> In the long term, What would be the

Re: [HACKERS] PATCH: recursive json_populate_record()

> I've noticed that this patch is on CF and needs a reviewer so I decided > to take a look. Code looks good to me in general, it's well covered by > tests and passes `make check-world`. Thanks for your review. > However it would be nice to have a little more comments. In my opinion > every

[HACKERS] Some thoughts about multi-server sync rep configurations

Hi, Sync rep with multiple standbys allows queries run on standbys to see transactions that haven't been flushed on the configured number of standbys. That means that it's susceptible to lost updates or a kind of "dirty read" in certain cluster reconfiguration scenarios. To close that gap, we

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-27 23:56 GMT+01:00 Merlin Moncure : > On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule > wrote: > > Hi > > > > I reread ideas described on page https://github.com/trustly/plpgsql2 > > > > Some points are well and can be benefit for PlpgSQL. > >

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Andreas Seltenreich writes: > Thomas Munro writes: > >> It is safe, as long as the segment remains mapped. Each backend that >> attaches calls LWLockRegisterTranche giving it the address of the name >> in its virtual address space. > > Hmok, I was under the impression only backends participating

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Thomas Munro writes: > On Wed, Dec 28, 2016 at 11:38 AM, Andreas Seltenreich > wrote: >> Thomas Munro writes: >> >>> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro >>> wrote: On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 12/23/2016 03:58 AM, Amit Kapila wrote: On Thu, Dec 22, 2016 at 6:59 PM, Tomas Vondra wrote: Hi, But as discussed with Amit in Tokyo at pgconf.asia, I got access to a Power8e machine (IBM 8247-22L to be precise). It's a much smaller machine compared to the x86

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

On Wed, Dec 28, 2016 at 11:38 AM, Andreas Seltenreich wrote: > Thomas Munro writes: > >> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro >> wrote: >>> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich >>> wrote:

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule wrote: > Hi > > I reread ideas described on page https://github.com/trustly/plpgsql2 > > Some points are well and can be benefit for PlpgSQL. > > First I describe my initial position. I am strongly against introduction >

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Thomas Munro writes: > On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro > wrote: >> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich >> wrote: >>> testing master as of fe591f8bf6 produced a crash reading >>> pg_stat_activity (backtrace

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro wrote: > On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich > wrote: >> testing master as of fe591f8bf6 produced a crash reading >> pg_stat_activity (backtrace below). Digging around with with

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Hello Tom, How? The issue is that stmtmulti silently skip some ';' when empty statements are found, [...] Maybe you should undo that. I was trying to be minimally invasive in the parser, i.e. not to change any rules. I've generally found that trying to put optimizations into the grammar

Re: [HACKERS] Hooks

On 12/27/16 1:43 PM, David Fetter wrote: So I'm a bit suspicious of this project in the first place, but it's hard to discuss which hooks should be documented when you haven't defined what you mean by documentation. I haven't quite come up with that, but I'd pictured a part of the SGML docs

Re: [HACKERS] pg_stat_activity.waiting_start

On 12/27/16 11:17 AM, Greg Stark wrote: On Dec 24, 2016 5:44 PM, "Tom Lane" > wrote: I think we'd need at least an order of magnitude cheaper to consider putting timing calls into spinlock or lwlock paths, and that's just not

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich wrote: > testing master as of fe591f8bf6 produced a crash reading > pg_stat_activity (backtrace below). Digging around with with gdb > revealed that pgstat_get_wait_event() returned an invalid pointer for a > classId

[HACKERS] [sqlsmith] Crash reading pg_stat_activity

Hi, testing master as of fe591f8bf6 produced a crash reading pg_stat_activity (backtrace below). Digging around with with gdb revealed that pgstat_get_wait_event() returned an invalid pointer for a classId PG_WAIT_LWLOCK. I think the culprit is dsa.c passing a pointer to memory that goes away

Re: [HACKERS] proposal: session server side variables

2016-12-27 21:38 GMT+01:00 Fabrízio de Royes Mello : > > On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway wrote: > > > > >> In the long term, What would be the possible scopes? > > >> > > >> TRANSACTION, SESSION, PERSISTANT ? > > >> > > >> Would some

Re: [HACKERS] proposal: session server side variables

On Fri, Dec 23, 2016 at 4:00 PM, Joe Conway wrote: > > >> In the long term, What would be the possible scopes? > >> > >> TRANSACTION, SESSION, PERSISTANT ? > >> > >> Would some scopes orthogonal (eg SHARED between sessions for a USER in a > >> DATABASE, SHARED at the cluster

Re: [HACKERS] Hooks

On Tue, Dec 27, 2016 at 01:32:46PM -0500, Tom Lane wrote: > David Fetter writes: > > One of our hidden treasures is the hook system, documented only in > > random presentations, if you can find them, and in the source code, if > > you know to look. > > > I'd like to document

Re: [HACKERS] [patch] psql tab completion for ALTER DEFAULT PRIVILEGES

Gilles, all, * Stephen Frost (sfr...@snowman.net) wrote: > * Gilles Darold (gilles.dar...@dalibo.com) wrote: > > Added to next commitfest. To explain more this patch, the completion of > > SQL command: > > > > ALTER DEFAULT PRIVILEGES FOR ROLE xxx [tab] > > Here is a cleaned up patch for

Re: [HACKERS] Hooks

David Fetter writes: > One of our hidden treasures is the hook system, documented only in > random presentations, if you can find them, and in the source code, if > you know to look. > I'd like to document the hooks that we consider public APIs. The main reason we send people

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Fabien COELHO writes: > How? The issue is that stmtmulti silently skip some ';' when empty > statements are found, so I need to keep track of that to know where to > stop, using the beginning location of the next statement, which is > probably your idea, does not work.

[HACKERS] Hooks

Folks, One of our hidden treasures is the hook system, documented only in random presentations, if you can find them, and in the source code, if you know to look. I'd like to document the hooks that we consider public APIs. To do this, I need to figure out whether there are hooks that we don't

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Tue, Dec 27, 2016 at 1:16 PM, Michael Paquier wrote: > On Tue, Dec 27, 2016 at 6:34 PM, Magnus Hagander > wrote: > > On Tue, Dec 27, 2016 at 2:23 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> Magnus, you have mentioned me

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

An additional comment on parser(planner?) part. This patch make planner() copy the location and length from parse to result, but copying such stuffs is a job of standard_planner. I put the copy in planner because standard_planner may not be called by planner, and in all cases I think

Re: [HACKERS] pg_stat_activity.waiting_start

On Dec 24, 2016 5:44 PM, "Tom Lane" wrote: I think we'd need at least an order of magnitude cheaper to consider putting timing calls into spinlock or lwlock paths, and that's just not available at all, let alone portably. For spinlocks we could conceivably just bite the

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Hello Kyotaro-san, In nonterminal stmtmulti, setQueryLocation is added and used to calcualte and store the length of every stmt's. This needs an extra storage in bse_yy_extra_type The extra storage is one int. and introduces a bit complicated stuff. But I think raw_parser can do that

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova wrote: > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x006941e7 in lazy_vacuum_heap (onerel=0x1ec2360, > vacrelstats=0x1ef6e00) at vacuumlazy.c:1417 > 1417tblk = >

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Tue, Dec 27, 2016 at 10:54 AM, Alvaro Herrera wrote: > Anastasia Lubennikova wrote: > >> I ran configure using following set of flags: >> ./configure --enable-tap-tests --enable-cassert --enable-debug >> --enable-depend CFLAGS="-O0 -g3 -fno-omit-frame-pointer" >> And

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Andres Freund writes: > On 2016-12-27 01:35:05 +, Greg Stark wrote: >> On Dec 26, 2016 10:35 PM, "Tom Lane" wrote: >>> So it seems like the configure support we'd need is to detect >>> whether clock_gettime is available (note on Linux there's also >>>

Re: [HACKERS] Parallel Index Scans

On Fri, Dec 23, 2016 at 5:48 PM, Rahila Syed wrote: >>> 5. Comment for _bt_parallel_seize() says: >>> "False indicates that we have reached the end of scan for >>> current scankeys and for that we return block number as P_NONE." >>> >>> What is the reason to check (blkno

Re: [HACKERS] Parallel Index Scans

On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova wrote: > 22.12.2016 07:19, Amit Kapila: >> >> On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova >> wrote: >>> >>> The following review has been posted through the commitfest

Re: [HACKERS] Reporting planning time with EXPLAIN

Ashutosh, * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > We report planning and execution time when EXPLAIN ANALYZE is issued. > We do not have facility to report planning time as part EXPLAIN > output. In order to get the planning time, one has to issue EXPLAIN > ANALYZE which

Re: [HACKERS] pg_stat_activity.waiting_start

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > In practice, there should never be waits on LWLocks (much less spinlocks) > that exceed order-of-milliseconds; if there are, either we chose the wrong > lock type or the system is pretty broken in general. So maybe it's > sufficient if we provide a

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Anastasia Lubennikova wrote: > I ran configure using following set of flags: > ./configure --enable-tap-tests --enable-cassert --enable-debug > --enable-depend CFLAGS="-O0 -g3 -fno-omit-frame-pointer" > And then ran make check. Here is the stacktrace: > > Program terminated with signal SIGSEGV,

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

23.12.2016 22:54, Claudio Freire: On Fri, Dec 23, 2016 at 1:39 PM, Anastasia Lubennikova wrote: I found the reason. I configure postgres with CFLAGS="-O0" and it causes Segfault on initdb. It works fine and passes tests with default configure flags, but I'm

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

On Mon, Dec 26, 2016 at 3:36 PM, Amit Langote wrote: > I suspect the following is a bug: > > create table foo (a int) with oids; > CREATE TABLE > create table bar (a int); > CREATE TABLE > alter table bar inherit foo; > ERROR: table "bar" without OIDs cannot

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

On Mon, Dec 26, 2016 at 11:49 AM, Jaime Casanova < jaime.casan...@2ndquadrant.com> wrote: > On 2 December 2016 at 07:36, Pavan Deolasee > wrote: > > > > I've updated the patches after fixing the issue. Multiple rounds of > > regression passes for me without any issue.

Re: [HACKERS] PATCH: recursive json_populate_record()

Hello. I've noticed that this patch is on CF and needs a reviewer so I decided to take a look. Code looks good to me in general, it's well covered by tests and passes `make check-world`. However it would be nice to have a little more comments. In my opinion every procedure have to have at least

Re: [HACKERS] postgres_fdw bug in 9.6

> >> 3. Talking about saving some CPU cycles - if a clauseless full join can be >> implemented only using merge join, probably that's the only path available >> in >> the list of paths for the given relation. Instead of building the same >> path >> anew, should we use the existing path like

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/12/08 21:08, Etsuro Fujita wrote: On 2016/12/07 20:23, Etsuro Fujita wrote: My proposal here would be a bit different from what you proposed; right before deparseSelectSql in deparseSelectStmtForRel, build the tlists for relations present in the given jointree that will be deparsed as

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Tue, Dec 27, 2016 at 6:34 PM, Magnus Hagander wrote: > On Tue, Dec 27, 2016 at 2:23 AM, Michael Paquier > wrote: >> Magnus, you have mentioned me as well that you had a couple of ideas >> on the matter, feel free to jump in and let's mix our

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

On 2016-12-27 14:09:05 +0900, Michael Paquier wrote: > On Fri, Dec 23, 2016 at 3:02 AM, Andres Freund wrote: > > Not quite IIRC: that doesn't deal with file size increase. All this would > > be easier if hardlinks wouldn't exist IIUC. It's basically a question > > whether

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/27 18:48, 高增琦 wrote: > Hi , > > I tried "COPY FROM" in the git version. It inserts rows to wrong partition. > > step to reproduce: > create table t(a int, b int) partition by range(a); > create table t_p1 partition of t for values from (1) to (100); > create table t_p2 partition of t

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/27 18:30, Rajkumar Raghuwanshi wrote: > Hi Amit, > > I have pulled latest sources from git and tried to create multi-level > partition, getting a server crash, below are steps to reproduce. please > check if it is reproducible in your machine also. > [ ... ] > postgres=# INSERT

Re: [HACKERS] Declarative partitioning - another take

Hi , I tried "COPY FROM" in the git version. It inserts rows to wrong partition. step to reproduce: create table t(a int, b int) partition by range(a); create table t_p1 partition of t for values from (1) to (100); create table t_p2 partition of t for values from (100) to (200); create table

Re: [HACKERS] [PATCH] Generic type subscription

> On 27 December 2016 at 16:09, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > until it breaks existing extensions. Hm...I already answered, that I managed to avoid compilation problems for this particular extension using the `genparser` command again: > On Thu, Nov 17, 2016 at 10:56

Re: [HACKERS] comments tablecmds.c

On Tue, Dec 27, 2016 at 10:36 AM, Erik Rijkers wrote: > On 2016-12-27 10:25, Magnus Hagander wrote: > >> On Sun, Dec 25, 2016 at 2:35 PM, Erik Rijkers wrote: >> >> Applied, thanks. >> >> Seems to me that in comments it's not worth chasing them down >>

Re: [HACKERS] comments tablecmds.c

On 2016-12-27 10:25, Magnus Hagander wrote: On Sun, Dec 25, 2016 at 2:35 PM, Erik Rijkers wrote: Applied, thanks. Seems to me that in comments it's not worth chasing them down individually, but if you happen to fix one alongside another one like here, then it's a different

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Tue, Dec 27, 2016 at 2:23 AM, Michael Paquier wrote: > Hi all, > > Since 56c7d8d4, pg_basebackup supports tar format when streaming WAL > records. This has been done by introducing a new transparent routine > layer to control the method used to fetch WAL

Re: [HACKERS] Declarative partitioning - another take

Hi Amit, I have pulled latest sources from git and tried to create multi-level partition, getting a server crash, below are steps to reproduce. please check if it is reproducible in your machine also. postgres=# CREATE TABLE test_ml (a int, b int, c varchar) PARTITION BY RANGE(a); CREATE TABLE

Re: [HACKERS] comments tablecmds.c

On Sun, Dec 25, 2016 at 2:35 PM, Erik Rijkers wrote: > On 2016-12-25 13:38, Erik Rijkers wrote: > >> 'the the' -> 'the' >> >> and >> >> 'ie' -> 'i.e.' >> >> Although (concening the latter change) the present counts are 'ie' >> 428, and 'i.e.' 428. >> so it might be debatable (but

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On 2016-12-27 01:35:05 +, Greg Stark wrote: > On Dec 26, 2016 10:35 PM, "Tom Lane" wrote: > > > So it seems like the configure support we'd need is to detect > whether clock_gettime is available (note on Linux there's also > a library requirement, -lrt), and we would

Re: [HACKERS] [PATCH] Generic type subscription

As I mentioned above [1] in my humble opinion this patch is not at all in a "good shape" until it breaks existing extensions. [1] http://postgr.es/m/20161115080324.GA5351%40e733.localdomain On Mon, Dec 26, 2016 at 10:49:30PM +0700, Dmitry Dolgov wrote: > > On 5 December 2016 at 12:03, Haribabu

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

On Sat, Dec 24, 2016 at 1:18 AM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > With your WARM and my indirect indexes, plus the additions for for-key > > locks, plus identity columns, there is no longer a real expectation that > > we can exit early from the

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/26 19:46, Amit Langote wrote: > (Perhaps, the following should be its own new thread) > > I noticed that ExecProcessReturning() doesn't work properly after tuple > routing (example shows how returning tableoid currently fails but I > mention some other issues below): > > create table

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

At Fri, 23 Dec 2016 11:02:11 +0900, Michael Paquier wrote in > On Fri, Dec 23, 2016 at 8:13 AM, Robert Haas wrote: > > On Thu, Dec 22, 2016 at 2:34 PM, Andres Freund

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Dec 27, 2016 at 1:36 PM, Mithun Cy wrote: Oops, patch number should be 08 re-attaching same after renaming. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com diff --git a/src/backend/access/hash/hashinsert.c

Re: [HACKERS] Cache Hash Index meta page.

On Thu, Dec 22, 2016 at 12:17 PM, Amit Kapila wrote: > On Wed, Dec 21, 2016 at 9:26 PM, Robert Haas wrote: >> On Tue, Dec 20, 2016 at 2:25 PM, Mithun Cy >> wrote: >>> -- I think if it is okay, I can document same for

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-27 8:54 GMT+01:00 Pavel Stehule : > Hi > > I reread ideas described on page https://github.com/trustly/plpgsql2 > > Some points are well and can be benefit for PlpgSQL. > > First I describe my initial position. I am strongly against introduction > "new" language -