Re: [HACKERS] pg_hba_file_settings view patch

On Thu, Jan 5, 2017 at 1:58 PM, Michael Paquier wrote: > Could you hold on a bit to commit that? I'd like to look at it in more > details. At quick glance, there is for example no need to use > CreateTemplateTupleDesc and list the columns both in pg_proc.h and the > C

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Jan 10, 2017 at 3:46 PM, Amit Kapila wrote: > On Mon, Jan 9, 2017 at 2:18 PM, Masahiko Sawada wrote: >> On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila wrote: >>> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/09 22:36, Ashutosh Bapat wrote: I wrote: Done. Attached is the new version of the patch. Why is this so? * If the outer cheapest-total path is parameterized by the inner * rel, we can't generate a nestloop path. That parameterization means that for

Re: [HACKERS] DROP FUNCTION of multiple functions

On Sun, Jan 1, 2017 at 1:17 AM, Peter Eisentraut wrote: > On 12/1/16 9:32 PM, Peter Eisentraut wrote: >> I think it would be better to get rid of objargs and have objname be a >> general Node that can contain more specific node types so that there is >> some

Re: [HACKERS] Block level parallel vacuum WIP

On Mon, Jan 9, 2017 at 2:18 PM, Masahiko Sawada wrote: > On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila wrote: >> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada >> wrote: >>> On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier

Re: [HACKERS] proposal: session server side variables

Hello Robert, Half-persistence (in definition, not in value) is not a key feature needed by the use-case. Well, you don't get to decide that. I do not think that your reprimand is deserved about this point: I did not decide a subjective opinion, I noted an objective fact. You've been

Re: [HACKERS] parallelize queries containing subplans

On Wed, Dec 28, 2016 at 11:47 AM, Amit Kapila wrote: > Attached patch implements the above idea. This will enable > parallelism for queries containing un-correlated subplans, an example > of which is as follows: I have reviewed the patch (pq_pushdown_subplan_v1.patch),

Re: [HACKERS] Block level parallel vacuum WIP

On Sat, Jan 7, 2017 at 7:18 AM, Claudio Freire wrote: > On Fri, Jan 6, 2017 at 2:38 PM, Masahiko Sawada wrote: >> table_size | indexes | parallel_degree | time >> +-+-+-- >> 6.5GB | 0 |

Re: [HACKERS] Parallel bitmap heap scan

On 01/09/2017 07:22 PM, Dilip Kumar wrote: Thanks, Tushar. I have fixed it. The defect was in 0002. I have also observed another issue related to code refactoring, Actually, there was some code present in 0001 which supposed to be in 0003. Thanks, I have checked at my end and it is fixed now.

Re: [HACKERS] Incorrect XLogRegisterBuffer flag for revmapbuf in brin

On Tue, Jan 10, 2017 at 2:52 AM, Alvaro Herrera wrote: > > Alvaro Herrera wrote: > > > If you examine the revmap in a replica after running the script below, > > you'd observe it's different than the one in the master. I confirmed > > that the proposed patch fixes the

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > My tests are OK too but I see an issue with the code in > enlargeStringInfo(), regarding integer overflow. > The bit of comment that says: > > Note we are assuming here that limit <= INT_MAX/2, else the above > loop could overflow. > > is obsolete, it's now INT_MAX

Re: [HACKERS] Declarative partitioning - another take

Is there any reason for the exclusion of parent tables from the pg_tables system catalog view? They do not show up in information_schema.tables as well. I believe I found where to make the changes and I tested to make sure it works for my simple case. Attached is my first attempt at patching

Re: [HACKERS] RustgreSQL

On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer wrote: > Immutable functions can and do use functionality from all over the > server. They just don't depend on user-visible mutable _state_ > elsewhere in the server. OK, fair point, but at least the functionality *could* be

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Tue, Jan 10, 2017 at 1:53 AM, Vladimir Rusinov wrote: > > On Mon, Jan 9, 2017 at 4:14 PM, Peter Eisentraut > wrote: >> >> > pg_is_xlog_replay_paused| pg_is_recovery_paused >> >> All the other xlog_replay names have been changed to

[HACKERS] remove floats from bootstrap scanner/parser

