> > While looking it at I found a bug. It returns the second column
> > in wrong order when both of the distance functions return recheck = true.
> > Test script attached to run on the regression database. I tried to
> > fix but could not. searchTreeItemDistanceRecheck function is not
> > very e
> I managed to break it again by ordering rows only by the second column
> of the index. Test script attached.
I was confused. It is undefined behavior. Sorry for the noise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Over here ->
http://www.postgresql.org/message-id/caaphdvqd99i2eesy6phueo8cmkkudhenzsa-edamswszhu2...@mail.gmail.com
I posted a patch to add support for removing SEMI and ANTI joins, where the
join could be proved useless by the existence of a foreign key.
The patch was part of my incremental work
On Wed, Sep 17, 2014 at 12:30 PM, Emre Hasegeli wrote:
> > I managed to break it again by ordering rows only by the second column
> > of the index. Test script attached.
>
> I was confused. It is undefined behavior. Sorry for the noise.
>
No problem. Thanks a lot for testing.
--
With bes
Hi,
At Thu, 11 Sep 2014 08:10:54 -0400, Robert Haas wrote
in
> On Wed, Sep 10, 2014 at 4:54 AM, Kyotaro HORIGUCHI
> wrote:
> > Finally I think that we need case-insensitive version of
> > get_role_id and() get_database_id() to acoomplish this patch'es
> > objective. (This runs full-scans on pg
Sorry for the mistake...
At Wed, 10 Sep 2014 18:53:03 +0300, Heikki Linnakangas
wrote in <541073df.70...@vmware.com>
> Wrong thread...
>
> On 09/10/2014 03:04 AM, Kyotaro HORIGUCHI wrote:
> > Hmm. Sorry, I misunderstood the specification.
> >
> >> You approach that coloring tokens seems right,
I've been looking into improving the performance of queries that have
co-related sub-queries, such as:
SELECT id,(SELECT value FROM t2 WHERE t2.id = t1.id) FROM t1;
Where currently we produce a plan that executes the subquery as a sub plan,
like:
On 14 August 2014 20:27, Robert Haas wrote:
> On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> I'd like to propose to add new option "--immediate" to pg_ctl promote.
>>> When this option is set, recovery ignores any WAL data which have not
>>> been replayed yet and ex
On 13 August 2014 11:42, Fujii Masao wrote:
> I'd propose the attached WIP patch which allows us to enable WAL archiving
> even in standby. The patch adds "always" as the valid value of archive_mode.
> If it's set to "always", the archiver is started when the server is in standby
> mode and all t
Hi,
On 2014-09-10 14:53:07 -0400, Robert Haas wrote:
> As discussed on the thread "Spinlocks and compiler/memory barriers",
> now that we've made the spinlock primitives function as compiler
> barriers (we think), it should be possible to remove volatile
> qualifiers from many places in the source
Hi all
Attached is a patch to switch 9.5 over to using the
GetSystemTimeAsFileTime call instead of separate GetSystemTime and
SystemTimeToFileTime calls.
This patch the first step in improving PostgreSQL's support for Windows
high(er) resolution time.
In addition to requiring one less call into
On Tue, Sep 16, 2014 at 02:57:00PM -0700, Peter Geoghegan wrote:
> On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut wrote:
> > Clearly, this is worth documenting, but I don't think we can completely
> > prevent the problem. There has been talk of a built-in index integrity
> > checking tool. Th
Here is where I think the timezone and PostGIS cases are fundamentally
different:
I can pretty easily make sure that all my servers run in the same timezone.
That's just good practice. I'm also going to install the same version of
PostGIS everywhere in a cluster. I'll build PostGIS and its de
On Wed, Sep 17, 2014 at 9:07 AM, Matthew Kelly wrote:
> Here is where I think the timezone and PostGIS cases are fundamentally
> different:
> I can pretty easily make sure that all my servers run in the same timezone.
> That's just good practice. I'm also going to install the same version of
Let me double check that assertion before we go too far with it.
Most of the problems I've seen are across 5 and 6 boundaries. I thought I had
case where it was within a minor release but I can't find it right now. I'm
going to dig.
That being said the sort order changes whether you staticall
On Tue, Sep 16, 2014 at 11:41 PM, Peter Geoghegan wrote:
> The timezone case you highlight here seems quite distinct from what
> Matthew is talking about, because in point of fact the on-disk
> representation is merely *interpreted* with reference to the timezone
> database. So, you could have an
Why don't we have our collation data? It seems MySQL has already done this.
http://dev.mysql.com/doc/refman/5.0/en/charset-collation-implementations.html
I don't think we cannot achieve that because even MySQL accomplishes:-)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.
On Wed, Sep 17, 2014 at 3:47 PM, Tatsuo Ishii wrote:
> I don't think we cannot achieve that because even MySQL accomplishes:-)
We've always considered it an advantage that we're consistent with the
collations in the rest of the system. Generally speaking the fact that
Postgres integrates with the
El 16/09/14 16:52, Szymon Guz escribió:
> Hi,
> I've been working a little bit on a patch for printing tables in
> asciidoc with psql.
>
> It's not finished yet, I'm not sure it there is any sense in
> supporting border types etc. The code is not cleared so far, but any
> remarks on the style not
On 09/17/2014 08:27 AM, Craig Ringer wrote:
Hi all
Attached is a patch to switch 9.5 over to using the
GetSystemTimeAsFileTime call instead of separate GetSystemTime and
SystemTimeToFileTime calls.
This patch the first step in improving PostgreSQL's support for Windows
high(er) resolution time
2014-09-16 21:52 GMT+02:00 Szymon Guz :
> Hi,
> I've been working a little bit on a patch for printing tables in asciidoc
> with psql.
>
> It's not finished yet, I'm not sure it there is any sense in supporting
> border types etc. The code is not cleared so far, but any remarks on the
> style not
On 04/07/2014 10:26 AM, Andres Freund wrote:
On 2014-04-05 11:05:09 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-02-27 19:14:13 -0500, Tom Lane wrote:
I looked at the postmaster log for the ongoing issue on narwhal
(to wit, that the contrib/dblink test dies the moment it tries
to do
On Wed, Sep 17, 2014 at 2:00 PM, David Rowley wrote:
> Anyway... I've been thinking of writing some code that converts these sub
> plans into left joins where it can be proved that the subquery would only at
> most produce 1 row
> Does anyone have any thoughts on this?
+1, I've thought about thi
Andrew Dunstan writes:
> On 09/17/2014 08:27 AM, Craig Ringer wrote:
>> Attached is a patch to switch 9.5 over to using the
>> GetSystemTimeAsFileTime call instead of separate GetSystemTime and
>> SystemTimeToFileTime calls.
> That will presumably breaK XP. I know XP has been declared at EOL, but
On 2014-09-17 11:19:36 -0400, Andrew Dunstan wrote:
>
> On 09/17/2014 08:27 AM, Craig Ringer wrote:
> >Hi all
> >
> >Attached is a patch to switch 9.5 over to using the
> >GetSystemTimeAsFileTime call instead of separate GetSystemTime and
> >SystemTimeToFileTime calls.
> >
> >This patch the first
On 09/17/2014 12:51 PM, Andres Freund wrote:
On 2014-09-17 11:19:36 -0400, Andrew Dunstan wrote:
On 09/17/2014 08:27 AM, Craig Ringer wrote:
Hi all
Attached is a patch to switch 9.5 over to using the
GetSystemTimeAsFileTime call instead of separate GetSystemTime and
SystemTimeToFileTime calls
On 9/16/14 3:52 PM, Szymon Guz wrote:
> It's not finished yet, I'm not sure it there is any sense in supporting
> border types etc.
AFAICT, Asciidoc doesn't support border types, so (if so) you should
just ignore that setting.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 2014-09-17 09:38:59 -0700, Tom Lane wrote:
> On the Unix side, I know exactly what would happen to a
> patch proposing that we replace gettimeofday() with clock_gettime()
> with no thought for backwards compatibility.
Btw, do you plan to pursue clock_gettime()? It'd be really neat to have
it...
On 17 September 2014 19:30, Peter Eisentraut wrote:
> On 9/16/14 3:52 PM, Szymon Guz wrote:
> > It's not finished yet, I'm not sure it there is any sense in supporting
> > border types etc.
>
> AFAICT, Asciidoc doesn't support border types, so (if so) you should
> just ignore that setting.
>
Too
On Wed, Sep 17, 2014 at 6:17 AM, Robert Haas wrote:
> What I find astonishing is that whoever maintains glibc (or the Red
> Hat packaging for it) thinks it's OK to change the collation order in
> a minor release. I'd understand changing it between, say, RHEL 6 and
> RHEL 7. But the idea that min
On 9/17/14 10:47 AM, Tatsuo Ishii wrote:
> Why don't we have our collation data? It seems MySQL has already done this.
Where would you get the source data from? How would you maintain it?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 9/16/14 5:57 PM, Peter Geoghegan wrote:
> On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut wrote:
>> Clearly, this is worth documenting, but I don't think we can completely
>> prevent the problem. There has been talk of a built-in index integrity
>> checking tool. That would be quite useful.
On Wed, Sep 17, 2014 at 01:07:56PM +, Matthew Kelly wrote:
> I'm with Martjin here, lets go ICU, if only because it moves sorting
> to a user level library, instead of a system level. Martjin do you
> have a link to the out of tree patch? If not I'll find it. I'd like
> to apply it to a bran
On 9/17/14 9:07 AM, Matthew Kelly wrote:
> Here is where I think the timezone and PostGIS cases are fundamentally
> different:
> I can pretty easily make sure that all my servers run in the same timezone.
> That's just good practice. I'm also going to install the same version of
> PostGIS ever
On Wed, Sep 17, 2014 at 11:05 AM, Peter Eisentraut wrote:
>> We could at least use the GNU facility for versioning collations where
>> available, LC_IDENTIFICATION [1].
>
> It looks like the revisions or dates reported by LC_IDENTIFICATION
> aren't ever updated for most locales.
That's not surpr
On 9/17/14 10:46 AM, Greg Stark wrote:
> You could have a problem if you have an expression index on (timestamp
> AT TIME ZONE '...'). I may have the expression slightly wrong but I
> believe it is posisble to write an immutable expression that depends
> on the tzdata data as long as it doesn't dep
On 9/17/14 2:07 PM, Peter Geoghegan wrote:
> On Wed, Sep 17, 2014 at 11:05 AM, Peter Eisentraut wrote:
>>> We could at least use the GNU facility for versioning collations where
>>> available, LC_IDENTIFICATION [1].
>>
>> It looks like the revisions or dates reported by LC_IDENTIFICATION
>> aren't
On Wed, Sep 17, 2014 at 11:08 AM, Peter Eisentraut wrote:
> I also wrote PostGIS dependent libraries, not PostGIS itself. If you
> are comparing RHEL 5 and 6, as you wrote elsewhere, then some of those
> will most likely be different. (Heck, glibc could be different. Is
> glibc never allowed to
Andres Freund writes:
> On 2014-09-17 09:38:59 -0700, Tom Lane wrote:
>> On the Unix side, I know exactly what would happen to a
>> patch proposing that we replace gettimeofday() with clock_gettime()
>> with no thought for backwards compatibility.
> Btw, do you plan to pursue clock_gettime()? It'
El 15/09/14 18:13, Simon Riggs escribió:
> On 15 September 2014 17:09, Robert Haas wrote:
>
>> Do we really want to disable HOT for all catalog scans?
> The intention of the patch is that catalog scans are treated
> identically to non-catalog scans. The idea here is that HOT cleanup
> only occurs
On 9/16/14 12:01 AM, Alvaro Herrera wrote:
> Jan Wieck wrote:
>> I think that most data integrity issues can be handled by a well
>> designed database schema that uses UNIQUE, NOT NULL, REFERENCES and
>> CHECK constraints. Assertions are usually found inside of complex
>> code constructs to check v
On 9/14/14 2:49 PM, Jan Wieck wrote:
> I don't think it is even a good idea to implement assertions that can
> query arbitrary data.
In a normal programming language, an assertion is usually a static fault
in your program. If the assertion ever fails, you fix your program and
then it hopefully ne
On 9/17/14, 9:00 PM, Peter Eisentraut wrote:
On 9/14/14 2:49 PM, Jan Wieck wrote:
I don't think it is even a good idea to implement assertions that can
query arbitrary data.
In a normal programming language, an assertion is usually a static fault
in your program. If the assertion ever fails,
2014-09-17 21:00 GMT+02:00 Peter Eisentraut :
> On 9/14/14 2:49 PM, Jan Wieck wrote:
> > I don't think it is even a good idea to implement assertions that can
> > query arbitrary data.
>
> In a normal programming language, an assertion is usually a static fault
> in your program. If the assertion
On 17 September 2014 19:55, Szymon Guz wrote:
>
>
> On 17 September 2014 19:30, Peter Eisentraut wrote:
>
>> On 9/16/14 3:52 PM, Szymon Guz wrote:
>> > It's not finished yet, I'm not sure it there is any sense in supporting
>> > border types etc.
>>
>> AFAICT, Asciidoc doesn't support border typ
On 9/17/14 3:04 PM, Pavel Stehule wrote:
> What is difference between content of variable or content of database?
> You can test any prerequisite, but when this prerequisite is not solved,
> than exception is very very hard without possible handling.
If the assertion tests arbitrary Boolean expres
On 15 September 2014 22:13, Simon Riggs wrote:
> On 15 September 2014 17:09, Robert Haas wrote:
>
>> Do we really want to disable HOT for all catalog scans?
>
> The intention of the patch is that catalog scans are treated
> identically to non-catalog scans. The idea here is that HOT cleanup
> onl
2014-09-17 21:36 GMT+02:00 Peter Eisentraut :
> On 9/17/14 3:04 PM, Pavel Stehule wrote:
> > What is difference between content of variable or content of database?
> > You can test any prerequisite, but when this prerequisite is not solved,
> > than exception is very very hard without possible han
On 09/16/2014 10:09 AM, Heikki Linnakangas wrote:
> On 09/16/2014 10:57 AM, Craig Ringer wrote:
>> On 09/16/2014 03:15 PM, Pavel Stehule wrote:
>>
>>> Why we don't introduce a temporary functions instead?
>>
>> I think that'd be a lot cleaner and simpler. It's something I've
>> frequently wanted, a
2014-09-17 22:07 GMT+02:00 Vik Fearing :
> On 09/16/2014 10:09 AM, Heikki Linnakangas wrote:
> > On 09/16/2014 10:57 AM, Craig Ringer wrote:
> >> On 09/16/2014 03:15 PM, Pavel Stehule wrote:
> >>
> >>> Why we don't introduce a temporary functions instead?
> >>
> >> I think that'd be a lot cleaner
On Wed, Sep 17, 2014 at 7:46 AM, Greg Stark wrote:
> You could have a problem if you have an expression index on (timestamp
> AT TIME ZONE '...'). I may have the expression slightly wrong but I
> believe it is posisble to write an immutable expression that depends
> on the tzdata data as long as i
On Fri, Sep 12, 2014 at 9:41 PM, Andrew Gierth
wrote:
> gsp1.patch - phase 1 code patch (full syntax, limited functionality)
> gsp2.patch - phase 2 code patch (adds full functionality using the
> new chained aggregate mechanism)
I gave these a try by convertin
> On 9/17/14 10:47 AM, Tatsuo Ishii wrote:
>> Why don't we have our collation data? It seems MySQL has already done this.
>
> Where would you get the source data from? How would you maintain it?
Don't know. However seeing that that MySQL manages it, it should be
possible for us.
Best regards,
-
> > >> Why does it need to know that? I don't see that it's doing
> > >> anything that requires knowing the size of that node, and if it is,
> > >> I think it shouldn't be. That should get delegated to the callback
> > >> provided by the custom plan provider.
> > >>
> > > Sorry, my explanation mi
> On Wed, Sep 17, 2014 at 3:47 PM, Tatsuo Ishii wrote:
>> I don't think we cannot achieve that because even MySQL accomplishes:-)
>
> We've always considered it an advantage that we're consistent with the
> collations in the rest of the system. Generally speaking the fact that
> Postgres integrat
On Wed, Sep 17, 2014 at 10:06 AM, Matthew Kelly wrote:
> Let me double check that assertion before we go too far with it.
>
> Most of the problems I've seen are across 5 and 6 boundaries. I thought I
> had case where it was within a minor release but I can't find it right now.
> I'm going to d
On 09/17/2014 03:02 PM, Marti Raudsepp wrote:
> So instead of:
> GroupAggregate
>Output: four, ten, hundred, count(*)
>Grouping Sets: (onek.four, onek.ten, onek.hundred), (onek.four,
> onek.ten), (onek.four), ()
>
> Perhaps print:
>Grouping Sets: (onek.four, onek.ten, onek.hundred)
>
On Wed, Sep 17, 2014 at 7:23 AM, Simon Riggs wrote:
> On 14 August 2014 20:27, Robert Haas wrote:
>> On Thu, Aug 14, 2014 at 10:12 AM, Tom Lane wrote:
>>> Fujii Masao writes:
I'd like to propose to add new option "--immediate" to pg_ctl promote.
When this option is set, recovery ignor
On Wed, Sep 17, 2014 at 5:16 PM, Robert Haas wrote:
> Of course, there's also the question of whether ICU would have similar
> issues. You're assuming that they *don't* whack the collation order
> around in minor releases, or at least that they do so to some lesser
> degree than glibc, but is tha
On 09/17/2014 03:36 PM, Peter Eisentraut wrote:
On 9/17/14 3:04 PM, Pavel Stehule wrote:
What is difference between content of variable or content of database?
You can test any prerequisite, but when this prerequisite is not solved,
than exception is very very hard without possible handling.
I
On 09/17/2014 11:19 PM, Andrew Dunstan wrote:
>
> On 09/17/2014 08:27 AM, Craig Ringer wrote:
>> Hi all
>> On Windows 2012 and Windows 8 I'd like to use the new
>> GetSystemTimePreciseAsFileTime call instead. As this requires some extra
>> hoop-jumping to safely and efficiently use it without brea
On 09/18/2014 12:58 AM, Andrew Dunstan wrote:
>
> Oh, hmm, yes, you're right. For some reason I was thinking W2K was later
> than XP. I get more random memory errors as I get older ...
It's because people say Win2k3 / Win2k8 / Win2k8r2 / Win2k12 a lot as
shorthand for Windows Server 2003 (XP-base
Hi all
In the wire protocol, currently if you get an error from the server
before you know it's processed your startup packet successfully you
don't know what character encoding that error is in.
If the error came from the postmaster then it's in the system's default
encoding or whatever locale t
We use ICU with postgres for many years in our mchar extension, which
provides case-insensitive text data type for popular russian financial
system. I don't know if we may ask ICU to give us special BSD-compatible
license ?
On Wed, Sep 17, 2014 at 9:06 PM, Oleg Bartunov wrote:
> We use ICU with postgres for many years in our mchar extension, which
> provides case-insensitive text data type for popular russian financial
> system. I don't know if we may ask ICU to give us special BSD-compatible
> license ?
I don'
On 09/17/2014 09:17 PM, Robert Haas wrote:
> What I find astonishing is that whoever maintains glibc (or the Red
> Hat packaging for it) thinks it's OK to change the collation order in
> a minor release. I'd understand changing it between, say, RHEL 6 and
> RHEL 7. But the idea that minor release
On Thu, Sep 18, 2014 at 1:09 PM, Peter Geoghegan wrote:
> On Wed, Sep 17, 2014 at 9:06 PM, Oleg Bartunov
> wrote:
> > We use ICU with postgres for many years in our mchar extension, which
> > provides case-insensitive text data type for popular russian financial
> > system. I don't know if
> On Wed, Sep 17, 2014 at 9:06 PM, Oleg Bartunov wrote:
>> We use ICU with postgres for many years in our mchar extension, which
>> provides case-insensitive text data type for popular russian financial
>> system. I don't know if we may ask ICU to give us special BSD-compatible
>> license ?
>
On Wed, Sep 17, 2014 at 9:35 PM, Tatsuo Ishii wrote:
> In my understanding PostgreSQL's manual MUST include the ICU license
> term (this is not a problem). What I am not so sure is, any software
> uses PostgreSQL also MUST include the ICU license or not. If yes, I
> think this is surely a problem
Hi All,
While running some tests on REL9_2_STABLE branch, I saw an assertion
failure in syncrep.c. The stack trace looks like this:
frame #3: 0x0001055a2da9
postgres`ExceptionalCondition(conditionName=0x00010567b8c5,
errorType=0x0001055ff193, fileName=0x00010567b8f4, lineNumber
70 matches
Mail list logo
