Tobias Bussmann writes:
> another typo taken over from commit log:
> s/Tobias Bussman/Tobias Bussmann/
Will fix, thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Am 04.02.2017 um 18:57 schrieb Tom Lane :
> Right now the question is whether individual items are
> correctly/adequately documented.
> Allow statements prepared with PREPARE to be given parallel plans (Amit
> Kapila, Tobias Bussman)
another typo taken over from commit log:
s/Tobias Bussman/Tob
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 stopping to
question it. Will fix, thanks for
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
> https://www.postgresql.org/docs/devel/static
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
https://www.postgresql.org/docs/devel/static/release-9-6-2.html
after guaibasaurus' next buildfarm run
On Fri, Oct 21, 2016 at 4:51 PM, Tom Lane wrote:
> Please review ...
Is somebody going to look at the bugfix for the issue where ON
CONFLICT DO NOTHING is used at higher isolation levels [1]? I think
that it's still possible to get it in.
[1]
https://www.postgresql.org/message-id/cam3swzr6an++h
I have committed draft release notes at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=eacaf6e29fd2a3047aff9738a35a8e9b05e55375
They should be up on the website at
https://www.postgresql.org/docs/devel/static/release-9-6-1.html
as soon as guaibasaurus does its next run (about h
On Thu, Apr 14, 2016 at 4:42 PM, Peter Geoghegan wrote:
> * We should look into using the ucol_nextSortKeyPart() API:
>
> http://userguide.icu-project.org/collation/architecture#TOC-Partial-sort-keys
Another more rich API we could immediately put to good use is the ICU
strcoll() variant that does
On Tue, Mar 29, 2016 at 5:18 AM, Teodor Sigaev wrote:
> It's based on https://people.freebsd.org/~girgen/postgresql-icu/readme.html
> work, and it was migrated to 9.5 with abbrevation keys support.
> Patch in current state is not ready to commit, of course.
Cool.
Some quick observations on this:
On Thu, Mar 31, 2016 at 2:59 PM, Tom Lane wrote:
> Well, too late for 9.5.2 anyway. It still makes sense to correct that
> text for future releases. I'm inclined to wait a little bit though and
> see what other improvements become apparent. For instance, I think the
> point about non-first inde
Peter Geoghegan writes:
> I just noticed that the release notes mention char(n) as affected.
> That's not actually true, because char(n) SortSupport only came in
> 9.6. The Wiki page now shows this, which may be the most important
> place, but ideally we'd fix this in the release notes. I guess it
On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote:
> Probably the most discussion-worthy item is whether we can say
> anything more about the strxfrm mess. Should we make a wiki
> page about that and have the release note item link to it?
I just noticed that the release notes mention char(n) as af
Does include ICU mean that collation handling is identical across platforms?
E.g. a query on Linux involving string comparison would yield the same
result on MacOS and Windows?
Yes, it does and that's the most important issue for us.
Yes, exactly. Attached patch adds support for libi
On Mon, Mar 28, 2016 at 6:08 PM, Robert Haas wrote:
> On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane wrote:
> > I'm also not exactly convinced by your implicit assumption that ICU is
> > bug-free.
>
> Noah spent some time looking at ICU back when he was EnterpriseDB, and
> his conclusion was that I
On Mon, Mar 28, 2016 at 1:36 PM, Thomas Kellerer wrote:
> Oleg Bartunov-2 wrote
> > But still, icu provides us abbreviated keys and collation stability,
>
> Does include ICU mean that collation handling is identical across
> platforms?
> E.g. a query on Linux involving string comparison would yie
On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane wrote:
> I'm also not exactly convinced by your implicit assumption that ICU is
> bug-free.
Noah spent some time looking at ICU back when he was EnterpriseDB, and
his conclusion was that ICU collations weren't stable across releases,
which is pretty much
Oleg Bartunov writes:
> Should we start thinking about ICU ?
Isn't it still true that ICU fails to meet our minimum requirements?
That would include (a) working with the full Unicode character range
(not only UTF16) and (b) working with non-Unicode encodings. No doubt
we could deal with (b) by i
Oleg Bartunov-2 wrote
> But still, icu provides us abbreviated keys and collation stability,
Does include ICU mean that collation handling is identical across platforms?
E.g. a query on Linux involving string comparison would yield the same
result on MacOS and Windows?
If that is the case I'm al
On Mon, Mar 28, 2016 at 2:06 PM, Peter Geoghegan wrote:
> On Mon, Mar 28, 2016 at 12:55 AM, Oleg Bartunov
> wrote:
> > We'll post the patch.
>
> Cool.
>
> > Teodor made something to get abbreviated keys work as
> > I remember. I should say, that 27x improvement I got on my macbook. I
> will
> >
On Mon, Mar 28, 2016 at 12:55 AM, Oleg Bartunov wrote:
> We'll post the patch.
Cool.
> Teodor made something to get abbreviated keys work as
> I remember. I should say, that 27x improvement I got on my macbook. I will
> check on linux.
I think that Linux will be much faster. The stxfrm() blob
On Mon, Mar 28, 2016 at 1:21 PM, Peter Geoghegan wrote:
> On Mon, Mar 28, 2016 at 12:08 AM, Oleg Bartunov
> wrote:
> > Should we start thinking about ICU ? I compare Postgres with ICU and
> without
> > and found 27x improvement in btree index creation for russian strings.
> This
> > includes eff
On Mon, Mar 28, 2016 at 12:08 AM, Oleg Bartunov wrote:
> Should we start thinking about ICU ? I compare Postgres with ICU and without
> and found 27x improvement in btree index creation for russian strings. This
> includes effect of abbreviated keys and ICU itself. Also, we'll get system
> indepen
On Mar 28, 2016 09:44, "Peter Geoghegan" wrote:
>
> On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote:
> > Probably the most discussion-worthy item is whether we can say
> > anything more about the strxfrm mess. Should we make a wiki
> > page about that and have the release note item link to it?
>
On Sun, Mar 27, 2016 at 8:43 PM, Peter Geoghegan wrote:
> On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote:
> > Probably the most discussion-worthy item is whether we can say
> > anything more about the strxfrm mess. Should we make a wiki
> > page about that and have the release note item link t
On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote:
> Probably the most discussion-worthy item is whether we can say
> anything more about the strxfrm mess. Should we make a wiki
> page about that and have the release note item link to it?
I think that there is an argument against doing so, which i
Jeff Janes writes:
> On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote:
> + Correctly handle wraparound cases in the pg_subtrans
> + startup logic for hot standby (Jeff Janes)
> This applies to all recovery scenarios, whether they are hot standby
> or just plain-old automatic crash recov
On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote:
> I've prepared a first cut at next week's release notes:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=29b6123ecb4113e366325245cec5a5c221dae691
>
> (As usual, I will make the notes for older branches by extracting
> relevant
I've prepared a first cut at next week's release notes:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=29b6123ecb4113e366325245cec5a5c221dae691
(As usual, I will make the notes for older branches by extracting
relevant items from this list, after it's been reviewed.) Please
re
28 matches
Mail list logo
