Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

On Thu, Mar 10, 2016 at 8:37 AM, Abhijit Menon-Sen wrote: > At 2016-03-10 08:35:43 +0100, michael.paqu...@gmail.com wrote: >> >> > I guess the easiest fix would be to shell out to initdb -s? >> >> What do you mean? I am not sure what initdb has to do with that as we >> have

Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

At 2016-03-10 08:35:43 +0100, michael.paqu...@gmail.com wrote: > > > I guess the easiest fix would be to shell out to initdb -s? > > What do you mean? I am not sure what initdb has to do with that as we > have no need for it in pg_rewind. initdb -S/--sync-only fsyncs everything in the data

Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

On Thu, Mar 10, 2016 at 4:43 AM, Andres Freund wrote: > how come that the only comment in pg_rewind about fsyncing is ' > void > close_target_file(void) > { > ... > /* fsync? */ > } > > Isn't that a bit, uh, minimal for a utility that's likely to be used in > failover

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Thu, Mar 3, 2016 at 11:50 PM, Robert Haas wrote: >What if you apply both this and Amit's clog control log patch(es)? Maybe the combination of the two helps substantially more than either >one alone. I did the above tests along with Amit's clog patch. Machine :8

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi Amit, Thank you for updating the patch. > -Original Message- > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Thursday, March 10, 2016 3:36 PM > To: Robert Haas > Cc: Kyotaro HORIGUCHI ; Amit Langote >

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

On Thu, Mar 10, 2016 at 12:12 AM, Alvaro Herrera wrote: > Aleksander Alekseev wrote: >> pg_receivexlog: could not send replication command "START_REPLICATION": >> out of memory pg_receivexlog: disconnected; waiting 5 seconds to try >> again pg_receivexlog: starting log

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Petr Jelinek > Sent: Thursday, March 10, 2016 11:01 AM > To: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Reworks of CustomScan

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