I happened to notice that we have dead code to parse floating point numbers in the boostrap scanner/parser. This seems unused since forever -- or, more precisely, I couldn't find any floats in 8.2's postgres.bki (the oldest I have around). I would just rip it out, per the attached. -- Álvaro

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-10 5:59 GMT+01:00 Peter Eisentraut : > On 1/7/17 6:39 AM, Pavel Stehule wrote: > > ROW_COUNT .. shortcut for GET DIAGNOSTICS row_count = ROW_COUNT. > > I don't see the point. > A check how much rows was impacted by query is relative often task. So we

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 6:39 AM, Pavel Stehule wrote: > ROW_COUNT .. shortcut for GET DIAGNOSTICS row_count = ROW_COUNT. I don't see the point. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-10 2:02 GMT+01:00 Jim Nasby : > On 1/9/17 6:07 PM, Marko Tiikkaja wrote: > >> One use case is NEW and OLD in triggers. Checking to see if one or >> the other is set is easier than checking TG_OP. It's also going to >> be faster (probably MUCH faster;

[HACKERS] pg_restore accepts -j -1

Greetings, For reasons which seem likely to be entirely unintentional, pg_restore will accept a '-1' for -j: pg_restore -j -1 This seems to result in the parallel state being NULL and so things don't outright break, but it hardly seems likely to be what the user was asking for- my guess is that

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby wrote: > On 1/5/17 12:55 PM, Jonathon Nelson wrote: > >> Attached please find a patch for PostgreSQL 9.4 which changes the >> maximum amount of data that the wal sender will send at any point in >> time from the hard-coded value

Re: [HACKERS] RustgreSQL

On 10 January 2017 at 09:54, Joel Jacobson wrote: > One idea of an area that would be most useful from a user-perspective > is probably all pg_catalog functions that are immutable. > They should be able to be written without expertise of the PostgreSQL > internals, > since

Re: [HACKERS] proposal: session server side variables

On 10 January 2017 at 05:14, Robert Haas wrote: > 2. The user doesn't need to re-declare the variables you want to use > at the beginning of every session. This is also the reason why many > people want global temporary tables. They don't do anything that > can't be done

Re: [HACKERS] _hash_addovflpage has a bug

On Mon, Jan 9, 2017 at 11:59 PM, Robert Haas wrote: > On Fri, Jan 6, 2017 at 11:32 PM, Amit Kapila wrote: >> On Sat, Jan 7, 2017 at 2:33 AM, Robert Haas wrote: >>> It looks to to me like the recent hash index changes have

Re: [HACKERS] Supporting huge pages on Windows

Hello, Amit, Magnus, I'm sorry for my late reply. Yesterday was a national holiday in Japan. From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > PGSharedMemoryReAttach is called after the startup of new process whereas >

Re: [HACKERS] WIP: Covering + unique indexes.

On 2017-01-09 16:02, Anastasia Lubennikova wrote: include_columns_10.0_v1.patch The patch applies, compiles, and make check is OK. It yields nice perfomance gains and I haven't been able to break anything (yet). Some edits of the sgml-changes are attached. Thank you for this very useful

Re: [HACKERS] move collation import to backend

On 18-12-2016 18:30, Peter Eisentraut wrote: > Updated patch with that fix. > Peter, I reviewed and improved your patch. * I document the new function. Since collation is a database object, I chose "Database Object Management Functions" section. * I've added a check to any-encoding database

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

On Sat, Jan 7, 2017 at 8:19 PM, Magnus Hagander wrote: > On Sat, Jan 7, 2017 at 12:31 AM, Michael Paquier > wrote: >> There is something I forgot. With this patch, >> FindStreamingStart()@pg_receivexlog.c is actually broken. In short it >> forgets

Re: [HACKERS] RustgreSQL

On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby wrote: > I do wonder if there are parts of the codebase that would be much better > suited to a language other than C, and could reasonably be ported. > Especially if that could be done in such a way that the net result is still

Re: [HACKERS] pg_background contrib module proposal

On 1/9/17 7:22 AM, amul sul wrote: On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby wrote: [skipped...] Oh, hmm. So I guess if you do that when the background process is idle it's the same as a close? I think we need some way to safeguard against accidental forkbombs

Re: [HACKERS] Increase pltcl test coverage

Jim Nasby writes: > On 1/9/17 5:38 PM, Tom Lane wrote: >> Yeah. I looked at that but couldn't get terribly excited about it, >> because AFAICS, Tcl in general is apt to fall over under sufficient >> memory pressure. > Though, since a memory error could just as likely

Re: [HACKERS] RustgreSQL

On 1/9/17 11:51 AM, Robert Haas wrote: Anyway, with regards to either Rust (which I know very little about) or C++ (which I know more about) I think it would be more promising to think about enabling extensions to be written in such languages than to think about converting the entire source

Re: [HACKERS] RustgreSQL

On 1/9/17 3:15 AM, Pavel Stehule wrote: The running unsafe PL in own managed processes is good idea - Years, I have a one diploma theme "better management of unsafe PL in Postgres" - but still without any interest from students :(. I had two possibilities to see catastrophic errors related to

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 6:07 PM, Marko Tiikkaja wrote: One use case is NEW and OLD in triggers. Checking to see if one or the other is set is easier than checking TG_OP. It's also going to be faster (probably MUCH faster; IIRC the comparison currently happens via SPI). This sounds useless.

Re: [HACKERS] Increase pltcl test coverage

On 1/9/17 5:38 PM, Tom Lane wrote: Jim Nasby writes: Hmm... I suspect there's more places where this could be a problem. For example, pltcl_quote calls palloc, which could ereport as well. Yeah. I looked at that but couldn't get terribly excited about it, because

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 1:03 AM, Jim Nasby wrote: > On 1/9/17 5:53 PM, Marko Tiikkaja wrote: > >> My idea was that the currently unsupported combination of NOT >> NULL and >> no DEFAULT would mean "has to be assigned to a non-NULL value >>

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 5:53 PM, Marko Tiikkaja wrote: My idea was that the currently unsupported combination of NOT NULL and no DEFAULT would mean "has to be assigned to a non-NULL value before it can be read from, or an exception is thrown". Solves the most

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 3:01 AM, Pavel Stehule wrote: You are forgot on function paramaters - somebody can use a function argument like FOUND, .. So auto variables should to be declared in most top namespace. Right, that's why I said it was an alternative. I agree it would be better to just have 2

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 5:12 PM, Merlin Moncure wrote: Agreed: If you want to break compatibility, pushing a new language is the better way than GUC. If you got consensus on this, having both languages side by side supported for a while (maybe 4-5 releases) is they way to go, and finally the only language

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 12:47 AM, Jim Nasby wrote: > On 1/9/17 5:30 PM, Marko Tiikkaja wrote: > My idea was that the currently unsupported combination of NOT NULL and >> no DEFAULT would mean "has to be assigned to a non-NULL value before it >> can be read from, or an

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 5:30 PM, Marko Tiikkaja wrote: This is exactly what we did not want to do with this project. The idea is to create a language which is really close to PL/PgSQL, but removes some of the brain diarrhoea currently present. As a general comment, ISTM it'd be much better to do as much

Re: [HACKERS] Make pg_basebackup -x stream the default

On Tue, Jan 10, 2017 at 12:05 AM, Magnus Hagander wrote: > OK. Pushed. I agree it made it more readable, if nothing else. Thanks. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Increase pltcl test coverage

Jim Nasby writes: > Hmm... I suspect there's more places where this could be a problem. For > example, pltcl_quote calls palloc, which could ereport as well. Yeah. I looked at that but couldn't get terribly excited about it, because AFAICS, Tcl in general is apt to

Re: [HACKERS] merging some features from plpgsql2 project

On 01/09/2017 06:12 PM, Merlin Moncure wrote: With respect to your company developers specifically? I'm genuinely curious if you've taken a good look at pl/v8 and why you've determined it's not suitable to move forward with. It's got a different set of headaches, but is really fast, and

Re: [HACKERS] merging some features from plpgsql2 project

On Mon, Jan 9, 2017 at 12:37 AM, Jim Nasby wrote: > If we're going to create a brand new language then I think it would be > extremely foolish to keep *any* of the current pain points around. Off the > top of my head: > > - variables must have an identifier (what $ in

Re: [HACKERS] merging some features from plpgsql2 project

On Sun, Jan 8, 2017 at 2:52 AM, Joel Jacobson wrote: > On Sat, Jan 7, 2017 at 8:56 PM, Pavel Stehule wrote: >> >> Jim, Marko, Joel - is there a place, features where we can find a partial >> agreement? If it is, then we can move our view there. > > I

Re: [HACKERS] Increase pltcl test coverage

On 1/9/17 4:23 PM, Tom Lane wrote: Jim Nasby writes: Got a stack trace. The abort happens in TclObjLookupVar: Yeah, I found the problem: pltcl_returnnext calls pltcl_build_tuple_result which may throw elog(ERROR), leaving the Tcl interpreter's state all screwed up,

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Mon, Jan 09, 2017 at 07:52:11PM -0300, Alvaro Herrera wrote: > David Fetter wrote: > > > + if (query->commandType == CMD_UPDATE || query->commandType == > > CMD_DELETE) > > + { > > + /* Make sure there's something to look at. */ > > + Assert(query->jointree != NULL); >

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

David Fetter wrote: > + if (query->commandType == CMD_UPDATE || query->commandType == > CMD_DELETE) > + { > + /* Make sure there's something to look at. */ > + Assert(query->jointree != NULL); > + if (query->jointree->quals == NULL) > +

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> [ pokes around... ] The code I was thinking of is convert_tuples_by_name > >> in access/common/tupconvert.c. There's a bit of an API mismatch in that > >> it wants to wrap the mapping array in a

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Sun, Jan 08, 2017 at 06:50:12PM -0600, Jim Nasby wrote: > On 1/5/17 12:04 AM, David Fetter wrote: > > +errmsg("UPDATE requires a WHERE clause > > when require_where.delete is set to on"), > > ISTM that message is no longer true. > > The second if could

Re: [HACKERS] Increase pltcl test coverage

Jim Nasby writes: > Got a stack trace. The abort happens in TclObjLookupVar: Yeah, I found the problem: pltcl_returnnext calls pltcl_build_tuple_result which may throw elog(ERROR), leaving the Tcl interpreter's state all screwed up, so that later functions go south. It

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Sat, Jan 7, 2017 at 9:01 AM, Thomas Munro wrote: > On Tue, Jan 3, 2017 at 10:53 PM, Thomas Munro > wrote: >> I will post a new rebased version soon with that and >> some other nearby problems fixed. > > Here is a new WIP patch. To

Re: [HACKERS] Increase pltcl test coverage

On 1/9/17 3:12 PM, Jim Nasby wrote: I'm compiling 8.4 now, will see if I can duplicate. Got a stack trace. The abort happens in TclObjLookupVar: if (nsPtr->varResProc != NULL || iPtr->resolverPtr != NULL) { nsPtr itself is NULL. * thread #1: tid = 0x, 0x00010949bca8

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Sun, Jan 8, 2017 at 11:36 AM, Greg Stark wrote: > On 8 January 2017 at 17:26, Greg Stark wrote: > > On 5 January 2017 at 19:01, Andres Freund wrote: > >> That's a bit odd - shouldn't the OS network stack take care of this in > >> both cases?

Re: [HACKERS] Incorrect XLogRegisterBuffer flag for revmapbuf in brin

Alvaro Herrera wrote: > If you examine the revmap in a replica after running the script below, > you'd observe it's different than the one in the master. I confirmed > that the proposed patch fixes the problem. Pushed. Thanks for the report! -- Álvaro Herrera

Re: [HACKERS] proposal: session server side variables

On Thu, Jan 5, 2017 at 5:39 AM, Fabien COELHO wrote: > Half-persistence (in definition, not in value) is not a key feature needed > by the use-case. Well, you don't get to decide that. You've been told by at least three or four people that they don't want variables to be

Re: [HACKERS] Increase pltcl test coverage

On 1/9/17 1:22 PM, Tom Lane wrote: I wrote: Pushed with that and some other, mostly-cosmetic changes. Hmm, looks like the new test cases have turned up a pre-existing bug. Some of the buildfarm is showing crashes :-(. It looks like all the unhappy critters are running Tcl 8.4.something,

Re: [HACKERS] Incorrect XLogRegisterBuffer flag for revmapbuf in brin

Alvaro Herrera wrote: > Kuntal Ghosh wrote: > > Hi all, > > > > In brin_doupdate(line 290), REGBUF_STANDARD is used to register > > revmap buffer reference in WAL record. But, revmap buffer page doesn't > > have a standard page layout and it doesn't update pd_upper and > > pd_lower as well. > >

Re: [HACKERS] ICU integration

On Tue, Dec 27, 2016 at 6:50 PM, Peter Eisentraut wrote: > Updated patch attached. Some more things I noticed following another quick read over the patch: * I think it's worth looking into ucol_nextSortKeyPart(), and using that as an alternative to

Re: [HACKERS] ICU integration

On Mon, Jan 9, 2017 at 12:25 PM, Peter Eisentraut wrote: > On 1/7/17 10:01 PM, Peter Geoghegan wrote: >> It occurs to me that the comparison caching stuff added by commit >> 0e57b4d8b needs to be considered here, too. > That might be worth looking into, but it

Re: [HACKERS] ICU integration

On 1/7/17 10:01 PM, Peter Geoghegan wrote: > It occurs to me that the comparison caching stuff added by commit > 0e57b4d8b needs to be considered here, too. When we had to copy the > string to a temp buffer anyway, in order to add the terminating NUL > byte expected by strcoll(), there was an

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/9/17 2:52 PM, Alvaro Herrera wrote: > CURRENT_USER is a standards-mandated keyword, but CURRENT_DATABASE is > not. The closest thing SQL has is CURRENT_CATALOG, which is the string > that identifies the "current default catalog". This would lead us to > COMMENT ON DATABASE

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 04:52:46PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote: > > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > > > wrote: > > > > On 1/3/17 11:52 PM, Ashutosh Bapat

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/9/17 1:34 PM, Robert Haas wrote: > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > wrote: >> On 1/3/17 11:52 PM, Ashutosh Bapat wrote: >>> We will need to make CURRENT_DATABASE a reserved keyword. But I like >>> this idea more than COMMENT ON CURRENT

Re: [HACKERS] sequence data type

On 1/8/17 2:39 PM, Steve Singer wrote: > The only concern I have with the functionality is that there isn't a way > to change the type of a sequence. If we implement the NEXT VALUE FOR expression (or anything similar that returns a value from the sequence), then the return type of that

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

Bruce Momjian wrote: > On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote: > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > > wrote: > > > On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > > >> We will need to make CURRENT_DATABASE a reserved keyword.

Re: [HACKERS] Proposal for changes to recovery.conf API

On 1/1/17 4:14 PM, Simon Riggs wrote: > OK, so here's the patch, plus doc cleanup patch. I don't think this patch is likely to succeed if we throw in more ideas in every round. I think we have or are approaching agreement on moving recovery.conf into postgresql.conf, making the settings

Re: [HACKERS] increasing the default WAL segment size

On 10 January 2017 at 07:40, Robert Haas wrote: > On Sat, Jan 7, 2017 at 7:45 PM, Jim Nasby wrote: >> Well, now that there's 3 places that need to do almost the same thing, I >> think it'd be best to just centralize this somewhere. I realize

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote: > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > wrote: > > On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > >> We will need to make CURRENT_DATABASE a reserved keyword. But I like > >> this idea more

Re: [HACKERS] Incorrect XLogRegisterBuffer flag for revmapbuf in brin

Kuntal Ghosh wrote: > Hi all, > > In brin_doupdate(line 290), REGBUF_STANDARD is used to register > revmap buffer reference in WAL record. But, revmap buffer page doesn't > have a standard page layout and it doesn't update pd_upper and > pd_lower as well. Hmm. This bug should be causing WAL

Re: [HACKERS] Increase pltcl test coverage

I wrote: > Pushed with that and some other, mostly-cosmetic changes. Hmm, looks like the new test cases have turned up a pre-existing bug. Some of the buildfarm is showing crashes :-(. It looks like all the unhappy critters are running Tcl 8.4.something, which might be a coincidence but I bet

Re: [HACKERS] Allow controlling location of tmp_install

On 1/7/17 8:52 PM, Jim Nasby wrote: > I've now moved my normal install locations to somewhere I can exclude > from mds and what-not, but I don't see any way to do that with > tmp_install. Is there a trick here I'm missing, or should I change > Makefile.global.in to check for an environment

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Alvaro Herrera writes: > Tom Lane wrote: >> [ pokes around... ] The code I was thinking of is convert_tuples_by_name >> in access/common/tupconvert.c. There's a bit of an API mismatch in that >> it wants to wrap the mapping array in a TupleConversionMap struct; but >>

Re: [HACKERS] increasing the default WAL segment size

On Sat, Jan 7, 2017 at 7:45 PM, Jim Nasby wrote: > Well, now that there's 3 places that need to do almost the same thing, I > think it'd be best to just centralize this somewhere. I realize that's not > going to save any significant amount of code, but it would make it

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut wrote: > On 1/3/17 11:52 PM, Ashutosh Bapat wrote: >> We will need to make CURRENT_DATABASE a reserved keyword. But I like >> this idea more than COMMENT ON CURRENT DATABASE. > > We already have the reserved key

Re: [HACKERS] _hash_addovflpage has a bug

On Fri, Jan 6, 2017 at 11:32 PM, Amit Kapila wrote: > On Sat, Jan 7, 2017 at 2:33 AM, Robert Haas wrote: >> It looks to to me like the recent hash index changes have left >> _hash_addovflpage slightly broken. I think that if that function >>

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Hmm. The bespoke code for constructing the attno map bothers me; > >> surely there is existing code that does that? If not, it'd still > >> make more sense to factor it out, I think, because there will

Re: [HACKERS] Incorrect XLogRegisterBuffer flag for revmapbuf in brin

Kuntal Ghosh wrote: > Added to next commitfest for tracking. I should've done it earlier. Yeah -- I hadn't noticed this thread until last week. I intend to apply this very soon. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] UNDO and in-place update

On Mon, Jan 9, 2017 at 7:50 AM, Amit Kapila wrote: > Okay, I see the point. I think here UNDO pointer can be marked > invalid either during page-pruning or vacuum. I explicitly want to avoid that, because it means re-dirtying the page. The UNDO pointer becomes invalid

Re: [HACKERS] RustgreSQL

On Sun, Jan 8, 2017 at 4:59 AM, Gavin Flower wrote: >> Is this completely unrealistic or is it carved in stone PostgreSQL will >> always be a C project forever and ever? >> > From my very limited understanding, PostgreSQL is more likely to be > converted to C++!

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/06/2017 12:54 AM, Ashutosh Sharma wrote: using pgbench -M prepared -c 10 -j 10 -T 600 -f test.sql test crashes after a few minutes with TRAP: FailedAssertion("!(LWLockHeldByMeInMode(((LWLock*) (&(bufHdr)->content_lock)), LW_EXCLUSIVE))", File: "bufmgr.c", Line: 3781)

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Mon, Jan 9, 2017 at 4:14 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > pg_is_xlog_replay_paused| pg_is_recovery_paused > > All the other xlog_replay names have been changed to wal_replay, so > making this one different is probably not so good. > Oops, forgot

[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, failed Pavel, gstore/gbstore: The functionality worked as expected -

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/9/17 10:50 AM, Vladimir Rusinov wrote: > pg_is_xlog_replay_paused| pg_is_recovery_paused All the other xlog_replay names have been changed to wal_replay, so making this one different is probably not so good. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Replication/backup defaults

On 1/9/17 7:44 AM, Magnus Hagander wrote: > So based on that, I suggest we go ahead and make the change to make both > the values 10 by default. And that we do that now, because that lets us > get it out through more testing on different platforms, so that we catch > issues earlier on if they do

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Jan 6, 2017 at 12:44 AM, Michael Paquier wrote: > > - OIDs - where do I get numbers from? I was kinda choosing them at > random, > > unaware if there is some process for keeping track of them. Please point > me > > if such thing exists and I'll change them. > >

Re: [HACKERS] Increase pltcl test coverage

Jim Nasby writes: > On 1/8/17 11:25 AM, Tom Lane wrote: >> But I don't understand >> how you got the sample output shown in the patch. Is this based >> on some unsubmitted changes in pltcl's error handling? > Maybe it's a version difference? > echo 'puts [info

Re: [HACKERS] Make pg_basebackup -x stream the default

On Sat, Jan 7, 2017 at 1:32 PM, Michael Paquier wrote: > On Sat, Jan 7, 2017 at 12:04 AM, Magnus Hagander > wrote: > > On Wed, Jan 4, 2017 at 10:43 AM, Magnus Hagander > > wrote: > >> Meh, just as I was going to respond

Re: [HACKERS] merging some features from plpgsql2 project

Hi > > Real support for using variables as identifiers / nothing restricted to > only accepting a Const. > This point is problematic not only from performance perspective. if you don't use some special syntax and you allow variables as identifier, then you will got a ambiguous situation

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Jan 9, 2017 at 5:01 PM, tushar wrote: > Thanks Dilip. issue is reproducible if we uses '--enable-cassert' switch > in the configure. We are able to reproduce it only with --enable-cassert' . Thanks, Tushar. I have fixed it. The defect was in 0002. I have

Re: [HACKERS] postgres_fdw bug in 9.6

> > Done. Attached is the new version of the patch. > > * I'm still not sure the search approach is the right way to go, so I > modified CreateLocalJoinPath so that it creates a mergejoin path that > explicitly sorts both the outer and inner relations as in > sort_inner_and_outer, by using the

Re: [HACKERS] pg_background contrib module proposal

On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby wrote: > [skipped...] > > Oh, hmm. So I guess if you do that when the background process is idle it's > the same as a close? > > I think we need some way to safeguard against accidental forkbombs for cases > where users aren't

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

Hi, > The patch itself is really straight forward (I'm new to sending patches, so > I've chosen a simple one), and there is only one thing that concerns me (as > in, if I did it right/good). The difference in syntax for SCHEMAS and the > other objects is that IN SCHEMA option makes no sense here

Re: [HACKERS] UNDO and in-place update

On Fri, Jan 6, 2017 at 7:41 PM, Robert Haas wrote: > On Fri, Jan 6, 2017 at 6:28 AM, Amit Kapila wrote: >>> Also, I'm thinking the bit could be stored in the line pointer rather >>> than the tuple, because with this design we don't need >>>

Re: [HACKERS] Replication/backup defaults

On Sun, Jan 8, 2017 at 2:19 AM, Jim Nasby wrote: > On 1/5/17 2:50 PM, Tomas Vondra wrote: > >> Ultimately, the question is whether the number of people running into >> "Hey, I can't take pg_basebackup or setup a standby with the default >> config!" is higher or lower

Re: [HACKERS] Replication/backup defaults

On Sat, Jan 7, 2017 at 7:57 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/7/17 6:23 AM, Magnus Hagander wrote: > > In the build farm, I have found 6 critters that do not end up with > the > > 100/128MB setting: sidewinder, curculio, coypu, brolga, lorikeet, > >

Re: [HACKERS] Parallel bitmap heap scan

On 01/09/2017 04:36 PM, Dilip Kumar wrote: I have taken the latest code, applied all 3 patches and compiled. Initdb is working fine for me. Can you please verify, do you have any extra patch along with my patch? Did you properly clean the code? Thanks Dilip. issue is reproducible if we uses

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Jan 9, 2017 at 3:07 PM, tushar wrote: > creating directory data ... ok > creating subdirectories ... ok > selecting default max_connections ... 100 > selecting default shared_buffers ... 128MB > selecting dynamic shared memory implementation ... posix >

Re: [HACKERS] Parallel bitmap heap scan

On 01/09/2017 01:05 PM, Dilip Kumar wrote: This patch can be used by 0003-parallel-bitmap-heap-scan-v7.patch attached in the mail and also parallel-index-scan[2] can be rebased on this, if this get committed, After applying your patches against the fresh sources of PG v10 , not able to perform

Re: [HACKERS] RustgreSQL

2017-01-09 1:21 GMT+01:00 Jim Nasby : > On 1/8/17 5:56 PM, Greg Stark wrote: > >> On 8 January 2017 at 21:50, Jim Nasby wrote: >> >>> Somewhat related to that... it would be useful if Postgres had "fenced" >>> functions; functions that ran in a

  1   2   >