Re: [HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > TBH, I think you are worried about the wrong thing here. You could drop > both of those errdetail calls altogether and be little worse off. In the > places where we have errdetail calls like "failed system call was xxx", > the main point is to show

[HACKERS] [RFC] Should "SHOW huge_pages" display the effective value "off" when the huge page is unavailable?

Hello, all Could you give me your opinions on whether the SHOW command should display the effective value or the specified value for huge_pages? During the review of "Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3, Magnus gave me a comment that the huge_page

Re: [HACKERS] Parallel Append implementation

v2 patch was not rebased over the latest master branch commits. Please refer to the attached ParallelAppend_v3.patch, instead. On 6 February 2017 at 11:06, Amit Khandekar wrote: > Ashutosh Bapat wrote: >>> We may want to think about a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > Hmmm. ISTM that control-c must at least reset the stack, otherwise their > is not easy way to get out. What can be left to another patch is doing a > control-C for contents and then another one for the stack when there is no > content. > And so it shall be. > - put Fabien's tap test in

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

On Mon, Feb 6, 2017 at 1:42 AM, Kouhei Kaigai wrote: > I also had thought an idea to have extra space to Instrumentation structure, > however, it needs to make Instrumentation flexible-length structure according > to the custom format by CSP/FDW. Likely, it is not a good

Re: [HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

"Tsunakawa, Takayuki" writes: > I added a few ereport() calls that emit the same message except for the Win32 > API name. Which of the following do you think is the best? I'd like to > follow the majority. > [Option 1] > ereport(elevel, >

Re: [HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > I find it hard to have an opinion on the matter as a non-translator. > Why not asking translators directly on pgsql-translators? > I didn't think of pgsql-translators. I'll ask

Re: [HACKERS] 0/NULL/NIL assignments in build_*_rel()

On Mon, Feb 6, 2017 at 11:10 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote: >>> I'd vote for not. The general programming style in the backend is to >>> ignore the fact

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Mon, Feb 6, 2017 at 10:06 AM, Ashutosh Sharma wrote: > On Sat, Feb 4, 2017 at 1:12 AM, Robert Haas wrote: >> >> Committed with those changes. > > Thanks for above corrections and commit. But, There are couple of > things that we might have to

Re: [HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

On Mon, Feb 6, 2017 at 2:56 PM, Tsunakawa, Takayuki wrote: > I'm rather inclined to choose Option 1 to reduce message translation work. > Actually, is the Option 3 the best so that it aligns with the existing > messages by putting the error code in the primary

[HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

Hello, all Could you give me your opinions on the message style? Recently, I got different comments from Magnus and Alvaro during the review of "Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3. To be more specific, I'm modifying src/backend/port/win32_shmem.c

Re: [HACKERS] 3D Z-curve spatial index

On Mon, Feb 06, 2017 at 11:04:12AM +0700, Boris Muratshin wrote: > The algorithm for 2D is described in articles (in Russian) > https://habrahabr.ru/post/319810/ and > https://habrahabr.ru/post/319096/ . > Goggle-translator generates (IMHO) suitable for understanding text. Welcome to the

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 9:47 AM, Pavan Deolasee wrote: > > > On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila wrote: >> >> >> >> Hmm. Consider that the first time relcahe invalidation occurs while >> computing id_attrs, so now the retry logic will

Re: [HACKERS] 0/NULL/NIL assignments in build_*_rel()

Ashutosh Bapat writes: > On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote: >> I'd vote for not. The general programming style in the backend is to >> ignore the fact that makeNode() zeroes the node's storage and initialize >> all the fields

Re: [HACKERS] Parallel Append implementation

Ashutosh Bapat wrote: >> We may want to think about a third goal: preventing too many workers >> from executing the same plan. As per comment in get_parallel_divisor() >> we do not see any benefit if more than 4 workers execute the same >> node. So, an append node

Re: [HACKERS] 0/NULL/NIL assignments in build_*_rel()

On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> Both build_simple_rel() and build_join_rel() allocate RelOptInfo using >> makeNode(), which returned a zeroed out memory. The functions then >> assign values like

Re: [HACKERS] 0/NULL/NIL assignments in build_*_rel()

Ashutosh Bapat writes: > Both build_simple_rel() and build_join_rel() allocate RelOptInfo using > makeNode(), which returned a zeroed out memory. The functions then > assign values like false, NULL, 0 or NIL which essentially contain > zero valued bytes. This

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

I think UInt32GetDatum(metad->hashm_procid) looks fine, the reason being 'hashm_procid' is defined as 32-bit unsigned integer but then we may have to define procid as int8 in SQL function. >>> >>> No, you're wrong. The GetDatum you choose macro has to match the SQL >>> type, not

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Sun, Feb 5, 2017 at 5:04 AM, Fujii Masao wrote: > With this patch, when normal users type TAB after SUBSCRIPTION, > they got "permission denied" error. I don't think that's acceptable. Right, I can see that now. pg_stat_get_subscription() does not offer as well a way to

[HACKERS] 0/NULL/NIL assignments in build_*_rel()

Hi, Both build_simple_rel() and build_join_rel() allocate RelOptInfo using makeNode(), which returned a zeroed out memory. The functions then assign values like false, NULL, 0 or NIL which essentially contain zero valued bytes. This looks like needless work. So, we are spending some CPU cycles

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Claudio Freire > Sent: Monday, February 06, 2017 1:05 PM > To: Kaigai Kouhei(海外 浩平) > Cc: Amit Kapila ; Robert Haas >

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Sat, Feb 4, 2017 at 1:12 AM, Robert Haas wrote: > On Wed, Feb 1, 2017 at 10:13 PM, Michael Paquier > wrote: >> On Tue, Jan 24, 2017 at 8:36 PM, Kuntal Ghosh >> wrote: >>> Nothing else to add from my side. I'm

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

On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas wrote: > On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost wrote: >> Daniel, >> >> * Daniel Verite (dan...@manitou-mail.org) wrote: >>> What if we look at the change from the pessimistic angle? >>> An example of

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee wrote: > >> > I like this approach. I'll run the patch on a build with > CACHE_CLOBBER_ALWAYS, but I'm pretty sure it will be ok. > While it looks certain that the fix will miss this point release, FWIW I ran this patch

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila wrote: > > > Hmm. Consider that the first time relcahe invalidation occurs while > computing id_attrs, so now the retry logic will compute the correct > set of attrs (considering two indexes, if we take the example given by >

[HACKERS] IF [NOT] EXISTS for replication slots

Hi all, Lately I have bumped into a case where it would have been useful to make the difference between a failure because of a slot already dropped and an internal failure of Postgres. Is there any interest for support of IE and INE for CREATE and DROP_REPLICATION_SLOT? My use case involved only

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 8:35 AM, Pavan Deolasee wrote: > > > On Mon, Feb 6, 2017 at 8:15 AM, Amit Kapila wrote: >> >> On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee >> wrote: >> > >> > >> > On Mon, Feb 6, 2017 at 1:44

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

On Mon, Feb 6, 2017 at 1:00 AM, Claudio Freire wrote: > On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote: >>> If the use case for this is to gather instrumentation, I'd suggest calling >>> the hook in RetrieveInstrumentation, and calling it

Re: [HACKERS] 3D Z-curve spatial index

The algorithm for 2D is described in articles (in Russian) https://habrahabr.ru/post/319810/ and https://habrahabr.ru/post/319096/ . Goggle-translator generates (IMHO) suitable for understanding text. 3D version article is not finished yet. The data in figures are obtained in the following way:

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote: >> If the use case for this is to gather instrumentation, I'd suggest calling >> the hook in RetrieveInstrumentation, and calling it appropriately. It would >> make the intended use far clearer than it is now. >> >> And if

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On 2017-02-05 22:34:34 -0500, Tom Lane wrote: > Pavan Deolasee writes: > The point is that there's a nontrivial chance of a hasty fix introducing > worse problems than we fix. > > Given the lack of consensus about exactly how to fix this, I'm feeling > like it's a good

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Pavan Deolasee writes: > On Mon, Feb 6, 2017 at 5:44 AM, Andres Freund wrote: >> +1. I don't think we serve our users by putting out a nontrivial bugfix >> hastily. Nor do I think we serve them in this instance by delaying the >> release to cover

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On 2017-02-05 21:49:57 -0500, Tom Lane wrote: > Andres Freund writes: > > I've not yet read the full thread, but I'm a bit confused so far. We > > obviously can get changing information about indexes here, but isn't > > that something we have to deal with anyway? If we

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 5:44 AM, Andres Freund wrote: > On 2017-02-05 12:51:09 -0500, Tom Lane wrote: > > Michael Paquier writes: > > > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule > wrote: > > >> I agree with Pavan - a

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 8:15 AM, Amit Kapila wrote: > On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee > wrote: > > > > > > On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote: > >> > >> > >> > >> > 2. In the second patch, we tried

Re: [HACKERS] Possible spelling fixes

It's now split more or less to your suggestion: https://github.com/jsoref/postgres/commits/spelling diff --git a/configure b/configure --- a/configure +++ b/configure @@ -7088,7 +7088,7 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCR test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' #

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Andres Freund writes: > I've not yet read the full thread, but I'm a bit confused so far. We > obviously can get changing information about indexes here, but isn't > that something we have to deal with anyway? If we guarantee that we > don't loose knowledge that there's a

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On 2017-02-06 08:08:01 +0530, Amit Kapila wrote: > I don't see in your patch that you are setting rd_bitmapsvalid to 0. IIRC a plain relcache rebuild should do that (note there's also no place that directly resets rd_indexattrs). > Also, I think this suffers from the same problem as the patch

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Sun, Feb 5, 2017 at 6:42 PM, Pavan Deolasee wrote: > I'm not sure that just because the bug wasn't reported by a user, makes it > any less critical. As Tomas pointed down thread, the nature of the bug is > such that the users may not discover it very easily, but that

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee wrote: > > > On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote: >> >> >> >> > 2. In the second patch, we tried to recompute attribute lists if a >> > relcache >> > flush happens in between and index list is

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 5:41 AM, Peter Geoghegan wrote: > On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote: > > I don't think this kind of black-and-white thinking is very helpful. > > Obviously, data corruption is bad. However, this bug has (from what > >

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 6:27 AM, Andres Freund wrote: > Hi, > > On 2017-02-05 16:37:33 -0800, Andres Freund wrote: >> > RelationGetIndexList(Relation relation) >> > @@ -4746,8 +4747,10 @@ RelationGetIndexPredicate(Relation relat >> > * we can include system attributes (e.g.,

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote: > > > > 2. In the second patch, we tried to recompute attribute lists if a > relcache > > flush happens in between and index list is invalidated. We've seen > problems > > with that, especially it getting into an infinite loop

Re: [HACKERS] Possible spelling fixes

Hi, On 2017-02-05 21:05:50 -0500, Josh Soref wrote: > Could someone please review the changes I have [3] and suggest a > series of commits that this project might like? I think the current split seem excessive... I'd suggest splitting things first into: - straight up spelling/typo fixes in

[HACKERS] Possible spelling fixes

Hi. I'm going through project-by-project offering spelling fixes. I have read your submission suggestions [1][2] and am choosing to disregard them. Could someone please review the changes I have [3] and suggest a series of commits that this project might like? It is quite likely that someone

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Sun, Feb 5, 2017 at 4:57 PM, Tomas Vondra wrote: > OTOH I disagree with the notion that bugs that are not driven by user > reports are somehow less severe. Some data corruption bugs cause quite > visible breakage - segfaults, immediate crashes, etc. Those are

Re: [HACKERS] libpq Alternate Row Processor

From: Tom Lane [mailto:t...@sss.pgh.pa.us]: > Kyle Gearhart writes: >> The guts of pqRowProcessor in libpq does a good bit of work to maintain the >> internal data structure of a PGresult. There are a few use cases where the >> caller doesn't need the ability to

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

On Wed, Feb 1, 2017 at 6:27 AM, Vitaly Burovoy wrote: > Hello, > > I've reviewed the patch[1]. > > Result of testing: > > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On Fri, Feb 3, 2017 at 8:28 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > On 30.12.2016 06:55, Haribabu Kommi wrote: > > > Hi All, > > Fujitsu was interested in developing a columnar storage extension with > minimal > changes the server backend. > > > We in PostgresPRO are also

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Hi, On 2017-02-05 16:37:33 -0800, Andres Freund wrote: > > RelationGetIndexList(Relation relation) > > @@ -4746,8 +4747,10 @@ RelationGetIndexPredicate(Relation relat > > * we can include system attributes (e.g., OID) in the bitmap > > representation. > > * > > * Caller had better hold at

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On 02/06/2017 01:11 AM, Peter Geoghegan wrote: On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote: I don't think this kind of black-and-white thinking is very helpful. Obviously, data corruption is bad. However, this bug has (from what one can tell from this thread) been

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On 2017-02-05 15:14:59 -0500, Tom Lane wrote: > I do not like any of the other patches proposed in this thread, because > they fail to guarantee delivering an up-to-date attribute bitmap to the > caller. I think we need a retry loop, and I think that it needs to look > like the attached. That

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Claudio Freire > Sent: Saturday, February 04, 2017 8:47 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Amit Kapila ; Robert Haas >

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On 2017-02-05 12:51:09 -0500, Tom Lane wrote: > Michael Paquier writes: > > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule > > wrote: > >> I agree with Pavan - a release with known important bug is not good idea. > > > This bug has been around

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote: > I don't think this kind of black-and-white thinking is very helpful. > Obviously, data corruption is bad. However, this bug has (from what > one can tell from this thread) been with us for over a decade; it must >

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Sun, Feb 5, 2017 at 1:34 PM, Martín Marqués wrote: > El 05/02/17 a las 10:03, Michael Paquier escribió: >> On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule >> wrote: >>> I agree with Pavan - a release with known important bug is not good idea. >>

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 9:14 PM, Ashutosh Sharma wrote: > On Fri, Feb 3, 2017 at 8:29 PM, Robert Haas wrote: >> On Fri, Feb 3, 2017 at 7:41 AM, Ashutosh Sharma >> wrote: >>> I think UInt32GetDatum(metad->hashm_procid) looks

Re: [HACKERS] 3D Z-curve spatial index

On Sat, Feb 04, 2017 at 03:41:29PM +0700, Boris Muratshin wrote: > Hi hackers, > > The low-level implementation of 3D Z-curve index > (https://github.com/bmuratshin/zcurve/tree/master) > is getting close to GiST R-Tree performance at > significantly lesser number of pages read from disk. > > See

Re: [HACKERS] [PATCH] SortSupport for macaddr type

Hi Julien, Thank you for taking the time to do this review, and my apologies for the very delayed response. I lost track of this work and have only jumped back into it today. Please find attached a new version of the patch with your feedback integrated. I've also rebased the patch against the

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

[ Having now read the whole thread, I'm prepared to weigh in ... ] Pavan Deolasee writes: > This seems like a real problem to me. I don't know what the consequences > are, but definitely having various attribute lists to have different view > of the set of indexes

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

On Sun, Feb 05, 2017 at 01:48:09PM -0500, Tom Lane wrote: > Noah Misch writes: > > On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote: > >> Is there any likely use-case for providing separate control flags for the > >> two permission checks? That would require an API

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

Noah Misch writes: > On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote: >> Is there any likely use-case for providing separate control flags for the >> two permission checks? That would require an API change for DefineIndex, >> making this considerably more invasive, so

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote: > Noah Misch writes: > > DefineIndex() has a check_rights argument that determines whether to > > perform a > > namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets > > that flag. The theory

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

El 05/02/17 a las 10:03, Michael Paquier escribió: > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule wrote: >> I agree with Pavan - a release with known important bug is not good idea. > > This bug has been around for some time, so I would recommend taking > the time

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

2017-02-05 18:51 GMT+01:00 Tom Lane : > Michael Paquier writes: > > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule > wrote: > >> I agree with Pavan - a release with known important bug is not good > idea. > > > This bug has

Re: [HACKERS] Draft release notes for next week's releases are up for review

Amit Kapila writes: > On Sat, Feb 4, 2017 at 11:27 PM, Tom Lane wrote: >> Fix possible miss of socket read events while waiting on Windows (Amit >> Kapial) > Typo > Amit Kapial/Amit Kapila Wups. Copied-and-pasted that from the commit log without

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Michael Paquier writes: > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule wrote: >> I agree with Pavan - a release with known important bug is not good idea. > This bug has been around for some time, so I would recommend taking > the time

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

Noah Misch writes: > DefineIndex() has a check_rights argument that determines whether to perform a > namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets > that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere > implementation

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

Hi, Jeff! 2017-02-05 3:45 GMT+05:00 Jeff Davis : > On Sun, Jan 22, 2017 at 10:32 PM, Jeff Davis wrote: >> On Sat, Jan 21, 2017 at 4:25 AM, Andrew Borodin wrote: >> One idea I had that might be simpler is to use a two-stage page >>

Re: [HACKERS] Parallel bitmap heap scan

On Wed, Feb 1, 2017 at 11:09 PM, Robert Haas wrote: Here are the latest version of the patch, which address all the comments given by Robert. > https://www.postgresql.org/message-id/20161017201558.cr34stc6zvxy3...@alap3.anarazel.de > that you should try to share only the

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule wrote: > I agree with Pavan - a release with known important bug is not good idea. This bug has been around for some time, so I would recommend taking the time necessary to make the best fix possible, even if it means waiting

Re: [HACKERS] Draft release notes for next week's releases are up for review

On Sat, Feb 4, 2017 at 11:27 PM, Tom Lane wrote: > First-draft release notes are available at > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9863017b87f3592ff663d03fc663a4f1f8fdb8b2 > They should appear in a more readable form at >

Re: [HACKERS] [PATCH] Generic type subscription

On 24 January 2017 at 02:36, Tom Lane wrote: > It might be possible to get away with having only one pg_type column, > pointing at the parse-analysis function. That function would generate > a SubscriptingRef tree node containing the OID of the appropriate > execution

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

2017-02-05 7:54 GMT+01:00 Pavan Deolasee : > > On Sat, Feb 4, 2017 at 11:54 PM, Tom Lane wrote: > >> >> Based on Pavan's comments, I think trying to force this into next week's >> releases would be extremely unwise. If the bug went undetected this