Re: [HACKERS] WIP: Access method extendability

Alexander Korotkov wrote: > Hi! > > Thank you for review! So. Before this version of the patch was posted in Nov 4th 2015, both Tom and Heikki had said essentially "CREATE ACCESS METHOD is worthless, let's pursue this stuff without those commands". http://www.postgresql.org/message-id/54730dfd.2

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

Seems reasonable. For the last hunk in your patch, though, I would add a /* translator: */ comment explaining what each of the values is; otherwise it's just incomprehensible percent-sign-salad for the poor translator. Note that if the line is too long you have to use dirty tricks to avoid pginde

Re: [HACKERS] Minor bug affecting ON CONFLICT lock wait log messages

Stephen Frost wrote: > I don't think either message really fits here, unfortunately. We're not > actually checking the uniqueness of someone else's tuple here either, > after all, we're waiting to see what happens with their tuple because > ours won't be unique if it goes in with that other tuple

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: > Fabrízio de Royes Mello wrote: > >You already have a patch? If yes I'm glad to review it. > > If the community is not against it, I'll do it quickly. Changing the syntax > is the risk. In addition, we have already missed 9.6. Also we're in the middle of a commitfest, and i

Re: [HACKERS] WIP: Access method extendability

Alexander Korotkov wrote: > On Tue, Mar 22, 2016 at 1:26 AM, Alvaro Herrera > wrote: > > I noticed this state of affairs because I started reading the complete > > thread in order to verify whether a consensus had been reached regarding > > the move of IndexQual

Re: [HACKERS] WIP: Access method extendability

Robert Haas wrote: > On Tue, Mar 22, 2016 at 5:50 AM, Alexander Korotkov > wrote: > >> And then Alexander posted this version, without any discussion that > >> evidenced that those old objections were overridden. What happened > >> here? Did somebody discuss this in unarchived meetings? If so,

Re: [HACKERS] BRIN is missing in multicolumn indexes documentation

Emre Hasegeli wrote: > > I guess multicolumn BRIN behaves similarly to B-tree or GiST. But I'm > > no expert, so I need someone knowledgeable to confirm this. If the > > following wording is OK, I will update the patch. > > Multicolumn BRIN is like GIN. Every column is indexed separately. > The o

Re: [HACKERS] Proposal: Generic WAL logical messages

Petr Jelinek wrote: > +++ b/contrib/test_decoding/sql/messages.sql > @@ -0,0 +1,17 @@ > +-- predictability > +SET synchronous_commit = on; > + > +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', > 'test_decoding'); > + > +SELECT 'msg1' FROM pg_logical_emit_message(true, 't

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

Andreas Karlsson escribió: > On 03/23/2016 01:55 PM, Eduardo Morras wrote: > >Benefits: > > > >Dynamic multihoming, modifiable at run time, don't need aggregate links at > >OS level or shutdown servers/clients for a hardware or topology network > >change. > >Message oriented connection. > >Messag

Re: [HACKERS] README for src/backend/replication/logical

Craig Ringer wrote: > Hi all > > As part of some internal training/discussion I wrote some notes on logical > decoding's structure and flow that seemed worth polishing up into a draft > README for src/backend/replication/logical . That's nice, but you attached the one in src/backend/replication i

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Note: the reason for a new subdirectory, rather than putting this > stuff into src/common/, is that src/common/ is meant for code that's > shared between frontend and backend, which this stuff is not. Also, > many of these files depend on libpq which seems like an inappropriate

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > > Actually you could just list them in OBJS_FRONTEND in src/common. That > > way they're not built for the server at all; no need for a new subdir. > > Meh. I think stuff in OBJS_FRONTEND has to

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> And where to put the corresponding header files? > >> src/include/fe-utils? > > > Sounds fair but would that be installed in PREFIX/include/server? > > That'd be a bit odd, but I&#

Re: [HACKERS] WIP: Access method extendability

I don't quite see how this is supposed to work: + #ifdef WAL_DEBUG + /* +* If xlog debug is enabled then check produced delta. Result of delta +* application to saved image should be the same as current page state. +*/ + if (XLOG_DEBUG) + { + chartmp[BLCKSZ]; + m

Re: [HACKERS] WIP: Access method extendability

