gesendet
> Am 10.11.2016 um 01:26 schrieb Craig Ringer :
>
> On 8 Nov. 2016 15:11, "Craig Ringer" wrote:
> >
> >
> >
> > On 7 November 2016 at 05:08, Stefan Scheid wrote:
> >>
> >> Hi all,
> >>
> >> are there plans to in
Hi all,
are there plans to introduce temporal tables?
best,
Stefan
Weitergeleitete Nachricht
Betreff:Re: [CORE] temporal tables (SQL2011)
Datum: Fri, 4 Nov 2016 10:27:40 -0400
Von:Peter Eisentraut
An: Stefan Scheid
Kopie (CC): pgsql-c
iled to fix the issue completely...
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/18/2016 09:52 PM, Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>> On 08/18/2016 09:30 PM, Christian Convey wrote:
>
>>> Yury: Would it make sense to add a call to "cmake_minimum_required" in
>>> one or more of your CMakeLists.txt files?
>
posed
for a commit should be able to build using the new system with whatever
cmake version is available in those by default (if it is at all).
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e to add a call to "cmake_minimum_required" in
> one or more of your CMakeLists.txt files?
it would make sense nevertheless but I dont think that 2.8.11 is old
enough - looking at the release information and the feature compatibily
matrix it would seems we should more aim a
On 08/18/2016 08:57 PM, Christian Convey wrote:
> Hi Stefan,
>
> I think I've seen similar errors when a project's CMake files assumed
> a newer version of CMake than the one being run.
>
> Which version of CMake gave you those errors? (Sorry if you provided
> t
Target "cmTryCompileExec2628321539" links to item " m" which has
leading or
trailing whitespace. This is now an error according to policy CMP0004.
CMake Error: Internal CMake error, TryCompile generation of cmake failed
which I have no idea whether they are an actual proble
did not follow the implementation
of PostgreSQL.
@Peter B. You know PostgreSQL well. Can you explain?
:Stefan
P.S. 2016-07-02 17:11 GMT+02:00 Tom Lane wrote:
> Peter E. had observer status at one point, don't know if he still does.
@Peter E.: Do you still have observer status a
lso reached stage
> 30.60. Does anyone know what that one is about? Maybe something like
Peter surely would know: https://www.jacobs-university.de/directory/pbaumann
:Stefan
2016-07-04 6:44 GMT+02:00 Thomas Munro :
> On Wed, Jun 29, 2016 at 11:51 AM, Stefan Keller wrote:
>>
On Sat, Jul 02, 2016 at 11:35:52AM -0400, Tom Lane wrote:
> Stefan Huehner writes:
> > re-testing our application Openbravo on 9.6beta2 i found the following
> > query failing to run with
> > ERROR: cache lookup failed for type 0
>
> Hmm, I can't reproduce this
no longer trigger the problem.
Also changing the 'c_orderline' create table statement to not have the last
column 'c_currency_id' (which is not even referenced in the query) also makes
the issue no longer reproducible.
Regards,
Stefan
--
Sent via pgsql-hackers mailing list (pg
Hi,
FYI: I'd just like to point you to following two forthcoming standard
parts from "ISO/IEC JTS 1/SC 32" comittee: one on JSON, and one on
"Multi-Dimensional Arrays" (SQL/MDA).
They define there some things different as already in PG. See also
Peter Baumann's sl
./src/backend/optimizer/path/costsize.c:3961
so probably related to the 'Use Foreign keys to improve joins estimates'
project from Tomas
If you need any more info or testing done just let me know.
Regards,
Stefan
pg9.6-2016-04-29-crash-reproducer.sql
Description: application/sq
On 01/28/2016 05:24 PM, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 10:25 AM, Stefan Kaltenbrunner
> wrote:
>> On 01/28/2016 04:00 PM, Stefan Kaltenbrunner wrote:
>>> Per discussion in the afternoon break at FOSDEM/PGDay 2016 Developer
>>> Meeting we are going to
On 01/28/2016 04:00 PM, Stefan Kaltenbrunner wrote:
> Hi all!
>
> Per discussion in the afternoon break at FOSDEM/PGDay 2016 Developer
> Meeting we are going to upgrade gemulon.postgresql.org aka "gitmaster"
> today (the upgrade was originally scheduled end of last year
s going to start in a few minutes - will send a notice
after it is done.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/26/2015 09:10 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> that seems entirely doable with our current infrastructure (and even
>> with minimal-to-no hackery on mj2) - but it still carries the "changes
>> From:" issue :/
>
> Yeah. What do you
some of the heavy lifting like doing the inbound dkim checking
and "hinting" the downstream ML-boxes with the results) - however the
main mailinglist infrastructure is still mj2 and that is aeons old perl
- still interested in helping with implementation? ;)
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o be the original
> author or the list; as I recall, neither of those are fully satisfactory.
well this is basically what it boils down to - we will absolutely have
to do is replacing "From:" (assuming the gmail rumour is true which I'm
not entirely convinced though) but what are
torn over this splitting resources to implement types like
geometry twice.
:Stefan
2015-10-12 11:24 GMT+02:00 Alexander Korotkov :
> Hi, Stefan!
>
> On Sun, Oct 11, 2015 at 10:00 PM, Stefan Keller wrote:
>>
>> Pls. don't misunderstand my questions: They are directed to get
geometric types?
Would'nt it be even more useful to concentrate to PostGIS
geometry/geography types and extend BRIN to these types?
:Stefan
2015-06-13 23:04 GMT+02:00 Emre Hasegeli :
>> Emre Hasegeli just pointed out to me that this patch introduced
>> box_contain_pt() and
- we can trivially implement that on the mailserver
side by asking the backend database sequence for a bugid and rewriting
the subject...
But given debbugs is on the radar not sure we need it...
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/25/2015 08:53 PM, Andres Freund wrote:
> On 2015-09-25 20:47:21 +0200, Stefan Kaltenbrunner wrote:
>> yeah the point about 9.0.x is a very good one - so I think we will
>> target mid/end of october for borka so we get a bit of time to deal with
>> any fallout from t
On 09/25/2015 08:30 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> * borka.postgresql.org - official tarball and docs build server, the
>> upgrade will upgrade the toolchain on that box to the respective
>> versions of what is in jessie. If people think it is nece
- official tarball and docs build server, the
upgrade will upgrade the toolchain on that box to the respective
versions of what is in jessie. If people think it is necessarily to
(double)check the effects beforehand we would like to know so we can
coordinate some
testing.
Stefan
-BEGIN PGP
form to
allow BZ to "learn" about an issue/bug/thread and keep tracking it
automatically afterwards. You could send it simply commands as part as
the mail or click in the gui (or do nothing at all - though it would
close the bug if it found the bug id in a commit).
Even adding something t
On 09/02/2015 10:10 PM, dinesh kumar wrote:
> On Tue, Sep 1, 2015 at 10:58 PM, Stefan Kaltenbrunner
> mailto:ste...@kaltenbrunner.cc>> wrote:
>
> On 07/25/2015 03:38 AM, dinesh kumar wrote:
> >
> >
> > On Fri, Jul 24, 2015 at 10:22 AM, Robert
; [
> > NO
> > (READ,WRITE)
> > PERMISSION TO
> > (GROUP,OTHERS)
> > ]
>
> If we're going to do anything here, it should use COPY's
> extensible-options syntax, I think.
>
>
> Thanks Robert. Let me send a patch
ther than the information: "there were more than those I printed")
regards
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/20/2015 06:09 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> I wonder if we should have a default of capping the dump to say 1k lines
>> or such and only optionally do a full one.
>
> -1. It's worked like this for the last fifteen years or thereabouts,
ont think we have
made relevant changes in more recent versions.
regards
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o carry "official" snapshots on the download site (
https://ftp.postgresql.org/pub/snapshot/dev/) that you could use if you
dont want git directly - those even receive some form of QA (for a
snapshot to be posted it is required to pass a full buildfarm run on the
buildbox).
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ll just failed in the same part of the regression tests
(and it is a Sparc64 box though not running solaris):
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2015-05-24%2023%3A00%3A07
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Hi,
2015-05-05 2:51 GMT+02:00 Andreas Karlsson :
> From my point of view as a reviewer this patch set is very close to being
> committable.
I'd like to thank already now to all committers and reviewers and hope
BRIN makes it into PG 9.5.
As a database instructor, conference organisator and geospa
which may
> be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
> RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
> have OpenSSL and therefore this wouldn't create any new dependencies and
> might be slightly simpler to implement.
not
that is where the past CF app stores its
> data, like that:
> https://commitfest-old.postgresql.org/action/patch_view?id=1330
hmm maybe we should have some sort of handler the redirects/reverse
proxies to the old commitfest app for this.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-
time.
fwiw - looks like spoonbill(not doing CLOBBER_CACHE_ALWAYS) managed to
trigger that ones as well:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2015-02-23%2000%3A00%3A06
there is also some failures from the BETWEEN changes in that
regression.diff but that might be fallout from
s that important to get it on a per-query base, imho it
is simply a configuration limit we have set (similiar to work_mem or
when switching to geqo) - we dont report "per query" through
notice/warning there either (though the effect is kind visible in explain).
Stefan
--
Sent via pgs
pecify a "maximum number
of workers per query" as well as a "maximum number of workers in total
for parallel operations".
>
> Now, for debugging purposes, I could see such a parameter being
> available but it should default to 'off/never-fail'.
not sure what
On 01/06/2015 10:12 PM, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:
>>>> I will run the script today. I didn't do it earlier because I want to
>>>> be current on reading community em
at the files should have newlines I dont think those
should be added in a copyright bump commit and I think the script might
actually break files where we specifically dont want a newline (afaik we
dont have atm but still)
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
3. If no, how large would you estimate the efforts to implement this
in days for an experienced programmer like you?
Yours, Stefan
2014-08-15 20:16 GMT+02:00 Alvaro Herrera :
> Fujii Masao wrote:
>
>> I've not read the patch yet. But while testing the feature, I found that
>>
On 07/13/2014 10:35 PM, Magnus Hagander wrote:
> On Sun, Jul 13, 2014 at 10:32 PM, Stefan Kaltenbrunner
> wrote:
>> On 07/12/2014 03:08 PM, Magnus Hagander wrote:
>>> As an administrator, I find that you fairly often want to know what
>>> your current connect
.
Yeah that would be handy - however I often wish to be able to figure
that out based on the logfile as well, any chance of getting these into
connection-logging/log_line_prefix as well?
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On 06/27/2014 08:26 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-06-27 13:12:31 -0400, Robert Haas wrote:
>>> I don't personally object to dropping Alpha, but when this was
>>> discussed back in October, Stefan did:
>>>
>>>
nt/staging, i really doubt that (especially
given the .0 history we had in the last years) people really move -BETA
installs to production or expect to do so.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm not sure about about "misconfigured" but both my personal
buildfarm members and pginfra run ones (like gaibasaurus) got errors
complaining about "snapshot too old" in the past for long running tests
so I'm not sure it is really a "we never had machin
ing an exception
when we request an unknown configuration parameter complicating our stored
procedure a little. It would be more comfortable if we could query pg_settings
and just get an empty result if the configuration parameter is not set.
Regards,
Stefan
--
Sent via pgsql-hackers mailing l
Hi Hadi
Do you think that cstore_fd*w* is also welll suited for storing and
retrieving linked data (RDF)?
-S.
2014-04-03 18:43 GMT+02:00 Hadi Moshayedi :
> Dear Hackers,
>
> We at Citus Data have been developing a columnar store extension for
> PostgreSQL. Today we are excited to open source
at
> would avoid some annoyances for documentation authors. But I still
> think we ought to just nuke them, because who cares?
I dont care about HISTORY and even less so about regress_README but I
would prefer to keep INSTALL because I know that people do look at that
one...
Stefan
--
Se
y Tomas Vondra and Amit Langote.
it seems that this commit made spoonbill an unhappy animal:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2014-01-23%2000%3A00%3A04
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
followings are for client encoding only */
> PG_SJIS,/* Shift JIS
> (Winindows-932) */
while you have that file open: s/Winindows-932/Windows-932 maybe?
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
state:
"By default it is disabled since it generates false warnings in more
than 99% of cases."
So maybe you need to apply some default settings to get a more sensible
report to start from?
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 12/04/2013 07:30 PM, Joshua D. Drake wrote:
>
> On 12/04/2013 07:32 AM, Stefan Kaltenbrunner wrote:
>>
>> On 12/04/2013 04:30 PM, Peter Eisentraut wrote:
>>> On 12/4/13, 2:14 AM, Stefan Kaltenbrunner wrote:
>>>> running a
>>>> few kvm instanc
l version on various
distribution platforms (because that is what people deploy in
production, hand built git-fetched kernels are rare) using tests that
both might have extended runtimes and/or require external infrastructure
>
> Or you could go off and do your own thing, but I believe that would leave
> us all poorer.
fully agreed
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/04/2013 04:30 PM, Peter Eisentraut wrote:
On 12/4/13, 2:14 AM, Stefan Kaltenbrunner wrote:
running a
few kvm instances that get bootstrapped automatically is something that
is a solved problem.
Is it sound to run performance tests on kvm?
as sounds as on any other platform imho, the
uld be to work out the minimum viable product,
> and then see what it would take to get that done.
yeah we need to start somewhere and see what we can learn.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bility to track that closely and automated and report back
and only if that feedback loop fails to work we are actually in a real
position to consider something as drastical as considering a platform
"undependable" or looking into alternatives (like directIO).
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
file as ASCII, e.g. not:
>>
>>
>> default:
>
> Huh, I did not see anything remotely like that in my email or in
> the archives:
>
> http://www.postgresql.org/message-id/1381949353.78943.yahoomail...@web162902.mail.bf1.yahoo.com
http://www.postgresql.org/message-id/r
On 10/18/2013 06:29 PM, Andres Freund wrote:
> On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
>> On 10/18/2013 02:41 PM, Robert Haas wrote:
>>> On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>>>> On 10/17/13 12:45 PM, Robert Haas wrote:
>
e current buildfarm support are considered fully
> supported. Others should be relegated to a sentence later in the
> paragraph that says something like "code support exists but not tested
> recently" or "expected to work but not tested regularly".
seems like an im
#History, all
> manufacturing of VAX computers ceased in 2005, but according to
> http://en.wikipedia.org/wiki/OpenVMS#Major_release_timeline, OpenVMS
> is still releasing new versions. I'm not sure what to make of that.
VAX is also an officially supported OpenBSD port (see
http://www.openbsd.org
On 09/03/2013 06:15 PM, Robert Haas wrote:
> On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
> wrote:
>>> It would seem that a simple solution would be to add an elevel argument
>>> to ProcessGUCArray and then call it with NOTICE in the case that
>>> check_
On 09/01/2013 12:53 AM, Stephen Frost wrote:
> * Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
>> On 08/18/2013 05:40 PM, Tom Lane wrote:
>>> Stefan Kaltenbrunner writes:
>>>> While working on upgrading the database of the search system on
>>>>
On 08/18/2013 05:40 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> While working on upgrading the database of the search system on
>> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
>> that system are actually invalid and cannot be reloaded wi
On 08/18/2013 05:40 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> While working on upgrading the database of the search system on
>> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
>> that system are actually invalid and cannot be reloaded wi
ed before the actual text search configuration is
(re)created. I have not checked in any more detail but I suspect that
this problem is not only affecting default_text_search_config.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 08/09/2013 12:02 AM, Vik Fearing wrote:
> On 08/08/2013 07:57 PM, Stefan Kaltenbrunner wrote:
>
>> On 08/08/2013 01:52 PM, Vik Fearing wrote:
>>> I would add this to the next commitfest but I seem to be unable to log
>>> in with my community account (I
today's HEAD attached.
>
> I would add this to the next commitfest but I seem to be unable to log
> in with my community account (I can log in to the wiki). Help appreciated.
whould be a bit easier to diagnose if we knew your community account name ;)
Stefan
--
Sent via pgsql-h
hat, and
> somebody who doesn't have access to edit the files blocks themselves
> out, there is no way for them to get a working system *at all*.
thinking more about that - is there _ANY_ prerequisite of an application
that can be completely reconfigured over a remote access protocol
he answer is "incredibly complicated"
> because it involves a stored procedure to implement the local policy and
> a command to enable the policy, really, I wonder who you're addressing
> there. Certainly not DBA, so that must be sysadmins, who would be better
> off without
On 08/05/2013 08:21 PM, Josh Berkus wrote:
> On 08/05/2013 11:14 AM, Stefan Kaltenbrunner wrote:
>> * in a few years from now people will just use superuser over the
>> network for almost all stuff "because its easy and I can click around in
>> $gui", having potentia
cause of say overrunning system resources. The same
thing can happen now just as well, but having them available from remote
will also result in tools doing this and people that have less
information about the hardware and system or what else is going on on
that box. Also we have to keep in mind
ut superuser (like if you run a managed service you might
want customers to be able to tweak some stuff but say not
archive/pitr/replication stuff because the responsibility for backups is
with the hosting company)
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I think that using those is a better idea in
general.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
snapshots also will also only get
published if the source passed a full buildfarm run as a basic form of
validation.
>
> However, if oyu're looking for a snapshot, please use the one on the
> ftpsite. Generating those snapshots on the git server is slow and
> expensive...
definitly
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Et26=r...@mail.gmail.com
?
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e on Management of data (SIGMOD '93), Peter
Buneman and Sushil Jajodia (Eds.). ACM, New York, NY, USA, 157-166.
DOI=10.1145/170035.170066 http://doi.acm.org/10.1145/170035.170066
just in case a direct reference might come in handy :-)
...
All the ebst,
Stefan.
--
Sent via pgsql-hackers ma
doubt, that any renaming of
config files will really have an impact on usability in the shady area
of "TL;DR" - at least for the next twenty years or so - as it still
holds, that from a false start (eg. not reading documentation written)
anything may follow.
But as usability is a prac
ewer gcc's
you should specify an open mode flag as third argument of the fopen
call, as only with the test tool nothing important found.
Stefan.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
llow to the end ... ;-)
but at least it is clear from this source, that CALL seems to be a
statement in SQL to invoke a procedure or whatever name juggling suits.
...
HTH,
Stefan.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
not a good judge here!) quite small
HTH,
Stefan.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-06-11 15:23 CEST, Hannu Krosing wrote:
On 06/11/2013 03:08 PM, Stefan Drees wrote:
...
What about this:
=# SELECT '{"measure":"seconds", "measure":42}'::json;
json
--
{"measure":
json
--
{"measure":42}
I presume people being used to store metadata in "preceding" json object
members with duplicate names, would want to decide in the client
requesting the data what to do with the metadata information and at what
mmitfest.postgresql.org/action/patch_view?id=1123
> https://commitfest.postgresql.org/action/patch_view?id=1124
>
>
> I stopped trying to add new item after too many failures from
> https://commitfest.postgresql.org/action/patch_form
> So one patch is not in the commitfest yet (fix_install_ext_
"ORDER BY ... <-> ..." involved.
I have to dig into my tests in order to give you the EXPLAIN ANALYZE.
Yours, Stefan
2013/5/26 Tom Lane :
> Stefan Keller writes:
>> Given following schema:
>
>> 1. TABLE a and TABLE b, each with INDEX on attribute geom.
>
>> 2. A VI
> Cell: (253) 686-5518
> william.k...@quentustech.com
>
> On 05/25/2013 05:35 PM, Stefan Keller wrote:
>> Hi
>>
>> I've encountered a fundamental problem which - to me - can only be
>> solved with an (future/possible) real index on views in PostgreSQL
>&
nct index on views.
Any opinions on this?
Yours, Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2013 12:20 PM, Stefan Kaltenbrunner wrote:
> Hi All!
>
>
> We will be upgrading gemulon.postgresql.org during the next few
> hours to the current release of debian (wheezy/7.0) as discussed
> with various people. To p
so don't be surprised if you get an error message.
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlGeQaYACgkQr1aG+WhhYQH4PACgncD04Mlo+sC27UROsnRkVo3e
NuEAoM/3U5QGt/TETG5f9OjXEdfATd+w
=zNvy
-END PGP SIGNATURE-
--
Sent via pgsql-hackers mailing
On 04/04/2013 02:18 AM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
On 04/03/2013 12:59 AM, Tom Lane wrote:
BTW, on further thought it seems like maybe this is an OpenBSD bug,
at least in part: what is evidently happening is that the temporary
blockage of SIGINT during the handler persists
rt a discussion.
>
>> There are very many other keywords that are less reserved in
>> Postgres than in the spec; this is a good thing.
>
> How is it a good thing? Help me understand.
why is breaking random applications or making it harder for people to
migrate from other databases without any reason a good thing?
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s no technical reason to do so...
>
> Sadly, this will cause problems for people who have tables with those
> names, but we've introduced incompatibilities (in 8.3, e.g.) that hit
> a much bigger part of our user base much harder than this. When we do
> re-reserve, we'll nee
l, just pump the data etc from one source
> to another in parallel. But I pity the poor guy who has to write it :-)
hmm pretty sure that Joachims initial patch for parallel dump actually
had a PoC for something very similiar to that...
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he old server, which has been discussed in the past for preparing
> pg_upgrade when we have a page format change.
given something like this also will have to be dealt with by pg_upgrade,
why not fold it into that (like into -c) completly and recommend running
that? on the flipside if people do
en we return to the main loop?
>
> If (your version of) OpenBSD is getting this wrong, it'd explain why
> we've not seen similar behavior elsewhere.
hmm trolling the openbsd cvs history brings up this:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/sparc64/machde
till-unexplained issues on spoonbill from a year back:
http://www.postgresql.org/message-id/4fe4b674.3020...@kaltenbrunner.cc)
so I would really like to see an option for a global timeout.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/26/2013 11:30 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> hmm - will look into that in a bit - but I also just noticed that on the
>> same day spoonbill broke there was also a commit to that file
>> immediately before that code adding the fflush() calls.
>
On 03/26/2013 09:33 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> On 03/26/2013 08:45 PM, Tom Lane wrote:
>>> It looks from here like the isolationtester client is what's dropping
>>> the ball --- the backend states are unsurprising, and two of them
1 - 100 of 777 matches
Mail list logo
