Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 03/11/2016 11:35 PM, Tom Lane wrote: Robert Haas writes: On Fri, Mar 11, 2016 at 1:11 PM, David Steele wrote: Is anyone willing to volunteer a review or make an argument for the importance of this patch? There's been a lot of discussion on

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 5:01 AM, Jim Nasby wrote: > > On 3/10/16 8:36 PM, Robert Haas wrote: >> >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

On 03/12/2016 12:49 AM, Tom Lane wrote: Anybody know what will happen when passing a uint64 to newSViv()? On 64 bit platforms, it is just interpreted as a signed integer, any number with the upper bit set will become negative. Perl provides newSVuv for unsigned numbers. On 32bit platforms

[HACKERS] [PATCH] Use MemoryContextAlloc() in the MemoryContextAllocZero() and MemoryContextAllocZeroAligned()

Hello all, Attached patch simplifies the MemoryContextAllocZero() and MemoryContextAllocZeroAligned(). The MemoryContextAllocZero() and MemoryContextAllocZeroAligned() functions does almost the same that MemoryContextAlloc() does. Additionally these functions fills allocated memory context with

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Fri, Mar 11, 2016 at 3:34 PM, Mithun Cy wrote: > > On Thu, Mar 10, 2016 at 9:39 PM, Robert Haas wrote: > >I guess there must not be an occurrence of this pattern in the > >regression tests, or previous force_parallel_mode testing would have >

Re: [HACKERS] raw output from copy

Hi 2016-03-09 18:41 GMT+01:00 Corey Huinker : > >>> The regression tests seem to adequately cover all new functionality, >>> though I wonder if we should add some cases that highlight situations where >>> BINARY mode is insufficient. >>> >>> > One thing I tried to test

Re: [HACKERS] Relation extension scalability

On Sat, Mar 12, 2016 at 8:37 AM, Amit Kapila wrote: > Can you post the numbers for 1, 5, 10, 15, 25 or whatever other multiplier > you have tried, so that it is clear that 20 is best? I had Tried with 1, 10, 20 and 50. 1. With base code it was almost the same as base

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 6:31 AM, Jim Nasby wrote: > On 3/10/16 8:36 PM, Robert Haas wrote: >> >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

On 12/03/16 04:30, Tom Lane wrote: 1. I found two places (marked XXX in this patch) that are using strtoul() to parse a tuple count back out of a command tag. That won't do anymore. pg_stat_statements has a messy hack for the same problem (look for HAVE_STRTOULL), which is probably what we

Re: [HACKERS] Relation extension scalability

On 12/03/16 01:01, Jim Nasby wrote: On 3/11/16 5:14 PM, Petr Jelinek wrote: I don't really understand this part about concurrent DDL. If there were concurrent DDL going on, presumably other backends would be blocked on the relation lock, not the relation extension lock - and it doesn't seem

Re: [HACKERS] Relation extension scalability

On 12/03/16 03:46, Dilip Kumar wrote: On Sat, Mar 12, 2016 at 5:31 AM, Jim Nasby > wrote: FWIW, this is definitely a real possibility in any shop that has very high downtime costs and high transaction rates. I also think

Re: [HACKERS] Parallel Aggregate

On 11 March 2016 at 03:39, David Rowley wrote: > A couple of things which I'm not 100% happy with. > > 1. make_partialgroup_input_target() doing lookups to the syscache. > Perhaps this job can be offloaded to a new function in a more suitable > location. Ideally the

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

I wrote: > I'll take it from here, unless I find bigger issues. Hmm ... so the more I pulled on this string, the more stuff I found. The attached updated patch fixes several additional significant areas: * call_cntr and max_calls in FuncCallContext are now uint64 * Result widths for

[HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

Hi, On 2016-01-28 19:09:01 +, Robert Haas wrote: > Only try to push down foreign joins if the user mapping OIDs match. > > Previously, the foreign join pushdown infrastructure left the question > of security entirely up to individual FDWs, but it would be easy for > a foreign data wrapper to

Re: [HACKERS] Relation extension scalability

On Sat, Mar 12, 2016 at 8:16 AM, Dilip Kumar wrote: > > > On Sat, Mar 12, 2016 at 5:31 AM, Jim Nasby wrote: >> >> FWIW, this is definitely a real possibility in any shop that has very high downtime costs and high transaction rates. >> >> I also

Re: [HACKERS] Proposal: BSD Authentication support

On 3/11/16 4:38 PM, Thomas Munro wrote: > It looks like this needs review from an OpenBSD user specifically. > FreeBSD and NetBSD use PAM instead of BSD auth. FreeBSD has man pages for this stuff, so maybe they also have it now. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Proposal: BSD Authentication support

On 1/7/16 9:40 PM, Marisa Emerson wrote: > There's a port for PAM, but we would prefer to use BSD Auth as its quite > a lot cleaner and is standard on OpenBSD. > > I've attached an updated patch that includes documentation. It has been > tested against OpenBSD 5.8. I'll add this thread to the

Re: [HACKERS] Relation extension scalability

On Sat, Mar 12, 2016 at 5:31 AM, Jim Nasby wrote: > FWIW, this is definitely a real possibility in any shop that has very high > downtime costs and high transaction rates. > > I also think some kind of clamp is a good idea. It's not that uncommon to > run

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

On Fri, 2016-03-11 at 16:40 -0800, Peter Geoghegan wrote: > On Fri, Mar 11, 2016 at 4:17 PM, Peter Geoghegan > wrote: > > > > If you want the tool to limp on when it finds an error, that can be > > done by changing the constant for the CORRUPTION macro in > > amcheck.c. > > But

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

On 03/11/2016 06:49 PM, Tom Lane wrote: Anybody know what will happen when passing a uint64 to newSViv()? A perl IV is guaranteed large enough to hold a pointer, if that's any help. But for an unsigned value you might be better off calling newSVuv() cheers

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

On Fri, Mar 11, 2016 at 4:30 PM, Jim Nasby wrote: > Right, but you still have the option to enable them if you don't want to > swamp your IO system. That's why CIC obeys it too. If I was running a > consistency check on a production system I'd certainly want the option

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

On Fri, Mar 11, 2016 at 4:17 PM, Peter Geoghegan wrote: > If you want the tool to limp on when it finds an error, that can be > done by changing the constant for the CORRUPTION macro in amcheck.c. > But having that be dynamically configurable is not really compatible > with the

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

On 3/10/16 3:29 PM, Regina Obe wrote: Take for example, I have tiger geocoder which relies on fuzzystrmatch. I have no idea where someone installs fuzzystrmatch so I can't schema qualify those calls. I use that dependent function to use to build an index on tables. This is something I've

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

On 3/11/16 6:17 PM, Peter Geoghegan wrote: Not sure about the cost delay thing. Delays are disabled by default for manually issued VACUUM, so have doubts that that's useful. Right, but you still have the option to enable them if you don't want to swamp your IO system. That's why CIC obeys it

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

On Fri, Mar 11, 2016 at 3:50 PM, Jim Nasby wrote: > I also agree that the nmodule name isn't very clear. If this is meant to be > the start of a generic consistency checker, lets call it that. Otherwise, it > should be marked as being specific to btrees, because

Re: [HACKERS] 2016-03 Commitfest

We're are now one third of the way through the 2016-03 Commitfest. There are still some patches left that need review but have no reviewer (https://commitfest.postgresql.org/9/?reviewer=-2) though a lot have been picked up in the last week. Needs review: 56 Needs *reviewer*: 15 (was 58 last

Re: [HACKERS] Relation extension scalability

On 3/11/16 5:14 PM, Petr Jelinek wrote: I don't really understand this part about concurrent DDL. If there were concurrent DDL going on, presumably other backends would be blocked on the relation lock, not the relation extension lock - and it doesn't seem likely that you'd often have a huge

Re: [HACKERS] PREPARE dynamic SQL in plpgsql

On Fri, Mar 11, 2016 at 4:45 PM, Koichi Suzuki wrote: > Hi, > > Does someone know how to prepare a synamic SQL statement in plpgsql? > > All the examples, PG documents describe only about preparing static SQL > statement. > > This is not an appropriate question for the

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

I wrote: > Anybody know what will happen when passing a uint64 to newSViv()? Oh, and how about Python's PyInt_FromLong()? Or PyList_New()? Or the second argument of PyList_SetItem()? regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PREPARE dynamic SQL in plpgsql

On Fri, Mar 11, 2016 at 4:45 PM, Koichi Suzuki wrote: > Hi, > > Does someone know how to prepare a synamic SQL statement in plpgsql? > > All the examples, PG documents describe only about preparing static SQL > statement. > > You might want to rephrase the question. From

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

On 3/11/16 3:31 PM, Peter Geoghegan wrote: Can we come up with names that more clearly identify the difference >between those two functions? I mean,_parent_ does not make it >particularly obvious that the second function acquires exclusive lock >and performs more thorough checks. Dunno about

[HACKERS] Perl's newSViv() versus 64-bit ints?

Anybody know what will happen when passing a uint64 to newSViv()? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Background Processes and reporting

On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: > Idea of individual time measurement of every wait event met criticism > because it might have high overhead [1]. Right. And that's actually one of the point which I meant with "didn't listen to criticism". There've been a lot of examples,

[HACKERS] PREPARE dynamic SQL in plpgsql

Hi, Does someone know how to prepare a synamic SQL statement in plpgsql? All the examples, PG documents describe only about preparing static SQL statement. Thank you; -- Koichi Suzuki

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On 3/10/16 8:36 PM, Robert Haas wrote: 1. We make it true only for heavyweight lock waits, and false for other kinds of waits. That's pretty strange. 2. We make it true for all kinds of waits that we now know how to report. That still breaks compatibility. I would absolutely vote for 2 here.

Re: [HACKERS] WIP: Upper planner pathification

On 2016-03-10 23:38:14 -0500, Tom Lane wrote: > > Would you rather add back the exports or should I? > > I'll do it ... just send me the list. After exporting make_agg, make_limit, make_sort_from_sortclauses and making some trivial adjustments due to the pull_var_clause changes change, Citus'

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 12:22 AM, Andres Freund wrote: > On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: > > It was many times stated in threads about waits monitoring [0, 1, 2] > > and supported by different people, but ultimately waits information > > was stored in

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

"Andreas 'ads' Scherbaum" writes: > On 09.02.2016 20:32, Christian Ullrich wrote: >> To fix this, I think it will be enough to change the format strings to >> use "%zu" instead of "%lu". > Attached is a new version of the patch, with %lu replaced by %zu. Nonono ... that

Re: [HACKERS] Relation extension scalability

On 11/03/16 22:29, Robert Haas wrote: On Thu, Mar 10, 2016 at 8:54 PM, Petr Jelinek wrote: I am not talking about extension locks, the lock queue can be long because there is concurrent DDL for example and then once DDL finishes suddenly 100 connections that tried to

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

On Fri, Mar 11, 2016 at 8:19 AM, Anastasia Lubennikova wrote: > I do hope that my patch will be accepted in 9.6, so this conflict looks > really bad. I hope so too. I'll have to look into this issue. > I think that error is caused by changes in pages layout. To

Re: [HACKERS] Performance improvement for joins where outer side is unique

I wrote: > I wondered why, instead of inventing an extra semantics-modifying flag, > we couldn't just change the jointype to *be* JOIN_SEMI when we've > discovered that the inner side is unique. BTW, to clarify: I'm not imagining that we'd make this change in the query jointree, as for example

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 23:22 GMT+01:00 Joel Jacobson : > On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule > wrote: > >> What we need is more input on proposed changes from other companies > >> who are also heavy users of PL/pgSQL. > >> > >> Only then can we move

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule wrote: >> What we need is more input on proposed changes from other companies >> who are also heavy users of PL/pgSQL. >> >> Only then can we move forward. It's like Robert is saying, there is a >> risk for bikeshedding here,

Re: [HACKERS] Background Processes and reporting

On 2016-03-12 01:05:43 +0300, Vladimir Borodin wrote: > > 12 марта 2016 г., в 0:22, Andres Freund написал(а): > > Only that it isn't. It's stored in PGPROC. > > Sorry, I missed that. So monitoring of wait events for auxiliary processes > still could be implemented? It's

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:48 GMT+01:00 Joel Jacobson : > On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule > wrote: > > I afraid so you try to look on your use case as global/generic issue. The > > PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 0:22, Andres Freund написал(а): > > On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: >> It was many times stated in threads about waits monitoring [0, 1, 2] >> and supported by different people, but ultimately waits information >> was stored in

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 4:48 AM, Joel Jacobson wrote: > neither you nor me have nothing to add. Correction: neither you nor me have anything to add. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule wrote: > I afraid so you try to look on your use case as global/generic issue. The > PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does the > languages dirty. In this point we have different opinion. > > I

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

On Fri, Mar 11, 2016 at 1:31 PM, Peter Geoghegan wrote: > You could have a race, where > there was a concurrent page deletion of the left sibling of the child > page, then a concurrent insertion into the newly expanded keyspace of > the parent. Therefore, the downlink in the

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:32 GMT+01:00 Joel Jacobson : > On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas > wrote: > > > > I don't think my experience in this area is as deep as you seem to > > think. I can tell you that most of the requests EnterpriseDB gets for > >

Re: [HACKERS] Background Processes and reporting

Hi, On 2016-03-11 11:16:32 -0800, Andres Freund wrote: > It seems rather worthwhile to think about how we can expand the coverage > of progress tracking to other types of background processes. WRT the progress reporting patch, I think we should split (as afaics was discussed in the thread for a

Re: [HACKERS] Proposal: BSD Authentication support

On Sat, Mar 12, 2016 at 5:14 AM, David Steele wrote: > On 1/14/16 11:22 PM, Robert Haas wrote: >> On Tue, Jan 12, 2016 at 2:27 AM, Marisa Emerson wrote: >>> I've attached the latest version of this patch. I've fixed up an issue with >>> the configuration

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:08 GMT+01:00 Robert Haas : > On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote: > > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas > wrote: > >> I'm not direly opposed to most of what's on that page, > >> but I'm

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas wrote: > > I don't think my experience in this area is as deep as you seem to > think. I can tell you that most of the requests EnterpriseDB gets for > PL/pgsql enhancements involve wanting it to be more like Oracle's > PL/SQL,

Re: [HACKERS] Performance improvement for joins where outer side is unique

So I started re-reading this thread in preparation for looking at the patch, and this bit in your initial message jumped out at me: > In all of our join algorithms in the executor, if the join type is SEMI, > we skip to the next outer row once we find a matching inner row. This is > because we

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

On Thu, Mar 10, 2016 at 9:18 AM, Tomas Vondra wrote: > I've looked at this patch today, mostly to educate myself, so this > probably should not count as a full review. Anyway, the patch seems in > excellent shape - it'd be great if all patches (including those

Re: [HACKERS] Relation extension scalability

On Thu, Mar 10, 2016 at 8:54 PM, Petr Jelinek wrote: > I am not talking about extension locks, the lock queue can be long because > there is concurrent DDL for example and then once DDL finishes suddenly 100 > connections that tried to insert into table will try to get

Re: [HACKERS] Background Processes and reporting

On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: > It was many times stated in threads about waits monitoring [0, 1, 2] > and supported by different people, but ultimately waits information > was stored in PgBackendStatus. Only that it isn't. It's stored in PGPROC. This criticism is true of

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

On Fri, Mar 11, 2016 at 1:09 PM, Peter Geoghegan wrote: > Or, you could add code like this to comparetup_index_btree(), to > simulate a broken opclass: > > diff --git a/src/backend/utils/sort/tuplesort.c > b/src/backend/utils/sort/tuplesort.c > index 67d86ed..23712ff 100644 > ---

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

On Fri, Mar 11, 2016 at 8:24 AM, Michael Paquier wrote: > You can use for example dd in non-truncate mode to corrupt on-disk > page data, say that for example: > dd if=/dev/random bs=8192 count=1 \ > seek=$BLOCK_ID of=base/$DBOID/$RELFILENODE \ > conv=notrunc

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote: > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote: >> I'm not direly opposed to most of what's on that page, >> but I'm not excited about most of it, either. > > May I ask, what improvements of

Re: [HACKERS] Background Processes and reporting

> 11 марта 2016 г., в 22:16, Andres Freund написал(а): > > Hi, > > We now have "Provide much better wait information in pg_stat_activity" > and "Add a generic command progress reporting facility" making it easier > to provide insight into the system. > > > While working

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote: > I'm not direly opposed to most of what's on that page, > but I'm not excited about most of it, either. May I ask, what improvements of PL/pgSQL would you personally be most excited about, if you or someone else would

Re: [HACKERS] eXtensible Transaction Manager API (v2)

Robert Haas writes: > On Fri, Mar 11, 2016 at 1:11 PM, David Steele wrote: >> Is anyone willing to volunteer a review or make an argument for the >> importance of this patch? > There's been a lot of discussion on another thread about this patch. > The

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On 3/11/16, Tom Lane wrote: > [ catches up with thread... ] > > Yes. It would be more reasonable IMO for to_date to throw an error > because this is bad input. On the other hand, to_date mostly doesn't > throw an error no matter how bad the input is. I think that may have >

[HACKERS] Saving SRF context

Hi, I have implemented a SRF[*] that returns rows one by one (using ExprMultipleResult). But now I need to save somewhere some context information between calls pertaining to the same result set and I am unable to find a proper place for that. I have seen that cfinfo->flinfo->fn_extra is

Re: [HACKERS] Change error code for hstore syntax error

Sherrylyn Branchaw writes: > The hstore module uses elog() to default to ERRCODE_INTERNAL_ERROR > (SQLSTATE XX000) when the error message reads "Syntax error near '%c' at > position %d". Yeah, that is entirely bogus. No user-facing error report should ever return

[HACKERS] Change error code for hstore syntax error

The hstore module uses elog() to default to ERRCODE_INTERNAL_ERROR (SQLSTATE XX000) when the error message reads "Syntax error near '%c' at position %d". I propose to switch to ereport() to return ERRCODE_SYNTAX_ERROR (SQLSTATE 42601), on the grounds that it's more transparent. It took me longer

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

Robert Haas writes: > On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy > wrote: >>> However, I'm not sure we ought to tinker with the behavior in this >>> area. If -MM-DD is going to accept things that are not of the >>> format -MM-DD, and

[HACKERS] Background Processes and reporting

Hi, We now have "Provide much better wait information in pg_stat_activity" and "Add a generic command progress reporting facility" making it easier to provide insight into the system. While working on the writeback control / checkpoint sorting patch I'd the following statement in BufferSync()'s

Re: [HACKERS] insufficient qualification of some objects in dump files

Hi Peter, On 2/26/16 1:30 AM, Tom Lane wrote: > Michael Paquier writes: >> On Fri, Feb 26, 2016 at 9:47 AM, Peter Eisentraut wrote: >>> Tom thought this might require an archive version dump, but I'm not >>> sure. The tags are more of an

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 3/11/16 2:00 PM, Oleg Bartunov wrote: > On Fri, Mar 11, 2016 at 7:11 PM, David Steele I'm concerned about the lack of response or reviewers for this patch. > It may be because everyone believes they had their say on the original > thread, or because it seems

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Fri, Mar 11, 2016 at 7:11 PM, David Steele wrote: > On 2/10/16 12:50 PM, Konstantin Knizhnik wrote: > > > PostgresProffesional cluster teams wants to propose new version of > > eXtensible Transaction Manager API. > > Previous discussion concerning this patch can be found

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Hi Filip, On 2/20/16 8:00 AM, Filip Rembiałkowski wrote: > On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob On 2/9/16, Tom Lane > > wrote: > > FWIW, I think it would be a good thing if the NOTIFY statement syntax

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 3/11/16 1:30 PM, Robert Haas wrote: > There's been a lot of discussion on another thread about this patch. > The subject is "The plan for FDW-based sharding", but the thread kind > of got partially hijacked by this issue. The net-net of that is that > I don't think we have a clear enough idea

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Fri, Mar 11, 2016 at 1:11 PM, David Steele wrote: > On 2/10/16 12:50 PM, Konstantin Knizhnik wrote: >> PostgresProffesional cluster teams wants to propose new version of >> eXtensible Transaction Manager API. >> Previous discussion concerning this patch can be found here:

Re: [HACKERS] remove wal_level archive

On 2/8/16 2:34 PM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> On 1/26/16 10:56 AM, Simon Riggs wrote: >>> Removing one of "archive" or "hot standby" will just cause confusion and >>> breakage, so neither is a good choice for removal. >>> >>> What we should do is >>> 1. Map "archive" and

Re: [HACKERS] WIP: Access method extendability

On Wed, Mar 9, 2016 at 8:31 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Hi! > > On Wed, Mar 9, 2016 at 3:27 PM, Alvaro Herrera > wrote: > >> Hi. As I just said to Tomas Vondra: since your patch creates a new >> object type, please make sure to add a

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 3/11/16 1:11 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: >>> It looks like a decision needs to be made here whether to apply this patch, >>> send it back to the author, or reject it so I'm

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

Robert Haas writes: > On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: >> It looks like a decision needs to be made here whether to apply this patch, >> send it back to the author, or reject it so I'm marking it "Ready for >> Committer". >> >>

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 2/10/16 12:50 PM, Konstantin Knizhnik wrote: > PostgresProffesional cluster teams wants to propose new version of > eXtensible Transaction Manager API. > Previous discussion concerning this patch can be found here: > >

Re: [HACKERS] Freeze avoidance of very large table.

On 03/11/2016 09:48 AM, Masahiko Sawada wrote: Thank you so much! What I wanted deal with in thread is almost done. I'm going to more test the feature for 9.6 releasing. Nicely done! Regards, -- Masahiko Sawada -- Command Prompt, Inc. http://the.postgres.company/

Re: [HACKERS] GinPageIs* don't actually return a boolean

Andres Freund wrote: I plan to commit something like this, unless there's very loud protest from Peter's side. I agree. Peter proposal can be considered in a separate thread. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent

Re: [HACKERS] Freeze avoidance of very large table.

On Sat, Mar 12, 2016 at 2:37 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 10:47 PM, Masahiko Sawada > wrote: >>> Thanks. I adopted some of your suggested, rejected others, fixed a >>> few minor things that I missed previously, and committed

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Mar 10, 2016 at 10:47 PM, Masahiko Sawada wrote: >> Thanks. I adopted some of your suggested, rejected others, fixed a >> few minor things that I missed previously, and committed this. If you >> think any of the changes that I rejected still have merit, please >>

Re: [HACKERS] Combining Aggregates

On 1/20/16 11:42 PM, David Rowley wrote: > On 21 January 2016 at 08:06, Robert Haas > wrote: > > On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > > > wrote: > >

Re: [HACKERS] Tsvector editing functions

I saw errors on windows, here is the fix: Thank you, pushed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On 3/11/16, Robert Haas wrote: > On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy > wrote: >>> However, I'm not sure we ought to tinker with the behavior in this >>> area. If -MM-DD is going to accept things that are not of the >>> format

Re: [HACKERS] Tsvector editing functions

> > On 11 Mar 2016, at 16:13, Stas Kelvich wrote: > > >> On 10 Mar 2016, at 20:29, Teodor Sigaev wrote: >> >> I would like to suggest rename both functions to array_to_tsvector and >> tsvector_to_array to have consistent name. Later we could add

Re: [HACKERS] auto_explain sample rate

On Fri, Mar 11, 2016 at 11:33 AM, Tomas Vondra wrote: > A bit late, but I think we should rename the GUC variable to > "sampling_rate" (instead of sample_ratio) as that's what pgbench uses > for the same thing. That'd be more consistent. I like that idea. It seems

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: > It looks like a decision needs to be made here whether to apply this patch, > send it back to the author, or reject it so I'm marking it "Ready for > Committer". > > Robert, since you were participating in this

Re: [HACKERS] Proposal: RETURNING primary_key()

On 3/11/2016 12:40 AM, Craig Ringer wrote: That's why (sorry, Igal) I'd like to see some more tests for cases other than identity columns. How is GENERATED ALWAYS handled, if supported? What about if it's on a UNIQUE column? How about a PRIMARY KEY whose value is assigned by a DEFAULT or by

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

Hi, On Fri, 2016-03-11 at 17:24 +0100, Michael Paquier wrote: > On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote: > > > > BTW, if you know a good way to corrupt index (and do it > > reproducible) I'd be > > very glad to see it. > You can use for example dd in non-truncate mode to

Re: [HACKERS] Speedup twophase transactions

On 01/26/2016 07:43 AM, Stas Kelvich wrote: Thanks for reviews and commit! As Simon and Andres already mentioned in this thread replay of twophase transaction is significantly slower then the same operations in normal mode. Major reason is that each state file is fsynced during replay and

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 1/21/16 9:53 AM, Shulgin, Oleksandr wrote: > On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas > wrote: > > > So it's true that the client can't unilaterally terminate COPY BOTH > mode; it can only send CopyDone. But an error on the

Re: [HACKERS] auto_explain sample rate

Hi, On Fri, 2016-03-11 at 15:11 +0100, Magnus Hagander wrote: >  > > > Applied with a minor word-fix in the documentation and removal of > some unrelated whitespace changes.  A bit late, but I think we should rename the GUC variable to "sampling_rate" (instead of sample_ratio) as that's what

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

On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote: > BTW, if you know a good way to corrupt index (and do it reproducible) I'd be > very glad to see it. You can use for example dd in non-truncate mode to corrupt on-disk page data, say that for example: dd if=/dev/random bs=8192 count=1

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

01.03.2016 03:09, Peter Geoghegan: I was assigned an "action point" during the FOSDEM developer meeting: "Post new version of btree consistency checker patch". I attach a new WIP version of my consistency checker tool, amcheck. This patch is proposed for 9.6, as an extension in contrib -- maybe

Re: [HACKERS] Proposal: BSD Authentication support

On 1/14/16 11:22 PM, Robert Haas wrote: > On Tue, Jan 12, 2016 at 2:27 AM, Marisa Emerson wrote: >> I've attached the latest version of this patch. I've fixed up an issue with >> the configuration scripts that I missed. > Looks reasonable on a quick read-through. Can anyone with

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

Le 11/03/2016 15:22, Tom Lane a écrit : > Gilles Darold writes: >> Le 11/03/2016 10:49, Shulgin, Oleksandr a écrit : >>> Would it make sense to have it as a symlink instead? >> The only cons I see is that it can be more "difficult" with some >> language to gather the

  1   2   >