Teodor Sigaev wrote: > So, per patch status: > create-am > ready Teodor agreed to me committing this one instead of him; thanks. I just pushed it after some mostly cosmetic adjustments. I pass the baton back to Teodor for the remaining patches in this series. Thanks, -- Álvaro Herrera

Re: [HACKERS] WIP: Access method extendability

Alvaro Herrera wrote: > Teodor Sigaev wrote: > > > So, per patch status: > > create-am > > ready > > Teodor agreed to me committing this one instead of him; thanks. I just > pushed it after some mostly cosmetic adjustments. This was maybe too laconic. I

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Robert Haas wrote: > On Wed, Mar 23, 2016 at 1:00 PM, Abhijit Menon-Sen > wrote: > > Now, the first part of this works fine. But with the second part, I get > > a reduce/reduce conflict if I use any_name. Here's an excerpt from the > > verbose bison output: > > > > State 2920 > > > > 1181 Alter

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > What I propose doing is leaving the above-listed items in > pg_dump/dumputils.h/.c, and moving the rest of what's in those files > to new files src/include/fe_utils/string_utils.h and > src/fe_utils/string_utils.c. Seems reasonable. > This name is a bit arbitrary, but most of w

Re: [HACKERS] multivariate statistics v14

Tomas Vondra wrote: > >+values[Anum_pg_mv_statistic_stamcv - 1] = PointerGetDatum(data); > > > >Why the double space (that's actually in several places in several of > >the patches). > > To align the whole block like this: > > nulls[Anum_pg_mv_statistic_stadeps -1] = true; > nu

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Christian Ullrich wrote: > * Christian Ullrich wrote: > > >* From: Magnus Hagander [mailto:mag...@hagander.net] > >>Code uses a mix of malloc() and palloc() (through sprintf). Is there a > >>reason for that? > > > >I wasn't sure which to prefer, so I looked around in auth.c, and other than > >RAD

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Christian Ullrich wrote: > To be honest, I'm not sure what can and cannot be done in auth code. I > took inspiration from the existing SSPI code and nearly every error > check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already, > directly or via pg_SSPI_error(). If this could cause serious

Re: [HACKERS] multivariate statistics v14

Tomas Vondra wrote: > There are a few places where I reverted the pgindent formatting, because it > seemed a bit too weird - the first one are the lists of function prototypes > in common.h/mvstat.h, the second one are function calls to > _greedy/_exhaustive methods. Function prototypes being wei

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Andres Freund wrote: > On 2016-03-28 15:46:43 +0300, Alexander Korotkov wrote: > > @@ -932,8 +936,13 @@ ReadBuffer_common(SMgrRelation smgr, cha > > > > if (isLocalBuf) > > { > > - /* Only need to adjust flags */ > > - bufHdr->flags |= BM_VALID; > > + /* > >

Re: [HACKERS] multivariate statistics v14

Tomas Vondra wrote: > I'm not sure about the prototypes though. It was a bit weird because > prototypes in the same header file were formatted very differently. Yeah, it is very odd. What happens is that the BSD indent binary does one thing (return type is in one line and function name in follow

Re: [HACKERS] WIP: Access method extendability

Alexander Korotkov wrote: > On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera > wrote: > > > .. Oh crap. I just noticed I forgot to update a comment in pg_dump's > > getAccessMethods. And we're missing psql tab-complete support for the > > new commands.

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

Michael Paquier wrote: > On Wed, Mar 23, 2016 at 12:24 AM, Alvaro Herrera > wrote: > > Seems reasonable. For the last hunk in your patch, though, I would add > > a /* translator: */ comment explaining what each of the values is; > > otherwise it's just incomprehensib

Re: [HACKERS] BRIN is missing in multicolumn indexes documentation

Petr Jediný wrote: > Comments? This is my first patch to postgresql project, so comments > are very much welcomed. I think it's fine, so I pushed it. Thanks. I hope you already read this https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F -- Álvaro Herrerahttp://

Re: [HACKERS] pthread portability

Michael McConville wrote: > The below diff fixes one problem: you can't compare pthread_t values > directly. Only the function pthread_equal(3) is defined. Direct > comparison usually works because most implementations define pthread_t > as an integer type. So is there a platform where this assump

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

Craig Ringer wrote: > I found a minor issue with the new psql method while writing tests for > failover slots. Patch attached. Thanks, pushed. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele wrote: > On 3/29/16 10:18 AM, Tom Lane wrote: > >Repurposing COMMERROR is definitely starting to seem like a low-impact > >solution compared to these others. Under what circumstances would you > >be wanting hide-from-client with an elevel different from LOG, anyway? > > In pgaudit t

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

Michael Paquier wrote: > On Tue, Mar 29, 2016 at 2:45 AM, Alvaro Herrera > wrote: > > If you're interesting in improving translatability of this program > > further, I suggest that messages of this sort > > msgid "BKPBLOCK_HAS_DATA set, but no data inclu

Re: [HACKERS] WIP: Access method extendability

Petr Jelinek wrote: > And here it is. It's not perfect but it's better (I am not native speaker > either). It's same as v12, just changed comments somewhat. I think this can still be improved a bit more, in particular this large comment, which I edit inline for expediency. > + /*

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Robert Haas wrote: > Yeah, I think it's dead certain that such code exists, and, ahem, not > only in our tree. I suspect that EDB is not the only organization > that has written code that involves comparing error levels. Putting > the flags in the low-order bits seems like it might be workable,

Re: [HACKERS] pgbench - show weight percent

Fabien wrote: > > This minor patch shows the expected drawing percent in multi-script reports, > next to the relative weight. Applied together with the zero weight. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > > >- that it does work:-) I'm not sure what happens by the script selection > > process, it should be checked carefully because it was not designed > > with allowing a zero weight, and it may depend on its/their positions. > > It may already work, but it really needs chec

Re: [HACKERS] pgbench stats per script & other stuff

Alvaro Herrera wrote: > In doing this, I noticed that the latency output is wrong if you use -T > instead of -t; it always says the latency is zero because "duration" is > zero. I suppose it should be like in the attached instead. At the same > time, it says "laten

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > > Hello, > > >>In doing this, I noticed that the latency output is wrong if you use -T > >>instead of -t; it always says the latency is zero because "duration" is > >>zero. I suppose it should be like in the attached instead. > > Indeed, I clearly overlooked option -t (tr

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

So, it seems that ClientAuthentication() expects to raise ereport(FATAL) in case of authentication failures. But what's the code path that causes that to happen if a ereport(ERROR) happens in there? Because all that code is pretty careful to not do ereport(ERROR) directly and instead return STATU

[HACKERS] standby_schedule

I think we're at a point where we can translate the tests in src/test/regress/standby_schedule file into a PostgresNode-based test, or remove it (probably under src/test/recovery). That way, it would get run all the time rather than just when somebody feels like it (which is probably almost never,

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Tom Lane wrote: > Alvaro Herrera writes: > > So, it seems that ClientAuthentication() expects to raise ereport(FATAL) > > in case of authentication failures. But what's the code path that > > causes that to happen if a ereport(ERROR) happens in there? Because all >

Re: [HACKERS] standby_schedule

Simon Riggs wrote: > On 29 March 2016 at 22:44, Alvaro Herrera wrote: > > > I think we're at a point where we can translate the tests in > > src/test/regress/standby_schedule file into a PostgresNode-based test, > > or remove it (probably under src/test/recovery). T

Re: [HACKERS] snapshot too old, configured by time

Michael Paquier wrote: > page = BufferGetPage(buf); > + TestForOldSnapshot(scan->xs_snapshot, rel, page); > This is a sequence repeated many times in this patch, a new routine, > say BufferGetPageExtended with a uint8 flag, one flag being used to > test old snapshots would be more adapted. B

Re: [HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

Tom Lane wrote: > What we need is a unique index on pg_constraint. > > The problem with that is that pg_constraint contains both table-related > and type (domain) related constraints; but it strikes me that we could > probably create a unique index on (conrelid, contypid, conname). Weren't you pr

Re: [HACKERS] [CommitFest App] Feature request -- review e-mail additions

José Luis Tallón wrote: > Just wanted to suggest two minor mods to the review e-mails > auto-generated by the app: > > * Prepend a [review] tag to the e-mail subject > ... so that e-mails sent to -hackers will read " [HACKERS] [review] > " Changing the subject of an email causes Gmail t

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > On Wed, Mar 30, 2016 at 11:37 AM, Tom Lane wrote: > > Alvaro Herrera writes: > >> I think a safer proposition would be to replace all current > >> BufferGetPage() calls (there are about 500) by adding the necessary > >> arguments: b

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > On Wed, Mar 30, 2016 at 2:22 PM, Alvaro Herrera > wrote: > > I said that we should change BufferGetPage into having the snapshot > > check built-in, except in the cases where a flag is passed; and the flag > > would be passed in all cases excep

Re: [HACKERS] Timeline following for logical slots

Craig Ringer wrote: > It removes the questionable cleanups, fixes the randAccess comment (IMO), I pushed cleanup separately, including the addition of a few comments that were documenting the original code. I actually made a mistake in extracting those, so there's one comment that's actually bog

Re: [HACKERS] snapshot too old, configured by time

Michael Paquier wrote: > Just a note: I began looking at the tests, but finished looking at the > patch entirely at the end by curiosity. Regarding the integration of > this patch for 9.6, I think that bumping that to 9.7 would be wiser > because the patch needs to be re-written largely, and that'

Re: [HACKERS] Very small patch for decode.c

Konstantin Knizhnik wrote: > diff --git a/src/backend/replication/logical/decode.c > b/src/backend/replication/logical/decode.c > index 2380ea2..a992662 100644 > --- a/src/backend/replication/logical/decode.c > +++ b/src/backend/replication/logical/decode.c > @@ -488,7 +488,7 @@ DecodeCommit(Logic

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

Andres Freund wrote: > On 2016-01-11 21:16:42 -0300, Alvaro Herrera wrote: > > Andres, Robert, are you still reviewing this patch? > > I don't think I've signed to - or actually did - reviewed this path. Well, maybe not as such, but you replied to the thread several ti

Re: [HACKERS] Speedup twophase transactions

Michael Paquier wrote: > On Tue, Jan 12, 2016 at 5:21 PM, Simon Riggs wrote: > > Should we just move the code somewhere just to imply it is generic? Seems > > pointless refactoring to me. > > Er, why not xlogutils.c? Having the 2PC code depending directly on > something that is within logicalfunc

Re: [HACKERS] Support for N synchronous standby servers - take 2

Michael Paquier wrote: > On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI > wrote: > > Hello, > > > > At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier > > wrote in > > > >> > >> Something that I find rather scary with this patch: could it be > >> possible to get actual regression tests now

Re: [HACKERS] pg_dump dumps event triggers and transforms unconditionally

Tom Lane wrote: > I noticed $subject while trying to fix the extension membership problem > Karsten Hilbert complained of last week. I do not think that if I ask > for a dump of a single table, that should include event triggers. Ugh, certainly not. > AFAICT event triggers don't belong to any pa

Re: [HACKERS] WIP: Rework access method interface

I just noticed that this patch had remained in Waiting-for-author status after Alexander had already submitted the updated version of the patch. I marked it as ready-for-committer, because Petr stated so in the thread. Tom, you're registered as committer for this patch. Do you have time in the ne

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > > Here is a two part v12, which: > > part a (refactoring of scripts and their stats): > - fix option checks (-i alone) > - s/repleacable/replaceable/ in doc > - keep small description in doc and help for -S & -N > - fix 2 comments for pg style > - show builtin list if

Re: [HACKERS] [PATCH] better systemd integration

Peter Eisentraut wrote: > I have written a couple of patches to improve the integration of the > postgres daemon with systemd. Great. Is anything happening with these patches, or? They've been inactive for quite a while now. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreS

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Amit Kapila wrote: > The reason for not updating the patch related to this thread is that it is > dependent on the work for refactoring the tranches for LWLocks [1] > which is now coming towards an end, so I think it is quite reasonable > that the patch can be updated for this work during commit f

Re: [HACKERS] statistics for array types

Alexander Korotkov wrote: > The patch implementing my idea above is attached. What's the status here? Jeff, did you have a look at Alexander's version of your patch? Tomas, does this patch satisfy your concerns? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Developme

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Peter Geoghegan wrote: > On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote: > > I only see one patch version on the thread. > > I'm not going to post a revision until I thrash out the tiny issues > with Heikki. He kind of trailed off. So maybe that kills it > immediately, which is a shame. If

Re: [HACKERS] 2016-01 Commitfest

Two weeks into the commitfest, things have moved a bit: Needs review: 53. Waiting on Author: 20. Ready for Committer: 10. Committed: 16. Total: 99. https://commitfest.postgresql.org/8/ We have two committed patches since last report -- not a lot for a whole week. We've managed t

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

Andrew Dunstan wrote: > I think we can be a bit more adventurous and remove all the Cygwin-specific > code. See attached patch, which builds fine on buildfarm cockatiel. Hopefully you also tested that it builds under MSVC :-) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreS

Re: [HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

Andres Freund wrote: > On December 4, 2015 9:48:55 AM GMT+01:00, Craig Ringer > wrote: > >On 3 December 2015 at 22:58, Amit Kapila > >wrote: > > > >> On Thu, Dec 3, 2015 at 9:02 AM, Craig Ringer > >> wrote: > > >http://www.postgresql.org/message-id/CAA4eK1+=5Ex8-5NRr3u94=_t2p65v0kcjZ5rXddVmkx=

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Peter Geoghegan wrote: > On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera > wrote: > > If you refuse to post an updated version of the patch until Heikki > > weighs in some more, and given that Heikki has (for the purposes of this > > patch) completely vanished, I t

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

> diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c > new file mode 100644 > index 1ae4bb7..c819517 > *** a/src/pl/plpgsql/src/pl_comp.c > --- b/src/pl/plpgsql/src/pl_comp.c > *** plpgsql_parse_tripword(char *word1, char > *** 1617,1622 > --- 1617,1677 >

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

Andrew Dunstan wrote: > > > On 01/18/2016 12:38 PM, Alvaro Herrera wrote: > >Andrew Dunstan wrote: > > > >>I think we can be a bit more adventurous and remove all the Cygwin-specific > >>code. See attached patch, which builds fine on buildfarm cockatie

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

FWIW the reason I read through this patch is that I wondered if there was anything in common with this other patch https://commitfest.postgresql.org/8/459/ -- and the answer seems to be "no". What that patch does is add a new construct TYPE(1+1) which in this case returns "int4"; I guess if we

Re: [HACKERS] Tsvector editing functions

So, Tomas, Teodor, did you like this new version of the patch? Stas Kelvich wrote: > > 7) Some of the functions use intexterm that does not match the function > > name. I see two such cases - to_tsvector and setweight. Is there a > > reason for that? > > Because sgml compiler wants unique in

Re: [HACKERS] Logical decoding on standby

Hi Dimitriy, Дмитрий Сарафанников wrote: > /* > * TODO: We got to change that someday soon... [ more code ] > if (RecoveryInProgress()) > ereport(ERROR, > (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > errmsg("logical decoding cannot be used while in recovery"))); > When you plan to add logical

Re: [HACKERS] PATCH: Extending the HyperLogLog API a bit

While going over this patch I noticed this commit in HyperLogLog's upstream: https://github.com/hideo55/cpp-HyperLogLog/commit/b8cb5e7b856928af15e9535b4b1650f493ba453f In the first hunk which is what we care about, the author is doing bit-or of both hash values instead of taking the max value, wh

Re: [HACKERS] make error - libpqdll.def No such file or directory

Igal @ Lucee.org wrote: > So when I try to run `make` I still get that error. Please note that I am > doing a VPATH build (the build in a separate directory from the downloaded > sources), which might play a role here: > > x86_64-w64-mingw32-gcc.exe: error: libpqdll.def: No such file or director

Re: [HACKERS] make error - libpqdll.def No such file or directory

Igal @ Lucee.org wrote: > Alvaro -- thank you for your reply! > > So to clarify (in the hopes that it would allow me to keep some hair on my > head by the end of this process, as I already pulled out most of it by > now)... > your process was as follows? > > build-dir$ ~/source-dir/configure --h

Re: [HACKERS] make error - libpqdll.def No such file or directory

Andrew Dunstan wrote: > jacana does VPATH builds with pretty much this setup all the time. See for > example > Yes, it builds a tree *once*, then deletes the result, and the next BF run uses a completely new

Re: [HACKERS] Advices on custom data type and extension development

Luciano Coutinho Barcellos wrote: > * the type would be 8 bytes long, being 4 dedicated to storing the > Date, and 4 dedicated to storing a serial within that day; Another thing to consider -- have you carefully defined what the "current day" is? This might sound a stupid question, but a

[HACKERS] Re: [BUGS] about test_parser installation failure problem(PostgreSQL in 9.5.0)？

閬閬イふ wrote: > hi postgreSql ! > test_parser install is ok (postgresql 9.2.4) > but at (postgresql 9.5.0) failure？ > why？the postgresql say: > CREATE EXTENSION zhparser What is zhparser anyway? There is one such thing at https://github.com/amutu/zhparser but I don't think it depends on

Re: [HACKERS] jsonb array-style subscription

Dmitry Dolgov wrote: > I've cleaned up the code, created a separate JsonbRef node (and there are a > lot of small changes because of that), abandoned an idea of "deep nesting" > of assignments (because it doesn't relate to jsonb subscription, is more > about the > "jsonb_set" function, and anyway

Re: [HACKERS] PATCH: Extending the HyperLogLog API a bit

Robert Haas wrote: > On Mon, Jan 11, 2016 at 2:22 PM, Alvaro Herrera > wrote: > > Tomas Vondra wrote: > >> Attached is v2 of the patch, adding the comments. > > > > Looks pretty reasonable to me. I'm not sure we want to push this ahead > > of the bloo

Re: [HACKERS] make error - libpqdll.def No such file or directory

Igal @ Lucee.org wrote: > On 1/19/2016 10:58 AM, Alvaro Herrera wrote: > >Yes, probably something like that. I think it failed the first time > >because there was a bug (the one I introduced in a967613911f7), then > >probably changed to src/backend and ran compiles there whi

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

Joe Conway wrote: > The attached includes Bruce's change, plus I found two additional sites > that appear to need the same change. The xlog.c change is just a DEBUG > message, so not a big deal. I'm less certain if the xlogdesc.c change > might create some fallout. Hm, pg_xlogdump links the rmgrd

Re: [HACKERS] checkpointer continuous flushing

Andres Freund wrote: > The relevant thread is at > http://archives.postgresql.org/message-id/CA%2BTgmoaCr3kDPafK5ygYDA9mF9zhObGp_13q0XwkEWsScw6h%3Dw%40mail.gmail.com > what I didn't remember is that I voiced concern back then about exactly this: > http://archives.postgresql.org/message-id/20111201

Re: [HACKERS] Releasing in September

Magnus Hagander wrote: > Except that we need to do it for the last one as well. With the only > exception that the last one might be a bit longer. But the fact is that the > recent of CFs *and* releases, we've taken the approach of closing the CF > when everything in it is done or explicitly revie

Re: [HACKERS] Releasing in September

Joshua D. Drake wrote: > 4. Submit a patch, review a patch. > > Don't review patches? Don't submit patches. Here's one area where the commitfest app could help the CFM. I would like to have a report that shows, for each person, the list of patches where they are author, and the list of patches

Re: [HACKERS] Releasing in September

Magnus Hagander wrote: > On Jan 20, 2016 18:57, "Alvaro Herrera" wrote: > > Here's one area where the commitfest app could help the CFM. I would > > like to have a report that shows, for each person, the list of patches > > where they are author, and the lis

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

Artur Zakirov wrote: > >I don't quite understand why aren't we using a custom GUC variable here. > >These already have SHOW and SET support ... > > > > Added GUC variables: > - pg_trgm.limit > - pg_trgm.substring_limit > I added this variables to the documentation. > show_limit() and set_limit()

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

So far as I can tell, there are three patches in flight here: * replication slot IO lwlocks * ability of extensions to request tranches dynamically * PGPROC The first one hasn't been reviewed at all, but the other two have seen a bit of discussion and evolution. Is anyone doing any more reviewin

Re: [HACKERS] More stable query plans via more predictable column statistics

Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > This post summarizes a few weeks of research of ANALYZE statistics > > distribution on one of our bigger production databases with some real-world > > data and proposes a patch to rectify some of the oddities observed. > > Please add this to the

Re: [HACKERS] Releasing in September

Magnus Hagander wrote: > On Wed, Jan 20, 2016 at 6:57 PM, Alvaro Herrera > wrote: > > Here's one area where the commitfest app could help the CFM. I would > > like to have a report that shows, for each person, the list of patches > > where they are author, and the l

Re: [HACKERS] multivariate statistics v8

Bruce Momjian wrote: > On Wed, Jan 20, 2016 at 02:20:38PM -0500, Robert Haas wrote: > > On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra > > wrote: > > >The remaining question is how unique the statistics name should be. > > >My initial plan was to make it unique within a table, but that of >

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

Etsuro Fujita wrote: > On second thought, I noticed that detecting whether we see a system column > that way needs more cycles in cases where the reltargetlist and the > restriction clauses don't contain any system columns. ISTM that such cases > are rather common, so I'm inclined to keep that co

Re: [HACKERS] WIP patch to improve amvalidate functions

Tom Lane wrote: > I'm posting this now just in case anyone has some comments, or quibbles > about the overall intent. In particular, if anyone has an idea for a more > thorough missing-objects check on BRIN opfamilies, I would like to hear > it. The fact that there are two kinds of opfamilies wi

Re: [HACKERS] Releasing in September

Bruce Momjian wrote: > FYI, the fact that feature authors appear in the release notes is an > artifact of how we track who wrote which stuff, and is not designed for > rewarding, though it has that effect. I think you can claim this all you want, but I'd be surprised if anyone actually believed i

Re: [HACKERS] Patch: Implement failover on libpq connect level.

You're editing the expected file for the libpq-regress thingy, but you haven't added any new lines to test the new capability. I think it'd be good to add some there. (I already said this earlier in the thread; is there any reason you ignored it the first time?) If the test program requires impr

Re: [HACKERS] pg_dump fails on domain constraint comments

Michael Paquier wrote: > On Tue, Jan 12, 2016 at 7:56 AM, Elvis Pranskevichus > wrote: > > It looks like pg_dump emits incorrect text for domain constraint comments: > > > > Assuming the following structure, > > Nice catch! qtypname already has fmtId applied to it, so quotes are > applied twice

Re: [HACKERS] 2016-01 Commitfest

Into its third week, this commitfest is looking like this: Needs review: 41. Waiting on Author: 24. Ready for Committer: 10. Committed: 23. Rejected: 1. Total: 99. The number of committed patches continues to grow slowly but steadily, which is a good sign -- and in the past week it grew eve

Re: [HACKERS] 2016-01 Commitfest

Andres Freund wrote: > On 2016-01-25 13:36:04 -0300, Alvaro Herrera wrote: > > We still have 41 patches that haven't gotten enough review though. The > > bad part about it is that there's a number of patches that have been > > bouncing for many commitfests now. He

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > You know how delighted I am to split patches... Yes, of course, it's the most interesting task in the world. I'm fully aware of that. FWIW I'm going to apply a preliminary commit to pgindent-clean the file before your patches, then apply each patch as pgindent-clean. Oth

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > a) add -b option for cumulating builtins and rework internal script >management so that builtin and external scripts are managed the >same way. I tweaked this a bit. I found a bug in threadRun: it was reading the commands first, and setting st->use_file later. Thi

Re: [HACKERS] Speedup twophase transactions

Stas Kelvich wrote: > While this patch touches quite sensible part of postgres replay and there is > some rarely used code paths, I wrote shell script to setup master/slave > replication and test different failure scenarios that can happened with > instances. Attaching this file to show test sc

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Simon Riggs wrote: > On 25 January 2016 at 09:55, Tomas Vondra > wrote: > > > > Imagine for example a script that in some rare cases passes happens to > > pass infinity into generate_series() - in that case I'd much rather error > > out than wait till the end of the universe. > > > > So +1 from

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > a) add -b option for cumulating builtins and rework internal script >management so that builtin and external scripts are managed the >same way. I'm uncomfortable with the prefix-matching aspect of -b. It makes "-b s" ambiguous -- whether it stands for select-only o

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > >It seems a bit funny to have the start_time not be reset when 0.0 is > >passed, which is almost all the callers. Using a float as a boolean > >looks pretty odd; is that kosher? Maybe it'd be a good idea to have a > >separate boolean flag instead? > Obviously this would w

<    1   2   3   4   5   6   7   8   9   10   >