2011/3/15 Robert Haas robertmh...@gmail.com:
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
On Tue, Mar 15, 2011 at 06:03, sanjay verma sanjayi...@yahoo.com wrote:
Hi,
I have installed PostgreSQL 8.4 on Windows 2008 R2 64 bit server. However,
the PostgreSQL service stops intermittently.
Is PostgreSQL 8.4 supported on Windows 2008 R2?
Yes.
Does PostgreSQL 8.4 have any known issue
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants for time values, e.g. 24, 12, 60, etc.
The attached
Bruce Momjian br...@momjian.us writes:
I would like to apply the attached patch to git_changelog for use in
creating the major release notes. I specifically added these flags:
--author-after Show author after the commit
--master-only Show commits made exclusively to the master
On Tue, Mar 15, 2011 at 9:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
I would like to apply the attached patch to git_changelog for use in
creating the major release notes. I specifically added these flags:
--author-after Show author after the commit
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Would it help moving toward Leap Second support, and is this something
we want to have?
IMO we don't want to have that, as it would completely bollix datetime
calculations of all kinds. You couldn't even count on stored timestamps
not changing
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I would like to apply the attached patch to git_changelog for use in
creating the major release notes. I specifically added these flags:
--author-after Show author after the commit
--master-only Show commits made
On Sat, Mar 12, 2011 at 1:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It looks like 9.1 currently introduces 11 new keywords: ATTRIBUTE,
COLLATION, EXTENSION, LABEL, NOREPLICATION, PASSING, REF, REPLICATION,
UNLOGGED, VALIDATE, and XMLEXISTS. Aside from
Robert Haas wrote:
On Tue, Mar 15, 2011 at 9:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
I would like to apply the attached patch to git_changelog for use in
creating the major release notes. ?I specifically added these flags:
? ? --author-after
Bruce Momjian wrote:
Bottom line: I need to start the release notes today --- I can hack my
own version and we can revisit this later, which I am afraid will be in
one year, or we can just add what I have and we can keep hacking on it
as needed.
Oh, one more thing. pgcvslog was added to
On Tue, Mar 15, 2011 at 10:25 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Tue, Mar 15, 2011 at 9:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
I would like to apply the attached patch to git_changelog for use in
creating the major
Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Would it help moving toward Leap Second support, and is this
something we want to have?
IMO we don't want to have that, as it would completely bollix
datetime calculations of all kinds. You couldn't even
Robert Haas robertmh...@gmail.com writes:
No, he wants to exclude things that were back-patched. But I agree
it's kind of grotty. Imagine you are preparing release notes for a
minor release. Now you will want all the back-branch commits, but not
the ones that were only committed to master.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Would it help moving toward Leap Second support, and is this
something we want to have?
IMO we don't want to have that, as it would completely bollix
Robert Haas wrote:
Bottom line: ?I need to start the release notes today --- I can hack my
own version and we can revisit this later, which I am afraid will be in
one year, or we can just add what I have and we can keep hacking on it
as needed.
The release note generation is tied to you
I wrote:
So I'd vote for having both --master-only and its inverse
--ignore-master, but I'm not sure we need anything more general
than that.
On second thought ... one big problem with --master-only is that
it's useful only to the extent that you trust git_changelog to
have matched up master
Excerpts from Tom Lane's message of mar mar 15 11:42:06 -0300 2011:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Would it help moving toward Leap Second support, and is this
something we want to have?
Tom Lane wrote:
I wrote:
So I'd vote for having both --master-only and its inverse
--ignore-master, but I'm not sure we need anything more general
than that.
On second thought ... one big problem with --master-only is that
it's useful only to the extent that you trust git_changelog to
On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2011/3/15 Robert Haas robertmh...@gmail.com:
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there was a discussion about impact of number of keyword
On 12/03/11 05:18, Robert Haas wrote:
XMLEXISTS is pretty horrible in that the
syntax apparently requires three new keywords (XMLEXISTS, PASSING,
REF) which is pretty lame but I guess it's specified by the standard
so I'm not sure there's much we can do about it. The rest look
reasonable and
Applied. I did not bump the catalog version because they are just
comments. I assume that is the right procedure.
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
On 15 March 2011 15:26, Bruce Momjian br...@momjian.us wrote:
Applied. I did not bump the catalog version because they are just
comments. I assume that is the right procedure.
*SNIP*
+ COMMENT ON DATABASE postgres IS 'default administrative
connection database';\n,
Default
Thom Brown wrote:
On 15 March 2011 15:26, Bruce Momjian br...@momjian.us wrote:
Applied. ?I did not bump the catalog version because they are just
comments. ?I assume that is the right procedure.
*SNIP*
+ ? ? ? ? ? ? COMMENT ON DATABASE postgres IS 'default administrative
On Fri, Mar 11, 2011 at 3:10 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
SET VALID? (c.f. SET NULL).
That sounds the best so far, but maybe we should think about other
phrases altogether (ie, not arising
Robert Haas robertmh...@gmail.com writes:
Well, we don't seem to really have consensus around anything in
particular here. Should we just leave it alone, or is this worth
spending more effort on?
I haven't seen any suggestions yet that don't seem inferior to the
existing command name (ie,
On 15 March 2011 15:37, Bruce Momjian br...@momjian.us wrote:
Thom Brown wrote:
On 15 March 2011 15:26, Bruce Momjian br...@momjian.us wrote:
Applied. ?I did not bump the catalog version because they are just
comments. ?I assume that is the right procedure.
*SNIP*
+ ? ? ? ? ? ?
2011/3/15 Robert Haas robertmh...@gmail.com:
On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2011/3/15 Robert Haas robertmh...@gmail.com:
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there was
On 15 March 2011 15:51, Thom Brown t...@linux.com wrote:
On 15 March 2011 15:37, Bruce Momjian br...@momjian.us wrote:
Thom Brown wrote:
On 15 March 2011 15:26, Bruce Momjian br...@momjian.us wrote:
Applied. ?I did not bump the catalog version because they are just
comments. ?I assume
Hey all,
Oleg Bartunov and I intend to begin the project of translation
of PostgreSQL documentation on Russian.
First of all, we want to create glossary to be used by translators.
However we consider that it would be nice to generalize this idea
and create a multi-language glossary of PostgreSQL
2011/3/15 Dmitriy Igrishin dmit...@gmail.com:
Oleg Bartunov and I intend to begin the project of translation
of PostgreSQL documentation on Russian.
Just to make sure that you are aware of a recently-started effort to
create a German translation, by Susanne and others:
On Sat, Mar 12, 2011 at 09:24:38PM +, Greg Stark wrote:
On Sat, Mar 12, 2011 at 8:42 PM, Robert Haas robertmh...@gmail.com wrote:
A preposition is something you should try not to end a sentence
with.
Something to keep in mind when someone localises Postgres for Latin
which has this
Thom Brown wrote:
On 15 March 2011 15:51, Thom Brown t...@linux.com wrote:
On 15 March 2011 15:37, Bruce Momjian br...@momjian.us wrote:
Thom Brown wrote:
On 15 March 2011 15:26, Bruce Momjian br...@momjian.us wrote:
Applied. ?I did not bump the catalog version because they are just
I looked through this, and it appears that we can just remove these
restrictions.
I considered the following parameters, which are measured in
milliseconds and currently have INT_MAX/1000 as maximum value.
deadlock_timeout
max_standby_archive_delay
max_standby_streaming_delay
On sön, 2011-03-13 at 13:16 -0400, Tom Lane wrote:
Well, it's exactly that distinction that's bugging me. It seems a bit
arbitrary if collation propagates in certain cases where collation
state doesn't. I'm concerned in particular that we're going to find
ourselves backend into a corner if
On tor, 2011-03-10 at 17:16 -0500, Tom Lane wrote:
On the other hand ... one thing that's been bothering me is that
select_common_collation assumes that explicit collation derivation
doesn't bubble up in the tree, ie a COLLATE is only a forcing function
for the immediate parent expression
Peter Eisentraut pete...@gmx.net writes:
On tor, 2011-03-10 at 17:16 -0500, Tom Lane wrote:
On the other hand ... one thing that's been bothering me is that
select_common_collation assumes that explicit collation derivation
doesn't bubble up in the tree, ie a COLLATE is only a forcing function
On tor, 2011-03-10 at 18:12 -0500, Tom Lane wrote:
What I'm inclined to do about this is set default's collencoding to
-1, with the semantics of works for any encoding, and fix the lookup
routines to try -1 if they don't get a match with the database
encoding. Having done that, we could also
On tis, 2011-03-15 at 16:16 -0400, Tom Lane wrote:
But what did you think of the idea of setting collations during a
post-pass, so that the collation derivation values need only be local
storage during that one recursive routine?
That sounds reasonable. We do need the collation value in the
On Tue, Mar 15, 2011 at 05:09:47PM +0100, Pavel Stehule wrote:
Real test of parser's speed should be done on short and quick queries.
It can be unexpected so parser should be a bottle neck on long OLAP
queries.
Surely parsing overhead could be measured by simply PREPAREing every
query, rather
On Fri, 2011-03-11 at 11:40 -0500, Robert Haas wrote:
My vote would be forget about building installers for alpha4 and
instead wrap an alpha5 next week.
If you need more votes for this: +1 from me. I'd like to wrap the
packages before I leave for PGEast.
Regards,
--
Devrim GÜNDÜZ
Robert Haas wrote:
On Fri, Mar 11, 2011 at 8:07 PM, Bruce Momjian br...@momjian.us wrote:
Currently, if you create a temporary table with the ON COMMIT action of
DELETE ROWS, the table will truncated for every commit, whether there is
any data in the table or not.
I measured the
Bruce Momjian wrote:
Andrew Dunstan wrote:
On 11/05/2010 06:54 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
The comment on the commit says:
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,
rather than executing the INTO clause with
On Sun, 2011-03-13 at 19:40 -0400, Tom Lane wrote:
It strikes me that it'd be possible to have btvacuumcleanup directly
measure order correlation when it's processing a btree index, yielding a
reliable answer for any btree index regardless of number of columns.
We could do that by comparing
2011/3/15 Devrim GÜNDÜZ dev...@gunduz.org:
On Fri, 2011-03-11 at 11:40 -0500, Robert Haas wrote:
My vote would be forget about building installers for alpha4 and
instead wrap an alpha5 next week.
If you need more votes for this: +1 from me. I'd like to wrap the
packages before I leave for
Robert Haas robertmh...@gmail.com writes:
2011/3/15 Devrim GÜNDÜZ dev...@gunduz.org:
If you need more votes for this: +1 from me. I'd like to wrap the
packages before I leave for PGEast.
My only hesitation about this is that it seems like sync rep and
collation support are both still pretty
On Wed, Mar 9, 2011 at 11:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
Same as above. I think that it's more problematic to leave the code
as it is. Because smart/fast shutdown can make the server get stuck
until immediate shutdown is requested.
I agree that the current state of affairs is
On Mon, Mar 14, 2011 at 01:56:22PM +0200, Heikki Linnakangas wrote:
On 12.03.2011 12:40, Noah Misch wrote:
The installation that inspired my original report recently upgraded from
9.0.1
to 9.0.3, and your fix did significantly decrease its conflict frequency.
The
last several conflicts I
On Tue, Mar 15, 2011 at 10:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
2011/3/15 Devrim GÜNDÜZ dev...@gunduz.org:
If you need more votes for this: +1 from me. I'd like to wrap the
packages before I leave for PGEast.
My only hesitation about this is
On Tue, 2011-03-15 at 22:00 -0400, Tom Lane wrote:
My only hesitation about this is that it seems like sync rep and
collation support are both still pretty broken. Should we just not
worry about that for alpha?
FWIW, collations are probably still several days away from being
On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas robertmh...@gmail.com wrote:
The problem is that there may be another backend B waiting on a lock
held by A. If backend A exits cleanly (without a PANIC), it will
remove itself from the ProcArray and release locks. That wakes up A,
which can now
50 matches
Mail list logo