On Wed, Mar 9, 2016 at 12:13 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I'm pretty meh about the whole idea of this function, though, >> actually, and I don't see a single clear +1 vote for this >> functionality upthread. (Apologies if I've missed one.) In the

Re: [HACKERS] [GENERAL] Request - repeat value of \pset title during \watch interations

Adding -hackers for consideration in the Commitfest. Thanks! David J. >>>Original request by me http://www.postgresql.org/message-id/CAKFQuwZqjz-je3Z=8jdodym3jm-n2ul4cuqy5vh8n75e5v1...@mail.gmail.com When executing a query using \watch in psql the first execution of the query includes "Title

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/10 14:29, Amit Langote wrote: > I rebased remainder patches (attached). > > 0001 is a small patch to fix issues reported by Tomas and Vinayak. 0002 > and 0003 are WIP patches to implement progress reporting for vacuum. Oops, in 0002, I wrongly joined with pg_class in the definition

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

Thank you for reviewing! Attached updated patch. On Thu, Mar 10, 2016 at 3:37 AM, Robert Haas wrote: > On Wed, Mar 9, 2016 at 9:09 AM, Masahiko Sawada > wrote: Attached latest 2 patches. >> * 000 patch : Incorporated the review comments and made

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On Thu, Mar 10, 2016 at 1:29 AM, David Steele wrote: > On 1/8/16 9:34 AM, Alvaro Herrera wrote: >> Simon Riggs wrote: >>> >>> On 8 January 2016 at 13:36, Alvaro Herrera >>> wrote: I would agree except for the observation on toast indexes.

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/10 2:16, Robert Haas wrote: > On Wed, Mar 9, 2016 at 2:37 AM, Amit Langote > wrote: >> On 2016/03/09 10:11, Amit Langote wrote: >>> The attached revision addresses above and one of Horiguchi-san's comments >>> in his email yesterday. >> >> I fixed one

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

On Wed, Mar 9, 2016 at 7:17 PM, Robert Haas wrote: > > On Wed, Mar 9, 2016 at 8:31 AM, Amit Kapila wrote: > > Thanks for the suggestion. I have updated the patch to include wait_event_type information in the wait_event table. > > I think we should

Re: [HACKERS] Pushing down sorted joins

On Wed, Mar 9, 2016 at 9:22 PM, Robert Haas wrote: > On Wed, Mar 9, 2016 at 2:23 AM, Ashutosh Bapat > wrote: > > [ new patch ] > > This looks OK to me. Committed! > > Thanks. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The

Re: [HACKERS] pstrdup(TextDatumGetCString(foo)) ?

Chapman Flack writes: > I am encountering, here and there, an idiom like > pstrdup(TextDatumGetCString(foo)) > or a pre-8.4 version, > pstrdup(DatumGetCString(DirectFunctionCall1(textout, foo))) > It's leading me to question my sanity because it appears to me > that

[HACKERS] pstrdup(TextDatumGetCString(foo)) ?

I am encountering, here and there, an idiom like pstrdup(TextDatumGetCString(foo)) or a pre-8.4 version, pstrdup(DatumGetCString(DirectFunctionCall1(textout, foo))) It's leading me to question my sanity because it appears to me that both text_to_cstring (underlying TextDatumGetCString) and

[HACKERS] pg_rewind just doesn't fsync *anything*?

Hi, how come that the only comment in pg_rewind about fsyncing is ' void close_target_file(void) { ... /* fsync? */ } Isn't that a bit, uh, minimal for a utility that's likely to be used in failover scenarios? I think we might actually be "saved" due to

Re: [HACKERS] auto_explain sample rate

On 17/02/16 01:17, Julien Rouhaud wrote: Agreed, it's too obscure. Attached v4 fixes as you said. Seems to be simple enough patch and works. However I would like documentation to say that the range is 0 to 1 and represents fraction of the queries sampled, because right now both the GUC

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-03-07 21:55:52 -0800, Andres Freund wrote: > Here's my updated version. > > Note that I've split the patch into two. One for the infrastructure, and > one for the callsites. I've finally pushed these, after making a number of mostly cosmetic fixes. The only of real consequence is that

Re: [HACKERS] Relation extension scalability

On 10/03/16 02:53, Dilip Kumar wrote: Attaching a latest patch. Hmm, why did you remove the comment above the call to UnlockRelationForExtension? It still seems relevant, maybe with some minor modification? Also there is a bit of whitespace mess inside the conditional lock block. --

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On 10/03/16 02:18, Kouhei Kaigai wrote: > >> I am not sure I like the fact that we have this EXTNODENAME_MAX_LEN and >> now the CUSTOM_NAME_MAX_LEN with the same length and also they are both >> same lenght as NAMEDATALEN I wonder if this shouldn't be somehow >> squished to less defines. >> >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi, Thank you very much for committing this feature. > -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Thursday, March 10, 2016 2:17 AM > To: Amit Langote > Cc: Kyotaro HORIGUCHI ; Amit Langote >

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

On 10 March 2016 at 05:30, Alvaro Herrera wrote: > Craig Ringer wrote: > > > 004 allows filtering on RecursiveCopy by a predicate function. Needed for > > filesystem level backups (007). It could probably be squashed with 007 if > > desired. > > I pushed this after some

Re: [HACKERS] Relation extension scalability

On Wed, Mar 9, 2016 at 1:39 AM, Robert Haas wrote: > LockWaiterCount() bravely accesses a shared memory data structure that > is mutable with no locking at all. That might actually be safe for > our purposes, but I think it would be better to take the partition > lock in

Re: [HACKERS] Proposal: RETURNING primary_key()

On 10 March 2016 at 00:41, Igal @ Lucee.org wrote: > On 3/8/2016 5:12 PM, Craig Ringer wrote: > >> One of the worst problems (IMO) is in the driver architecture its self. >> It attempts to prevent blocking by guestimating the server's send buffer >> state and its recv buffer

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

> On 29/02/16 13:07, Kouhei Kaigai wrote: > > > > I'd like to adjust a few of custom-scan interface prior to v9.6 freeze. > > > > The major point is serialization/deserialization mechanism. > > Now, extension has to give LibraryName and SymbolName to reproduce > > same CustomScanMethods on the

Re: [HACKERS] Parallel Aggregate

On Mon, Mar 7, 2016 at 4:39 PM, Tom Lane wrote: > Haribabu Kommi writes: >> 2. Temporary fix for float aggregate types in _equalAggref because of >> a change in aggtype to trans type, otherwise the parallel aggregation >> plan failure in

Re: [HACKERS] statistics for array types

On 1/18/16 11:24 AM, Alvaro Herrera wrote: 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? This was marked as "needs review"

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

On 03/02/16 05:02, Robert Haas wrote: On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: I have attached a patch that adds an ereport() macro to suppress client output for a single report call (applies cleanly on 1d0c3b3). I'll also move it to the next CF. I don't see

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On 1/8/16 9:34 AM, Alvaro Herrera wrote: Simon Riggs wrote: On 8 January 2016 at 13:36, Alvaro Herrera wrote: I would agree except for the observation on toast indexes. I think that's an important enough use case that perhaps we should have both. The exclusion of

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

Hi, On 29/02/16 13:07, Kouhei Kaigai wrote: > > I'd like to adjust a few of custom-scan interface prior to v9.6 freeze. > > The major point is serialization/deserialization mechanism. > Now, extension has to give LibraryName and SymbolName to reproduce > same CustomScanMethods on the background

Re: [HACKERS] Proposal: Generic WAL logical messages

On 08/03/16 21:21, Artur Zakirov wrote: I think here +const char * +logicalmsg_identify(uint8 info) +{ +if (info & ~XLR_INFO_MASK == XLOG_LOGICAL_MESSAGE) +return "MESSAGE"; + +return NULL; +} we should use brackets const char * logicalmsg_identify(uint8 info) { if

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Thu, Mar 10, 2016 at 5:30 AM, Robert Haas wrote: > On Wed, Mar 9, 2016 at 7:16 AM, Haribabu Kommi > wrote: >> On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila wrote: >>> On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi

Re: [HACKERS] Timeline following for logical slots

On 04/03/16 17:08, Craig Ringer wrote: I'd really appreciate some review of the logic there by people who know timelines well and preferably know the xlogreader. It's really just one function and 2/3 comments; the code is simple but the reasoning leading to it is not. I think this will have

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

Hi Victor, On 2/1/16 5:05 PM, Alvaro Herrera wrote: Victor Wagner wrote: On Fri, 22 Jan 2016 16:36:15 -0300 Alvaro Herrera wrote: 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

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

Craig Ringer wrote: > 007 adds PostgresNode support for hot and cold filesystem-level backups > using pg_start_backup and pg_stop_backup, which will be required for some > coming tests and are useful by themselves. Finally, pushed this one after rebasing on top of the changes in the others. I

Re: [HACKERS] Optimizer questions

Konstantin Knizhnik writes: > I think that the best approach is to generate two different paths: > original one, when projection is always done before sort and another one > with postponed projection of non-trivial columns. Then we compare costs > of two paths and

Re: [HACKERS] HINTing on UPDATE foo SET foo.bar = ..;

On 12/23/15 9:15 PM, Michael Paquier wrote: On Mon, Dec 7, 2015 at 9:14 PM, Michael Paquier wrote: On Wed, Sep 2, 2015 at 6:19 AM, Marko Tiikkaja wrote: Hopefully nobody minds if I slip this to the commit fest that started today? The attached patch

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

Craig Ringer wrote: > 004 allows filtering on RecursiveCopy by a predicate function. Needed for > filesystem level backups (007). It could probably be squashed with 007 if > desired. I pushed this after some tinkering: * filtering applies to all directory entries, not just files. So you can

Re: [HACKERS] fun with "Ready for Committer" patches

On Wed, Mar 9, 2016 at 10:19 PM, Andres Freund wrote: > On 2016-03-10 06:14:25 +0900, Michael Paquier wrote: >> IMO, during a review one needs to think of himself as a committer. >> Once the reviewer switches the patch to "Ready for committer", it >> means that the last

Re: [HACKERS] fun with "Ready for Committer" patches

On 2016-03-10 06:14:25 +0900, Michael Paquier wrote: > IMO, during a review one needs to think of himself as a committer. > Once the reviewer switches the patch to "Ready for committer", it > means that the last version of the patch present would have been the > version that gained the right to be

Re: [HACKERS] fun with "Ready for Committer" patches

On Wed, Mar 9, 2016 at 9:47 PM, Robert Haas wrote: > On Tue, Mar 8, 2016 at 9:44 PM, Craig Ringer wrote: >> On 9 March 2016 at 07:18, Tatsuo Ishii wrote: >>> Many of "needs review" state patches already have reviewer(s). Do you

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi, On Wed, 2016-03-09 at 12:16 -0500, Robert Haas wrote: > On Wed, Mar 9, 2016 at 2:37 AM, Amit Langote > wrote: > > On 2016/03/09 10:11, Amit Langote wrote: > >> The attached revision addresses above and one of Horiguchi-san's comments > >> in his email

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Robert Haas writes: > On Wed, Mar 9, 2016 at 1:12 PM, Tom Lane wrote: >> I hadn't been paying any attention to this thread, but I wonder whether >> this entire approach isn't considerably inferior to what we can do now >> with the planner pathification

Re: [HACKERS] [PATCH v6] GSSAPI encryption support

David Steele writes: > On 3/8/16 5:44 PM, Robbie Harwood wrote: >> >> Here's yet another version of GSSAPI encryption support. It's also >> available for viewing on my github: > > I got this warning when applying the first patch in the set: > >

Re: [HACKERS] pg_ctl promote wait

On Mon, Feb 29, 2016 at 4:29 PM, Michael Paquier wrote: > On Mon, Feb 29, 2016 at 4:28 PM, Michael Paquier > wrote: >> I would suggest using >> $node_standby->poll_query_until('SELECT pg_is_in_recovery()') to >> validate the end of the test.

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

On Wed, Mar 9, 2016 at 12:29 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> After sleeping (best debugger ever) on that, actually a way popped up >> in my mind, and I propose the attached, which refactors a bit 005 and >> checks that the LSN position of master has

Re: [HACKERS] WIP: Upper planner pathification

On Wed, Mar 9, 2016 at 5:47 PM, Tom Lane wrote: > Alexander Korotkov writes: > > I have a question about Sort path. AFAICS this question wasn't mentioned > in > > the upthread discussion. > > We're producing Sort plans in two ways: from explicit

Re: [HACKERS] Alter or rename enum value

Besides not being able to rename enum values there are two other limitations regarding enums which would be nice to get finally fixed: 1) There is also no possibility to drop a value. 2) Quoting the docs ( http://www.postgresql.org/docs/9.5/static/sql-altertype.html): "ALTER TYPE ... ADD VALUE

Re: [HACKERS] pgbench small bug fix

OK, I've committed the fix for the -T part. It didn't back-patch cleanly, and it is a minor bug, so I'm not inclined to worry about it further. I agree that it is a very minor bug and not necessary worth back-patching. I didn't commit the fix for the -P part, because Alvaro objected to the

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, [...] With your patch, you get different behavior depending on exactly how the input is malformed. I understand that you require only one possible error message on malformed input, instead of failing when converting to double if the input looked like a double (there was a '.'

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

On Wed, Mar 9, 2016 at 9:09 AM, Masahiko Sawada wrote: Attached latest 2 patches. > * 000 patch : Incorporated the review comments and made rewriting > logic more clearly. That's better, thanks. But your comments don't survive pgindent. After running pgindent, I get this:

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Wed, Mar 9, 2016 at 7:16 AM, Haribabu Kommi wrote: > On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila wrote: >> On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi >> wrote: >>> >>> >>> I tried replacing the random() with

Re: [HACKERS] WIP: Upper planner pathification

On Wed, Mar 9, 2016 at 12:33 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Yeah, fixed. I had assumed that the existing coding in create_gather_plan >>> was OK, because it looked like it was right for a non-projecting node. >>>

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Mar 9, 2016 at 1:12 PM, Tom Lane wrote: > Robert Haas writes: >> Overall, I think this is looking pretty good. > > I hadn't been paying any attention to this thread, but I wonder whether > this entire approach isn't considerably inferior to what

Re: [HACKERS] multivariate statistics v14

On Wed, 2016-03-09 at 18:21 +0100, Tomas Vondra wrote: > Hi, > > On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: > > On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra > > wrote: > > > Hi, > > > > > > thanks for the feedback. Attached is v14 of the patch series,

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Robert Haas writes: > Overall, I think this is looking pretty good. I hadn't been paying any attention to this thread, but I wonder whether this entire approach isn't considerably inferior to what we can do now with the planner pathification patch. To quote from the new

Re: [HACKERS] pgbench small bug fix

On Wed, Mar 9, 2016 at 4:12 AM, Fabien COELHO wrote: >> On Wed, Jan 27, 2016 at 2:31 PM, Fabien COELHO >> wrote: >>> >>> - when a duration (-T) is specified, ensure that pgbench ends at that >>>time (i.e. do not wait for a transaction beyond the end

Re: [HACKERS] multivariate statistics v14

On Wed, Mar 9, 2016 at 9:21 AM, Tomas Vondra wrote: > Hi, > > On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: >> On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra >> wrote: >> > Hi, >> > >> > thanks for the feedback. Attached is v14 of

Re: [HACKERS] pgcrypto: add s2k-count

Jeff Janes wrote: > On Tue, Mar 8, 2016 at 4:09 PM, Alvaro Herrera > wrote: > Yeah, I find that pretty impenetrable too. I just treated it as a > black box, I changed how the number passed into it gets set, but not > the meaning of that number. Initially I had the

Re: [HACKERS] pgcrypto: add s2k-count

On Tue, Mar 8, 2016 at 4:09 PM, Alvaro Herrera wrote: > Jeff Janes wrote: >> pgcrypto supports s2k-mode for key-stretching during symmetric >> encryption, and even defaults to s2k-mode=3, which means configurable >> iterations. But it doesn't support s2k-count to

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Mar 9, 2016 at 3:30 AM, Etsuro Fujita wrote: > Great! I changed the naming. I also updated docs as proposed by you in a > previous email, and rebased the patch to the latest HEAD. Please find > attached an updated version of the patch. Thanks. The new

[HACKERS] enums and indexing

Currently we don't have a way to create a GIN index on an array of enums, or to use an enum field in a GIST index, so it can't be used in an exclusion constraint, among other things. I'd like to work on fixing that if possible. Are there any insuperable barriers? If not, what do we need to

Re: [HACKERS] Declarative partitioning

> > > I think we're converging on a good syntax, but I don't think the > choice of nothingness to represent an open range is a good idea, both > because it will probably create grammar conflicts now or later and > also because it actually is sort of confusing and unintuitive to read > given the

Re: [HACKERS] raw output from copy

> > >> 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 RAW was to load an existing json file. My own personal test was to load an

Re: [HACKERS] pgcrypto: add s2k-count

Alvaro Herrera wrote: > Anyway, assuming that the iteration count was already being used > correctly, then as far as I'm concerned we're ready to go. The attached > patch is what I would commit. I read some more (gnupg code as well as our own) and applied some more tweaks, and pushed. --

Re: [HACKERS] WIP: Upper planner pathification

Alvaro Herrera writes: > Tom Lane wrote: >> Yeah, fixed. I had assumed that the existing coding in create_gather_plan >> was OK, because it looked like it was right for a non-projecting node. >> But actually Gather can project (why though?), so it's not right. > This

[HACKERS] Patch to implement pg_current_logfile() function

Hi, Here is a patch that is supposed to solve the remaining problem to find the current log file used by the log collector after a rotation. There is lot of external command to try to find this information but it seems useful to have an internal function to retrieve the name of the current log

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Mar 9, 2016 at 3:09 AM, Fabien COELHO wrote: > I'm not sure what is "not acceptable" as it "totally breaks the error > handling" in the above code. > > I assumed that you want to check that sscanf can read what sprintf generated > when handling "\set". I'd guess that

Re: [HACKERS] multivariate statistics v14

Hi, On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: > On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra > wrote: > > Hi, > > > > thanks for the feedback. Attached is v14 of the patch series, fixing > > most of the points you've raised. > > > Hi Tomas, > > Applied

Re: [HACKERS] WIP: Upper planner pathification

On Wed, Mar 9, 2016 at 12:07 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> Amit Kapila writes: > >> > Without setting max_parallel_degree, it works fine and generate the >> > appropriate results. Here the issue seems to be that the code in >>

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Wed, Mar 9, 2016 at 2:37 AM, Amit Langote wrote: > On 2016/03/09 10:11, Amit Langote wrote: >> The attached revision addresses above and one of Horiguchi-san's comments >> in his email yesterday. > > I fixed one more issue in 0002 per Horiguchi-san's comment.

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > On 03/09/2016 11:07 AM, Tom Lane wrote: >> I have a vague recollection that we discussed this at the time the enum >> stuff went in, and there are concurrency issues? Don't recall details >> though. > Rings a vague bell, but should it be any worse

Re: [HACKERS] WIP: Upper planner pathification

Tom Lane wrote: > Amit Kapila writes: > > Without setting max_parallel_degree, it works fine and generate the > > appropriate results. Here the issue seems to be that the code in > > grouping_planner doesn't apply the required PathTarget to Path below Gather > > Path

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 11:07 AM, Tom Lane wrote: Andrew Dunstan writes: On 03/09/2016 09:56 AM, Matthias Kurz wrote: Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I don't know of any plans, but it would be a useful thing.

Re: [HACKERS] [PATCH v6] GSSAPI encryption support

Hi Robbie, On 3/8/16 5:44 PM, Robbie Harwood wrote: > Hello friends, > > Here's yet another version of GSSAPI encryption support. It's also > available for viewing on my github: I got this warning when applying the first patch in the set:

Re: [HACKERS] Crash with old Windows on new CPU

* Magnus Hagander wrote: On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich wrote: * Magnus Hagander wrote: How does this work wrt mingw, though? Do we have the same problem there? AIUI this code can never run on mingw, correct? Not unless mingw defines _MSC_VER.

Re: [HACKERS] Crash with old Windows on new CPU

Magnus Hagander wrote: > On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich > wrote: > > And apparently not a single one with VS 2013. OK, I'll see what I can do > > about setting some up soonish, at least with (server) 2008 and (client) 7. > > FWIW, I have a local build of

Re: [HACKERS] multivariate statistics v14

On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra wrote: > Hi, > > thanks for the feedback. Attached is v14 of the patch series, fixing > most of the points you've raised. Hi Tomas, Applied to aa09cd242fa7e3a694a31f, I still get the seg faults in make check if I

Re: [HACKERS] Proposal: RETURNING primary_key()

On 3/8/2016 5:12 PM, Craig Ringer wrote: One of the worst problems (IMO) is in the driver architecture its self. It attempts to prevent blocking by guestimating the server's send buffer state and its recv buffer state, trying to stop them filling and causing the server to block on writes. It

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

"Shulgin, Oleksandr" writes: > Yes, I now recall that my actual concern was that sample_cnt may calculate > to 0 due to the latest condition above, but that also implies track_cnt == > 0, and then we have a for loop there which will not run at all due to this, > so I

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

On Wed, Mar 9, 2016 at 1:33 PM, Tomas Vondra wrote: > Hi, > > On Wed, 2016-03-09 at 11:23 +0100, Shulgin, Oleksandr wrote: > > On Tue, Mar 8, 2016 at 8:16 PM, Alvaro Herrera > > wrote: > > > > Also, I can't quite figure out why the

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

Tomas Vondra writes: > On Wed, 2016-03-09 at 12:02 -0300, Alvaro Herrera wrote: >> Tomas Vondra wrote: >>> FWIW while looking at the code I noticed that we skip wide varlena >>> values but not cstrings. Seems a bit suspicious. >> Uh, can you actually have columns of

Re: [HACKERS] the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1

On 2016年03月09日 23:31, Andres Freund wrote: Did you enable track_commit_timestamps in the server? That's unrelated, commit ts is about an xid timestamp mapping. Yes, whether enable track_commit_timestamp or not, I have just done the test again and the result is the same. Thxs all!

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

On Wed, 2016-03-09 at 12:02 -0300, Alvaro Herrera wrote: > Tomas Vondra wrote: > > > FWIW while looking at the code I noticed that we skip wide varlena > > values but not cstrings. Seems a bit suspicious. > > Uh, can you actually have columns of cstring type? I don't think you > can ... Yeah,

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > On 03/09/2016 09:56 AM, Matthias Kurz wrote: >> Right now it is not possible to rename an enum value. >> Are there plans to implement this anytime soon? > I don't know of any plans, but it would be a useful thing. I agree it > wouldn't be too hard.

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 09:56 AM, Matthias Kurz wrote: Hi! Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I had a bit of a discussion on the IRC channel and it seems it shouldn't be that hard to implement this. Again, I am talking about renaming

[HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

Hi all, I faced suspicious behaviour on hot standby server related to visibility map. The scenario is, 1. Create table and check internal of visibility map on master server. postgres(1)=# create table hoge (col int); CREATE TABLE postgres(1)=# insert into hoge select generate_series(1,10);

Re: [HACKERS] WIP: Upper planner pathification

Amit Kapila writes: > On latest commit-51c0f63e, I am seeing some issues w.r.t parallel query. > Consider a below case: > create table t1(c1 int, c2 char(1000)); > insert into t1 values(generate_series(1,30),''); > analyze t1; > set max_parallel_degree=2; >

Re: [HACKERS] Pushing down sorted joins

On Wed, Mar 9, 2016 at 2:23 AM, Ashutosh Bapat wrote: > [ new patch ] This looks OK to me. Committed! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Crash with old Windows on new CPU

On Wed, Mar 9, 2016 at 4:36 PM, Christian Ullrich wrote: > * Magnus Hagander wrote: > > On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich >> wrote: >> > > On February 13, 2016 4:10:34 PM Tom Lane wrote: >>> >> > I'm also

Re: [HACKERS] Crash with old Windows on new CPU

* Magnus Hagander wrote: On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich wrote: On February 13, 2016 4:10:34 PM Tom Lane wrote: I'm also suspicious of the "#if _MSC_VER == 1800" tests, that is, the code compiles on *exactly one* MSVC version.

Re: [HACKERS] the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1

On March 9, 2016 4:26:01 AM PST, Craig Ringer wrote: >On 9 March 2016 at 18:13, 李海龙 wrote: > >> >> >> HI, pgsql-hackers >> >> The include-timestamp data returned by >pg_logical_slot_peek_changes() is >> always 2000-01-01 in 9.5.1, is it not normal？

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

Aleksander Alekseev wrote: > pg_receivexlog: could not send replication command "START_REPLICATION": > out of memory pg_receivexlog: disconnected; waiting 5 seconds to try > again pg_receivexlog: starting log streaming at 0/100 (timeline 1) > > Breakpoint 1, getCopyStart (conn=0x610180,

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

Tomas Vondra wrote: > FWIW while looking at the code I noticed that we skip wide varlena > values but not cstrings. Seems a bit suspicious. Uh, can you actually have columns of cstring type? I don't think you can ... -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Crash with old Windows on new CPU

On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich wrote: > On February 13, 2016 4:10:34 PM Tom Lane wrote: > > > Christian Ullrich writes: > >> * Robert Haas wrote: > >>> Thanks for the report and patch. Regrettably I haven't

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

Hello, Michael Thanks a lot for steps to reproduce you provided. I tested your path on Ubuntu Linux 14.04 LTS (GCC 4.8.4) and FreeBSD 10.2 RELEASE (Clang 3.4.1). In both cases patch applies cleanly, there are no warnings during compilation and all regression tests pass. A few files are not

[HACKERS] Alter or rename enum value

Hi! Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I had a bit of a discussion on the IRC channel and it seems it shouldn't be that hard to implement this. Again, I am talking about renaming the values, not the enum itself. Thanks!

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

Hi All, Explain [Analyze] Select Into table. produces the plan which uses parallel scans. *Test:* create table table1 (n int); insert into table1 values (generate_series(1,500)); analyze table1; set parallel_tuple_cost=0; set max_parallel_degree=3; postgres=# explain select into

  1   2   >