2016-02-10 19:26 GMT+01:00 Jim Nasby :
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
>
> NEEDS CATVERSION
On 2/10/16, Pavel Stehule wrote:
> Hi Vitaly,
>
> please, can you send your version of this patch, how we talked about it in
> Moscow?
>
> Thank you
>
> Pavel
Hello, Pavel!
Please find attached my version of the patch (it applies cleanly on
top of 64d89a9 which is current master).
It is time to
On 02/10/16 23:55, Tom Lane wrote:
> Yeah, I got that --- what seems squishier is that none of the other C1
> control characters are considered whitespace?
That seems to be exactly the case:
http://www.unicode.org/Public/5.2.0/ucd/PropList.txt
09..0D, 20, 85, and A0 are the only whitespace char
Chapman Flack writes:
> On 02/10/16 17:19, Tom Lane wrote:
>> I also verified that in UTF8-based locales, isspace() thinks that 0x85 and
>> 0xA0, and no other high-bit-set values, are spaces. Not sure exactly why
> Unicode NEXT LINE (NEL) and NO-BREAK SPACE, respectively.
Yeah, I got that --- w
On 02/10/16 17:19, Tom Lane wrote:
> I also verified that in UTF8-based locales, isspace() thinks that 0x85 and
> 0xA0, and no other high-bit-set values, are spaces. Not sure exactly why
Unicode NEXT LINE (NEL) and NO-BREAK SPACE, respectively.
http://unicode.org/standard/reports/tr13/tr13-5.ht
On Wed, Feb 10, 2016 at 1:25 AM, Kouhei Kaigai wrote:
> It is pretty good!
>
> The attached patch (primary one) implements the above idea.
>
> Now ExtensibleNode works as a basis structure of data container,
> regardless of CustomScan and ForeignScan.
> Also, fdw_private and custom_private are de-
On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier
wrote:
>
> On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila
wrote:
> > Okay, but isn't it better that we remove the snapshot taken
> > at checkpoint time in the main branch or till where this code is
> > getting back-patched. Do you see any need of s
Artur Zakirov writes:
> [ tsearch_aff_parse_v1.patch ]
I've pushed this with some corrections --- notably, I did not like the
lack of buffer-overrun prevention, and it did the wrong thing if a line
had more than one trailing space character.
We still need to look at other uses of *scanf(), but
Larry Rosenman writes:
> If you want, file a bug at https://bugs.freebsd.org/bugzilla
Probably not much point; the commit log shows pretty clearly that they
have been thinking about the code's behavior with multibyte characters,
so I assume they've intentionally decided to keep it like this.
On 10 February 2016 at 22:39, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Feb 10, 2016 at 3:13 PM, Tom Lane wrote:
> >> So I propose the attached patch. Any objections? Should this get
> >> back-patched? It's arguably a bug, though surely a minor one, that
> >> the message comes out wh
On 2016-02-10 17:00, Tom Lane wrote:
Larry Rosenman writes:
On 2016-02-10 16:19, Tom Lane wrote:
I looked into the OS X sources, and found that indeed you are right:
*scanf processes the input a byte at a time, and applies isspace() to
each byte separately, even when the locale is such that th
Larry Rosenman writes:
> On 2016-02-10 16:19, Tom Lane wrote:
>> I looked into the OS X sources, and found that indeed you are right:
>> *scanf processes the input a byte at a time, and applies isspace() to
>> each byte separately, even when the locale is such that that's a
>> clearly insane thing
On 2016-02-10 16:19, Tom Lane wrote:
I wrote:
Artur Zakirov writes:
I think this is not a bug. It is a normal behavior. In Mac OS
sscanf()
with the %s format reads the string one character at a time. The size
of
letter 'х' is 2. And sscanf() separate it into two wrong characters.
That arg
I wrote:
> Artur Zakirov writes:
>> I think this is not a bug. It is a normal behavior. In Mac OS sscanf()
>> with the %s format reads the string one character at a time. The size of
>> letter 'Ñ
' is 2. And sscanf() separate it into two wrong characters.
> That argument might be convincing if
Robert Haas writes:
> On Wed, Feb 10, 2016 at 3:13 PM, Tom Lane wrote:
>> So I propose the attached patch. Any objections? Should this get
>> back-patched? It's arguably a bug, though surely a minor one, that
>> the message comes out when it does.
> I would vote against a back-patch. And I k
On Wed, Feb 10, 2016 at 7:21 PM, Tom Lane wrote:
> Oleg Bartunov writes:
> > It looks like there is a very old bug in full text parser (somebody
> > pointed me on it), which appeared after moving tsearch2 into the core.
> The
> > problem is in how full text parser process hyphenated words. Our
On Wed, Feb 10, 2016 at 3:13 PM, Tom Lane wrote:
> In our recent investigations of slow shutdown on some buildfarm members,
> it became clear that "database system is shut down" can get logged many
> seconds before the postmaster actually exits; the main cause of delay
> is that the stats collecto
Hello friends,
For your consideration, here is a new version of GSSAPI encryption
support. For those who prefer, it's also available on my github:
https://github.com/frozencemetery/postgres/commit/c92275b6605d7929cda5551de47a4c60aab7179e
Some thoughts:
- The overall design is different this tim
On Wed, Feb 10, 2016 at 7:45 PM, Mike Rylander wrote:
> On Wed, Feb 10, 2016 at 4:28 AM, Oleg Bartunov
> wrote:
> > It looks like there is a very old bug in full text parser (somebody
> pointed
> > me on it), which appeared after moving tsearch2 into the core. The
> problem
> > is in how full
On Wed, Feb 10, 2016 at 3:00 AM, Rushabh Lathia
wrote:
> Fujita-san, I am attaching update version of the patch, which added
> the documentation update.
>
> Once we finalize this, I feel good with the patch and think that we
> could mark this as ready for committer.
It would be nice to hear from
Hello,
thanks for reviewing the patch!
On 09.02.2016 20:32, Christian Ullrich wrote:
- Are there portability issues/Will it work on Windows/BSD etc.:
No, it will not work correctly on Windows when built with MSVC,
although it may work with MinGW.
+++ postgresql-9.5.0/src/backend/tc
In our recent investigations of slow shutdown on some buildfarm members,
it became clear that "database system is shut down" can get logged many
seconds before the postmaster actually exits; the main cause of delay
is that the stats collector's final data dump can take awhile. This is
pretty confu
2016-02-10 20:25 GMT+01:00 Jim Nasby :
> On 2/10/16 1:17 PM, Pavel Stehule wrote:It is too simple and too like
> workaround :) I can do it this in plpgsql
>
>> extension probably.
>>
>
> I think it's something people will definitely want. If we don't have it,
> then they're going to be using schem
>>
>> The schema variables are private by design. It can be enhanced in
>> future, but now it is out my scope. If you need public access to these
>> variables, you can use a functions. The access to functions can be
>> controlled by a rights. We can introduce a private (schema limited)
>> function
On 2/10/16 1:17 PM, Pavel Stehule wrote:
2016-02-10 20:10 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>:
On 2/10/16 1:04 PM, Pavel Stehule wrote:
BTW, if all that's desired here are session variables for
plpgsql, I
think it makes a lot more sense
2016-02-10 20:10 GMT+01:00 Jim Nasby :
> On 2/10/16 1:04 PM, Pavel Stehule wrote:
>
>>
>> BTW, if all that's desired here are session variables for plpgsql, I
>> think it makes a lot more sense to start with implementing
>> per-function session variables. That's a lot simpler design-wi
On 2/10/16 12:44 PM, Pavel Stehule wrote:
FWIW, I'd think it's better to not break backwards compatibility,
but I'm also far from a python expert. It might well be worth adding
a plpython GUC to control the behavior so that there's a migration
path forward, or maybe do something
On 2/10/16 1:04 PM, Pavel Stehule wrote:
BTW, if all that's desired here are session variables for plpgsql, I
think it makes a lot more sense to start with implementing
per-function session variables. That's a lot simpler design-wise and
is something we should have anyway. You do
On 2/10/16 11:33 AM, Pavel Stehule wrote:
I don't think that really makes sense. I would expect schema
variables to be exposed to a function as variables or attributes,
either in the global namespace for that PL, or as an attribute of
some object (ie the plpy object in plpython).
>> I didn't propose SESSION variables - now there are some workarounds how
>> to anybody can emulate it, so this feature can wait. What we need is
>> safe session variables with limited access. And the border can be
>> defined by schema scope. So the keyword SCHEMA has sense, and it is
>> necessary
On 2/10/16 11:25 AM, Pavel Stehule wrote:
Oh, and I suggest we call them SESSION variables rather than SCHEMA
variables, to reinforce the idea of how long the values in the
variables live. A session variable is in a sense a 1x1 temp table,
whose definition persists across session
On 2/10/16 11:54 AM, Pavel Stehule wrote:
2016-02-09 23:41 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>:
The other big thing you get is public vs private. You can
sorta-kinda-almost simulate that with permissions in simple cases,
but it ultimately falls apart as soon as you w
On Tue, Feb 9, 2016 at 6:35 PM, Kouhei Kaigai wrote:
> Unfortunately, it was not sufficient.
>
> Due to the assumption, the buffer page to be suspended does not exist
> when a backend process issues a series P2P DMA command. (If block would
> be already loaded to the shared buffer, it don't need t
Stephen Frost writes:
> The way permissions on catalog objects are handled isn't discussed at
> all in the documentation. Barring objections, I'll commit and
> back-patch the attached to improve that situation in the next day or so.
I have no objection to the goal, but I do not think this wordin
Hi
>
>> Actually I imagine that if there's no agreement between author and first
>> reviewer, there might not *be* a committer in the first place. Perhaps
>> try to get someone else to think about it and make a decision. It is
>> possible that some other committer is able to decide by themselv
Greetings,
The way permissions on catalog objects are handled isn't discussed at
all in the documentation. Barring objections, I'll commit and
back-patch the attached to improve that situation in the next day or so.
Thanks!
Stephen
From ad8e663893ea906238a9c0346bf8791eafe3d333 Mon Sep 17 00:00:
On 2/10/16 12:26 PM, Jim Nasby wrote:
I editorialized the docs and some of the comments. In particular, I documented
behavior of not truncating, and recommended casting to name[] if user cares
about that. Added a unit test to verify that works. BTW, I saw mention in the
thread about not trunca
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
NEEDS CATVERSION BUMP
I editorialized the docs and some of the comme
Hi Vitaly,
please, can you send your version of this patch, how we talked about it in
Moscow?
Thank you
Pavel
On 02/10/2016 12:53 PM, Tom Lane wrote:
Andrew Dunstan writes:
Yeah. It's faintly possible that a kernel upgrade will help.
Another data point. I have another RPi2B that is running Debian Wheezy
rather than the Fedora remix. I'm running the same test on it we ran
yesterday on axolotl. It se
Hi
2016-02-09 23:41 GMT+01:00 Jim Nasby :
> On 2/9/16 4:13 PM, Corey Huinker wrote:
>
>>
>> We're not going to get source compatibility without implementing
>> packages, and there's no enthusiasm for that. It's been stated a few
>> times before by some that the only value they see in packages is
Andrew Dunstan writes:
>> Yeah. It's faintly possible that a kernel upgrade will help.
> Another data point. I have another RPi2B that is running Debian Wheezy
> rather than the Fedora remix. I'm running the same test on it we ran
> yesterday on axolotl. It seems to be running without having t
Hi,
PostgresProffesional cluster teams wants to propose new version of
eXtensible Transaction Manager API.
Previous discussion concerning this patch can be found here:
http://www.postgresql.org/message-id/f2766b97-555d-424f-b29f-e0ca0f6d1...@postgrespro.ru
The API patch itself is small enough
Hi, hackers.
Long story short, I'd like to do some refactoring of the code related to
indexes.
I work on patch which provides INCLUDING columns functional [1]. The
patch was reviewed again and again, I fixed many issues, but we still
don't sure enough that all occurrences of /rd_index->indna
On 11 February 2016 at 00:21, Robert Haas wrote:
>
>
> If there's a strong feeling that we should keep the old APIs around,
> we can do that, but I think that (1) if we don't remove them now, we
> probably never will and (2) they are vile APIs.
Yep.
Delete 'em.
Things regularly change between
2016-02-09 23:31 GMT+01:00 Jim Nasby :
> On 2/8/16 10:02 AM, Pavel Stehule wrote:
>
>>
>> I think it would make sense to implement the interface in at least
>> one of our other supported PLs. I'm not entirely clear how well this
>> will match up with, say, plperl, but I'd be interested
2016-02-09 20:55 GMT+01:00 David G. Johnston :
> On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
> wrote:
>
>>
>> Oh, and I suggest we call them SESSION variables rather than SCHEMA
>> variables, to reinforce the idea of how long the values in the variables
>> live. A session variable is in a sens
Hi
Would it make sense to explicitly import variables in function definitions?
>
> CREATE SESSION VARIABLE foo integer;
> CREATE SESSION VARIABLE my_schema.bar text;
> SET SESSION VARIABLE foo to 4;
> SET SESSION VARIABLE my_schema.bar to 'hi mom';
>
> CREATE FUNCTION my_func (p_param text) return
On 10.02.2016 18:51, Teodor Sigaev wrote:
Hmm. Here
src/backend/access/transam/xlog.c read_tablespace_map()
using %s in scanf looks suspisious. I don't fully understand but it
looks like it tries to read oid as string. So, it should be safe in
usial case
Next, _LoadBlobs() reads filename (fname)
On 02/09/2016 11:21 PM, Andrew Dunstan wrote:
The idea I was toying with is that previous filesystem activity (making
the temp install, the server's never-fsync'd writes, etc) has built up a
bunch of dirty kernel buffers, and at some point the kernel goes nuts
writing all that data. So the
Artur Zakirov writes:
> I agree that previous patch is wrong. Instead of using new
> parse_ooaffentry() function maybe better to use sscanf() with %ls
> format. The %ls format is used to read a wide character string.
No, that way is going to give you worse portability problems than what
we have
I duplicate the patch here.
it's very good thing to update disctionaries to support modern versions. And
thank you for improving documentation. Also I've impressed by long description
in spell.c header.
Som notices about code:
1
struct SPELL. Why do you remove union p? You leave comment
On Wed, Feb 10, 2016 at 4:28 AM, Oleg Bartunov wrote:
> It looks like there is a very old bug in full text parser (somebody pointed
> me on it), which appeared after moving tsearch2 into the core. The problem
> is in how full text parser process hyphenated words. Our original idea was
> to repor
Robert Haas writes:
> On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas wrote:
>> (Sorry if this was discussed already, I haven't been paying attention)
>>
>> LWLockAssign() is used by extensions. Are we OK with just breaking them,
>> requiring them to change LWLockAssign() with the new mecha
On Wed, Feb 10, 2016 at 3:24 AM, Aleksander Alekseev
wrote:
>> Basically, the burden for you to impose a new coding rule on everybody
>> who uses shared hash tables in the future is very high.
>
> I fixed an issue you described. Number of spinlocks doesn't depend of
> NUM_LOCK_PARTITIONS anymore a
On 2/10/16 11:12 AM, Andres Freund wrote:
> On 2016-02-10 11:06:01 -0500, David Steele wrote:
>> That makes sense. The backup_label "as is" could be output at the
>> beginning but if we want to add the minimum recovery point it would need
>> to be output at the end.
>>
>> It seems like tablespace_
Oleg Bartunov writes:
> It looks like there is a very old bug in full text parser (somebody
> pointed me on it), which appeared after moving tsearch2 into the core. The
> problem is in how full text parser process hyphenated words. Our original
> idea was to report hyphenated word itself as well
On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas wrote:
> On 10/02/16 17:12, Robert Haas wrote:
>> Code cleanup in the wake of recent LWLock refactoring.
>>
>> As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no
>> longer any way of requesting additional LWLocks in the main tranc
On 2016-02-10 11:06:01 -0500, David Steele wrote:
> That makes sense. The backup_label "as is" could be output at the
> beginning but if we want to add the minimum recovery point it would need
> to be output at the end.
>
> It seems like tablespace_map could still be output at the beginning, thou
On 2/10/16 10:50 AM, Magnus Hagander wrote:
> On Wed, Feb 10, 2016 at 4:38 PM, David Steele
> This information is handy for automating selection of a backup when
> doing time-based PITR (or so the user can manually select). For
> exclusive backups it is possible to parse the .backup f
On 2016-02-09 22:27:07 -0500, Tom Lane wrote:
> The idea I was toying with is that previous filesystem activity (making
> the temp install, the server's never-fsync'd writes, etc) has built up a
> bunch of dirty kernel buffers, and at some point the kernel goes nuts
> writing all that data. So the
On 2/10/16 11:01 AM, Andres Freund wrote:
> On 2016-02-10 16:50:26 +0100, Magnus Hagander wrote:
>>> I would be happy to see the time-stamp returned from the
>>> pg_start_backup() function as well. It's a bigger change, but once
>>> pg_start_backup() returns multiple columns it will be easier to a
On 2016-02-10 16:50:26 +0100, Magnus Hagander wrote:
> > I would be happy to see the time-stamp returned from the
> > pg_start_backup() function as well. It's a bigger change, but once
> > pg_start_backup() returns multiple columns it will be easier to add more
> > columns in the future.
> >
> > I
Noah Misch writes:
>>> That's reasonable. If you would like higher-fidelity data, I can run loops
>>> of
>>> "pg_ctl -w start; make installcheck; pg_ctl -t900 -w stop", and I could run
>>> that for HEAD and 9.2 simultaneously. A day of logs from that should show
>>> clearly if HEAD is systemati
It seems that *scanf() with %s format occures only here:
- check.c - get_bin_version()
- server.c - get_major_server_version()
- filemap.c - isRelDataFile()
- pg_backup_directory.c - _LoadBlobs()
- xlog.c - do_pg_stop_backup()
- mac.c - macaddr_in()
I think here sscanf() do not works with the UTF-
On Wed, Feb 10, 2016 at 4:38 PM, David Steele wrote:
> On 2/10/16 7:46 AM, Magnus Hagander wrote:
> > Per discussion at the developer meeting in Brussels, here's a patch that
> > makes some updates to the backup APIs, to support non-exclusive backups
> > without using pg_basebackup. <...>
>
> Thi
On 02.02.2016 15:45, Artur Zakirov wrote:
On 01.02.2016 20:12, Artur Zakirov wrote:
I have changed the patch:
1 - trgm2.data was corrected, duplicates were deleted.
2 - I have added operators <<-> and <->> with GiST index supporting. A
regression test will pass only with the patch
http://www.po
On 2/10/16 7:46 AM, Magnus Hagander wrote:
> Per discussion at the developer meeting in Brussels, here's a patch that
> makes some updates to the backup APIs, to support non-exclusive backups
> without using pg_basebackup. <...>
This sounds like a great idea and I have signed up to review.
> * A
Hello Michaël,
+ parameter% of the time.
Nitpick: double space here.
Ok.
+ default:
+ return false;
}
In evalFunc(), the default case in switch for the operator functions
should never be reached. Adding for example Assert(0) is so
On Wed, Feb 10, 2016 at 1:32 AM, Amit Kapila wrote:
> The reason for using centralized way is that we need to request
> named tranches before initialization of shared memory and as far as
> I can see, currently there is no way in the subsystems where they can
> issue such a request, so one possibi
* David Steele (da...@pgmasters.net) wrote:
> On 2/10/16 9:44 AM, Stephen Frost wrote:
> > Hrmmm. If that's the case then perhaps you're right. I liked the
> > general idea of not having to maintain a TCP connection during the
> > entire backup (TCP connections can be annoyingly finicky in certai
On 2/10/16 9:44 AM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund wrote:
>>> On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
* If the client disconnects with a non-exclusive backup running, the
>>> backup
is a
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund wrote:
> > On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > > Per discussionat the developer meeting in Brussels, here's a patch that
> > > makes some updates to the backup APIs, to support non-
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > * If the client disconnects with a non-exclusive backup running, the backup
> > is automatically aborted. This is the same thing that pg_basebackup does.
> > To use these non-exclusive backups the
On Tue, Feb 9, 2016 at 5:06 AM, Alvaro Herrera wrote:
> Fabien COELHO wrote:
>>
>> Hello,
>>
>> >>v23 attached, which does not change the message but does the other fixes.
>> >
>> >This doesn't apply anymore
>>
>> Indeed, but the latest version was really v25.
>>
>> >-- please rebase and submit to
On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund wrote:
> Hi,
>
> On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > Per discussionat the developer meeting in Brussels, here's a patch that
> > makes some updates to the backup APIs, to support non-exclusive backups
> > without using pg_basebac
Hi,
On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> Per discussionat the developer meeting in Brussels, here's a patch that
> makes some updates to the backup APIs, to support non-exclusive backups
> without using pg_basebackup.
Thanks for following through with this!
> * If the client di
On 09.02.2016 20:13, Tom Lane wrote:
I do not like this patch much. It is basically "let's stop using sscanf()
because it seems to have a bug on one platform". There are at least two
things wrong with that approach:
1. By my count there are about 80 uses of *scanf() in our code. Are we
going
On 10 February 2016 at 08:00, Rushabh Lathia wrote:
> Fujita-san, I am attaching update version of the patch, which added
> the documentation update.
>
> Once we finalize this, I feel good with the patch and think that we
> could mark this as ready for committer.
I find this wording a bit confusi
On Wed, Feb 10, 2016 at 7:12 AM, Ashutosh Bapat
wrote:
> Here's patch to remove this declaration. The Assert next probably prevents
> the warning for build with asserts. But both those lines are not needed.
I like the Assert(), so I kept that and ditched the variable.
Thanks,
--
Robert Haas
En
On Wed, Feb 10, 2016 at 7:46 AM, Magnus Hagander wrote:
> Per discussionat the developer meeting in Brussels, here's a patch that
> makes some updates to the backup APIs, to support non-exclusive backups
> without using pg_basebackup. The idea is to fix at least three main issues
> that are there
Per discussionat the developer meeting in Brussels, here's a patch that
makes some updates to the backup APIs, to support non-exclusive backups
without using pg_basebackup. The idea is to fix at least three main issues
that are there today -- that you cannot run concurrent backups, that the
backup_
Here's patch to remove this declaration. The Assert next probably prevents
the warning for build with asserts. But both those lines are not needed.
On Wed, Feb 10, 2016 at 12:01 PM, Jeff Janes wrote:
> On Tue, Feb 9, 2016 at 11:16 AM, Robert Haas
> wrote:
> > On Tue, Feb 9, 2016 at 8:39 AM, Ash
On Wed, Feb 10, 2016 at 12:28 PM, Oleg Bartunov wrote:
> It looks like there is a very old bug in full text parser (somebody
> pointed me on it), which appeared after moving tsearch2 into the core. The
> problem is in how full text parser process hyphenated words. Our original
> idea was to rep
On 2016-02-10 10:32:44 +0530, Dilip Kumar wrote:
> On Fri, Feb 5, 2016 at 4:50 PM, Amit Kapila wrote:
>
> > > Could you also measure how this behaves for an INSERT instead of a COPY
> > > workload?
> >
> >
> I think such a test will be useful.
> >
>
> I have measured the performance with insert
On Wed, Feb 10, 2016 at 5:34 PM, Kyotaro HORIGUCHI
wrote:
>
> Hello,
>
> At Wed, 10 Feb 2016 15:22:44 +0900, Michael Paquier
> wrote in
>
> > On Wed, Feb 10, 2016 at 3:13 PM, Michael Paquier
> > wrote:
> > > On Wed, Feb 10, 2016 at 11:25 AM, Masahiko Sawada
> > > wrote:
> > > I am personally
It looks like there is a very old bug in full text parser (somebody
pointed me on it), which appeared after moving tsearch2 into the core. The
problem is in how full text parser process hyphenated words. Our original
idea was to report hyphenated word itself as well as its parts and ignore
hyphen
Hello,
At Wed, 10 Feb 2016 15:22:44 +0900, Michael Paquier
wrote in
> On Wed, Feb 10, 2016 at 3:13 PM, Michael Paquier
> wrote:
> > On Wed, Feb 10, 2016 at 11:25 AM, Masahiko Sawada
> > wrote:
> > I am personally fine with () and [] as you mention, we could even consider
> > {}, each one of t
Hello, Robert
> Basically, the burden for you to impose a new coding rule on everybody
> who uses shared hash tables in the future is very high.
I fixed an issue you described. Number of spinlocks doesn't depend of
NUM_LOCK_PARTITIONS anymore and could be specified for each hash table
on a callin
On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila wrote:
> Okay, but isn't it better that we remove the snapshot taken
> at checkpoint time in the main branch or till where this code is
> getting back-patched. Do you see any need of same after
> having the logging of snapshot in bgwriter?
But this o
On Wed, Feb 10, 2016 at 1:01 PM, Michael Paquier
wrote:
>
>
> On Wed, Feb 10, 2016 at 4:11 PM, Amit Kapila
> wrote:
>
>>
>>
>>
>>>
>>> >> > - last_snapshot_lsn != GetXLogInsertRecPtr())
>>> >> > +
>>> >> > GetLastCheckpointRecPtr() < GetProgressRecPtr())
>>> >> >
>>> >> > How the above check in
Fujita-san, I am attaching update version of the patch, which added
the documentation update.
Once we finalize this, I feel good with the patch and think that we
could mark this as ready for committer.
On Fri, Feb 5, 2016 at 5:33 PM, Rushabh Lathia
wrote:
>
>
> On Fri, Feb 5, 2016 at 4:46 PM, R
92 matches
Mail list logo
