fused with
serializability in the mathematical sense or in the sense of
transaction isolation levels.
In general on this thread, when I've seen the terms "serializable"
and "serializability" I haven't been clear on whether the words are
being used in their more general sense as words in the English
language, or in a more particular technical sense.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gh sampling of current
usage to be sure we know when we have alternatives for every current
valid usage?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 21, 2012, at 6:02 PM, Peter Eisentraut wrote:
> On Thu, 2012-10-18 at 16:31 +, Murphy, Kevin wrote:
>> It might be nice for psql to have a 'htmlcaption' boolean pset option that
>> would wrap the provided title/caption, if any, in a caption tag in the HTML
>
Alvaro Herrera wrote:
> Kevin Grittner escribió:
>> Tom Lane wrote:
>
>>> Also, it doesn't appear that we ever got around to preparing
>>> documentation updates, but I think we definitely need some if
>>> we're going to start throwing errors fo
;-> 'foo' limit 10;
> good tip - it's working
If two or more values happen to be at exactly the same distance,
wouldn't you just get one of them?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Pavel Stehule wrote:
> >> 2012/10/22 Tom Lane :
> >>> Perhaps it would be close enough to what you want to use DISTINCT ON:
> >>> contrib_regression=# explain select distinct on( t <->
Alvaro Herrera wrote:
> Kevin Grittner escribió:
>> Tom Lane wrote:
>
>>> Also, it doesn't appear that we ever got around to preparing
>>> documentation updates, but I think we definitely need some if
>>> we're going to start throwing errors fo
t a barrier to people migrating from Oracle because
SELECT FOR UPDATE in PostgreSQL is weaker than it is in Oracle (where
it is just as strong as if an actual UPDATE were done -- write
conflicts and all); let's not increase the barrier by making SELECT
FOR UPDATE even weaker.
-Kevin
--
Sen
ating system, which is
something you should generally include in a question.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t
to solve the problem is not performing as well as you think it
should.
http://www.postgresql.org/docs/current/static/sql-createindex.html
http://www.postgresql.org/docs/current/static/indexes.html
http://wiki.postgresql.org/wiki/SlowQueryQuestions
-Kevin
--
Sent via pgsql-hackers maili
observe the cost numbers in the output.
> Also, is there any way to force postgres abide on the estimation of
> Hashjoin cost as 3(R+S), which also means, to make hashjoin cost
> mainly spend on I/O?
How useful would that be for workloads where data is fully cached?
-Kevin
--
Sent via
omething else in production. What does
it take for their autovacuum to be stalled?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
> What I've been wondering since this last came up is whether we
> could use some variant of the SIREAD locks Kevin introduced for SSI
> to handle this case - essentially have the transaction doing the
> TRUNCATE make an entry in the lock table that will force
Merlin Moncure wrote:
> Kevin Grittner wrote:
>> Robert Haas wrote:
>> It seems to me that the goal would be to make this semantically
>> idential to the behavior users would see if an unqualified DELETE
>> were run against the table rather than a TRUNCATE.
>
er perhaps this one could
serve as a "pilot", to identify issues and help develop such a plan.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
narrow enough to merit the approach
you're talking about, IMV, at least. Sorry I initially misunderstood
what you were going for.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ght want to see how far he got -- he might have some "work in
process" or an internal patch that would be a good starting point.
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00831.php
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01065.php
-Kevin
--
Sent via
creating, with a reasonably prominent link from the home page.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
7;m not sure
that should preclude a change that would benefit others. I'm sure
we can code around it one way or another. Perhaps some of the new
monitoring functions in 9.0 will help. I'll have to take a look.
Seriously, if there would be significant benefit to others, don't
let
I saw this on reddit and thought I might drop a line.
I went through this same issue, trying to find a postgresql driver. Mostly, I
had no intention of using psycopg because of its copyleft licensing. (Of
course, I don't need to go into why.)
Anyways, here's some info that might help on thre
idered as something that can be shipped with
PostgreSQL. (Yeah, I'm looking at *you*, section 4.)
-Kevin
> DISCLAIMER. If I receive a message from you, you are agreeing
> that:
> 1. I am by definition, "the intended recipient".
> 2. All information in the email
e it was useful to feed pg_dump --column-inserts output into
Sybase databases. It was very nice to have that. I think we did
sometimes have to filter it through sed to deal with BOOLEAN vs BIT
issues.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
I hope people don't mind my asking about this on the list... as I hinted at
before, I don't really follow the development of PostgreSQL, I was just
interested in the Python driver project that I heard about.
Anyways, as I understand it, the current goal is to use psycopg and get it
changed to
> Well, all else being equal we'd certainly prefer a library that was
> licensed more like the core Postgres database. However, we don't have
> infinite resources, and an LGPL license is not a showstopper (at least
> not to the people who seem to be willing to work on this problem).
> The attract
;match multiple hosts by a single
> rule". Any reason not to do this?
I can't see any reason other than code complexity.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sane not to use them at all, but there are valid use
cases for different timings. Personally, I'd be happy to see a
default of sending them if a connection is idle for two minutes, but
those people who create 2000 lightly used connections to the
database might feel differently.
-Kevin
--
Heikki Linnakangas wrote:
> I think 'rsync' has the same problem.
There is a switch you can use to create the problem under rsync, but
by default rsync copies to a temporary file name and moves the
completed file to the target name.
-Kevin
--
Sent via pgsql-hackers mailin
[off-list to avoid distracting from the 9.0 wrap-up effort]
Markus Wanner wrote:
> Quoting "Kevin Grittner" :
>> I strongly encourage you to set that up on git.postgresql.org.
>
> I'm about to provide git repositories for Postgres-R anyway, so
> I've se
I wrote:
> [off-list to avoid distracting from the 9.0 wrap-up effort]
Arg. I really didn't mean that to go to the list. :-(
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
M Z wrote:
> Looks like the contrib functions have not been added in.
The contrib features are not built or installed by default -- they
are optional modules. This should point you in the right direction:
http://www.postgresql.org/docs/8.3/interactive/contrib.html
-Kevin
--
Sent
sees *its own* uncommitted work. Wouldn't the
historical policy of PostgreSQL self-notifies be consistent with
that?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
_
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/
_
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/
3 at all; in
fact, adding the additional columns to indexes to allow that
optimization tends to work against it.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; problems, a nonvolatile function is allowed to call a volatile
> one.
Could it work to store a flag in each process to indicate when it is
executing a non-volatile function, and throw an error on any attempt
to call a volatile function or modify the database?
-Kevin
--
Sent via pgsql
Tom Lane wrote:
> "Kevin Grittner" writes:
>> throw an error on any attempt to call a volatile function or
>> modify the database?
> It's *not an error* for a nonvolatile function to call a volatile
> one.
Right, we all know it currently doesn&#x
"Joshua D. Drake" wrote:
> If I issue a shutdown, PostgreSQL should do whatever it needs to
> do to shutdown; including issuing a pg_stop_backup.
Should we have a pg_fail_backup function, so that it doesn't put out
a file which suggests that we have a complete backup?
Greg Stark wrote:
> Kevin Grittner wrote:
>> Does anyone have a sane use case for a non-volatile function to
>> call a volatile one or to update the database?
>
> So consider for example a function which explicitly sets the
> timezone and then uses timestamp wi
really needed to solve this, so it's 9.1
material at best.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark wrote:
> Kevin Grittner wrote:
>> Thanks for the examples. They did make me consider a real-life
>> type of process which isn't currently implemented as a PostgreSQL
>> function, but conceivably could be -- randomizing a pool of
>> jurors to facilit
formance testing and confirmation that existing apps don't rely
on the non-standard behavior. I don't remember either of those
happening.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
> Perhaps we should add it to the next CommitFest?
Sounds like the right course of action to me. If nobody objects or
beats me to it, I'll do that.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
"Kevin Grittner" wrote:
> Robert Haas wrote:
>
>> Perhaps we should add it to the next CommitFest?
>
> Sounds like the right course of action to me. If nobody objects
> or beats me to it, I'll do that.
Done.
-Kevin
--
Sent via pgsql-hackers mailin
able for PostgreSQL development to say we can't get to a
feature which SQL server had in version 1.0 and maintains through
their conversion to MVCC. Where it fits in the scheme of priorities
and cost/benefit is certainly a valid question. It does provide
significant benefits for some us
x in the index file, you will
move the leaf index data into the heap tuples? The pages in such a
IOT heap file would still need to look a lot like index pages, yes?
I'm not saying it's a bad idea, but I'm curious what benefits you
see to taking that approach.
-Kevin
--
Sent vi
could find:
http://community.enterprisedb.com/git/
Heikki, any thoughts on what it would take, beside cleaning up bit
rot?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he new page is
> allocated. Vacuum has a clever trick for solving this but it
> doesn't work for arbitrarily many concurrent scans.
It sounds like you're asserting that Index Scan nodes are inherently
unreliable, so I must be misunderstanding you.
-Kevin
--
Sent via pgsql-hackers
_stop_backup or to interrupt a pending one.
(2) You wouldn't want the .backup file to be written.
(3) What about the equivalent WAL end-of-backup record?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
> On tor, 2009-08-20 at 10:31 -0500, Kevin Grittner wrote:
>> (2) It doesn't exit with zero for a missing executable unless
>> the request is "stop". It uses 5, which means "program is not
>> installed".
>
> Usin
- it has its own set of values and 5 is not assigned, so
using it seems wrong. It seems like it should be 3 ("program is not
running"). Agreed?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
remember suggesting automatic query retry
(rather than continuing in a mixed-snapshot mode) for update
conflicts in read committed mode and Tom had objections; you might
want to check the archives for that.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
hat the database engine can determine the
read/write behavior directly if the language is SQL, and you tell it
what it does if you're coding in some other language.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gresql.org/docs/8.4/interactive/datatype-net-types.html
> Also I'm interesting in pgsql . Could you give me some suggestion
> about how to hack pgsql.
http://www.postgresql.org/developer/
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Bruce Momjian wrote:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>> > Exactly. With Fedora respecting the standard in this regard,
>> > I'm convinced we should, too. In reviewing things based on
>> > Peter's question, I did start to ha
into pg_ctl. That the script becomes shorter and easier to
read and understand may have some limited value, but I see that as
secondary.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing Visual Studio headers
get picked up?
* Is there something I should be doing to avoid the 'inconsistent dll
linkage' warnings?
(The C-Language functions are going to end up using some in-proc
Windows-only components, so I'm hoping that building them using Visual
Studio will be the least painful way to get at those.)
Thanks in advance for any help
Kevin.
nows it's running on Win32, is there some other configuration change I
should make for dev purposes to indicate that it's "the win32 configuration"?
Or does "building with the win32 configuration" refer to those who are building
the server from source, or something?
Tha
or
to, er, find out how to do it :) ). You can get round it by commenting out the
include or creating a dummy libintl.h.
Just posting the results here in case they're relevant for anything.
Kevin.
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: 05 M
Robert Haas wrote:
> Wolfgang Wilhelm wrote:
>> Isn*t that a good time to think to put that question into the
>> list of things PostgreSQL doesn*t want to do?
>
> Yes.
Done.
http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want
-Kevin
--
Sent via pgsql
ut functions that
aren't required by the standard -- which seems much less invasive
than the OP's requests.
I'm willing to rework, soften, or narrow the entry as needed, and I
certainly would take no offense at anyone else doing so. I was just
trying to get it listed, since there seemed
s one issue.
The other issues raise in the original post are valid possible
enhancements, or is there something else to list?:
http://archives.postgresql.org/pgsql-hackers/2010-03/msg00257.php
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
gs from a
C-language function without using palloc?
Thanks in advance for any leads
Kevin.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
PORT',
and if you define BUILDING_DLL, then PGDLLIMPORT is defined as ' __declspec
(dllexport)'). But you're quite right, if I take out the BUILDING_DLL
definition, and put the __declspec (dllexport) stuff in piecemeal, the
access violation goes away. Thank goodness.
Thanks, tha
y others you want to load and share subroutines from.
I don't see where plperl is unsafe unless you do those things. A
user who can do those things can likely subvert your database in
other ways, no?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
ve comment true.
Quick brain dump on the topic, anyone?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> "Kevin Grittner" writes:
>> According to htup.h:
>> * t_self and t_tableOid should be valid if the HeapTupleData
>> * points to a disk buffer, or if it represents a copy of a tuple
>> * on disk. They should be explicitly set invalid in
This can be startling in
a debugger if you don't know that the comment isn't really true.
(And I've found another place where t_tableOid isn't set, but it is
apparently benign; that's without an exhaustive search.)
I could put forward a comment-only patch per the above if th
ing beyond a comment would be justified.
Longer term, it's hard enough getting one's head around a million
lines of code without false statements in the comments.
Thanks again.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
And paint it red.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> It would scan better, to my mind, if we moved backend_start ahead
>> of xact_start.
>
> Yes, that is another idea that would work, though Tom's idea that
> the query start should be near the query makes sense.
Wel
though it would sure be nice if
it were possible to swap 2 and 3 so that we could put the query text
at the end.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e changing
>> that, even if it were clearly a good idea which I doubt.
>
> Possibly. We should at least document that.
Basically, what you feel is missing is documentation that if two
shapes share one or more points they are considered to overlap;
there is no requirement that they share an
Robert Haas wrote:
> Does the SQL standard specify anything in this area?
The only thing that comes to mind for me is the SQL/PSM
.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
o match the
conventional definition in geometry.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
> I think you've missed my point.
> What I was talking about was that box '((0,0),(1,1))' && box
> '((1,1),(2,2))' returns true, even though they touch at only a
> single point, and share zero area.
FWIW, that's what I w
otherwise you could only schedule
one thing in the room for all time and one thing at a given time
across all rooms.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
> I thought it was referring to all pairs of rows, but I see
> now it's referring to pairs of columns, so it's correct.
If it confused you, I suspect it will confuse others. Offhand,
I can't see how to improve the language, though.
-Kevin
--
S
the number of
replication connections, and be surprised when they are unable to
connect in an emergency.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus wrote:
> Robert,
> do you think you could put up replacement tarballs today?
If you don't hear from him soon, perhaps he's traveling:
http://archives.postgresql.org/pgsql-hackers/2010-03/msg01298.php
-Kevin
--
Sent via pgsql-hackers mailing lis
rofile.id, profile.name, profile.age, COUNT(*)
FROM profile
GROUP BY profile.id, profile.name, profile.age;
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
OUNT(*) FROM
(SELECT id, name, age FROM profile GROUP BY id, name, age) x;
I don't remember offhand what version started considering a hash for
DISTINCT.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
(When I was
attempting to follow all the lists, I'd typically give up when I
fell about 6000 messages behind, and try to start up again "cold"
after having missed a big interval of messages.)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
aps -general should be eliminated in favor of more specific
lists?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ell, one of these more specific lists must be getting over half of
the message relevant to the title, unless things are freakishly
evenly divided. Message counts in the last 30 days:
143 -novice
199 -sql
321 -admin
436 -performance
1099 *subtotal*
1102 -general
2201 **total**
able
> with no statistics would trigger an automatic ANALYZE by the
> backend on which the query was executed.
+1 as an RFE
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing them to access any other drive they want, is just
silly.
It does raise the question of why we need to check this at all,
rather than counting on OS security to limit access to things which
shouldn't be seen.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
way to
establish sensible operations between types (like distance / speed =
time or speed * time = distance).
Just a thought
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander wrote:
> On Fri, Apr 9, 2010 at 16:02, Kevin Grittner
>> I assume we reject anything where what precedes the colon doesn't
>> match the current drive's designation?
>
> Define reject?
I guess I made that comment thinking about the example o
27;m totally at the hand-waving stage on it, with no concrete ideas.
I just thought that if you were adding more type information,
oriented aournd the types themselves rather than index AMs, some form
of inheritence might fit in gracefully.
> in any case it's almost entirely unrelated to what
ializable branch for an example.
I learned by putting in a request similar to your pending one.
;-)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
terialized views, I thought
this information might be germane.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
have anything to do with the old issue you're describing.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is before. Is there something I should do to
follow up on it (other than not blowing away the evidence if I see
it again)?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the "make check" regression
tests which would get run less frequently but test a lot more. This
sounds like a good one to include.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ideline, it seems
like we should. I wonder if we should add any hints telling people
what they might see as problems if they are too far one way or the
other. (Or does that go beyond the scope of what makes sense in
TFM?)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
king when our web support folks say I've
got it to the point where we're not getting any timeouts against our
20 second limit for queries which normally run in less than 1 ms.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing a random seed which is logged so that it can be forced
for a repeat of the run?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
In the embarrassingly trivial department, I think I found a
misspelled word in the GiST README file (unless it's a valid
alternate spelling I've never seen).
-Kevin
*** a/src/backend/access/gist/README
--- b/src/backend/access/gist/README
***
*** 110,116 particularly,
a bit more editing to make it
> read better if anyone is so inclined, although certainly the
> meaning is clear enough.
I think the same could be said for many of the README files. In
particular, some of them don't seem to have fully adjusted to being
fact, rather than proposal. I
create it, and possibly provide a stack trace.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1201 - 1300 of 4332 matches
Mail list logo
