On Wed, Mar 16, 2011 at 11:07 AM, Robert Haas 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 go do its thing.
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 Tue, Mar 15, 2011 at 10:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2011/3/15 Devrim GÜNDÜZ :
>>> 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 sup
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 co
On Wed, Mar 9, 2011 at 11:11 PM, Fujii Masao 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 a problem. However
Robert Haas writes:
> 2011/3/15 Devrim GÜNDÜZ :
>> 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 broken. Should we just not
> wo
2011/3/15 Devrim GÜNDÜZ :
> 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.
M
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
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> >
> > On 11/05/2010 06:54 PM, Tom Lane wrote:
> > > Andrew Dunstan writes:
> > >> The comment on the commit says:
> > >> EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,
> > >> rather than executing the INTO clause wit
Robert Haas wrote:
> On Fri, Mar 11, 2011 at 8:07 PM, Bruce Momjian 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 overhead usin
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
Princip
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, rathe
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 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 coul
Peter Eisentraut 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
>> for
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
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 i
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
log_min_duration_sta
Thom Brown wrote:
> On 15 March 2011 15:51, Thom Brown wrote:
> > On 15 March 2011 15:37, Bruce Momjian wrote:
> >> Thom Brown wrote:
> >>> On 15 March 2011 15:26, Bruce Momjian wrote:
> >>> >
> >>> > Applied. ?I did not bump the catalog version because they are just
> >>> > comments. ?I assume
On Sat, Mar 12, 2011 at 09:24:38PM +, Greg Stark wrote:
> On Sat, Mar 12, 2011 at 8:42 PM, Robert Haas 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 rule.
Quidquid
2011/3/15 Dmitriy Igrishin :
> 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:
http://archives.postgresql.org/pgsql-ha
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 t
On 15 March 2011 15:51, Thom Brown wrote:
> On 15 March 2011 15:37, Bruce Momjian wrote:
>> Thom Brown wrote:
>>> On 15 March 2011 15:26, Bruce Momjian wrote:
>>> >
>>> > Applied. ?I did not bump the catalog version because they are just
>>> > comments. ?I assume that is the right procedure.
>>>
2011/3/15 Robert Haas :
> On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule
> wrote:
>> 2011/3/15 Robert Haas :
>>> On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane wrote:
Pavel Stehule writes:
> there was a discussion about impact of number of keyword for parser
> speed. I did some syntheti
On 15 March 2011 15:37, Bruce Momjian wrote:
> Thom Brown wrote:
>> On 15 March 2011 15:26, Bruce Momjian wrote:
>> >
>> > Applied. ?I did not bump the catalog version because they are just
>> > comments. ?I assume that is the right procedure.
>>
>> *SNIP*
>>
>> >> + ? ? ? ? ? ? "COMMENT ON DATAB
Robert Haas 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, VALIDATE). I'm inclin
On Fri, Mar 11, 2011 at 3:10 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>> Andrew Dunstan 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 from the word "valid")? I
>> don't have any great
Thom Brown wrote:
> On 15 March 2011 15:26, Bruce Momjian 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
> >> connecti
On 15 March 2011 15:26, Bruce Momjian 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 administr
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 writes:
> > > Tom Lane wrote:
> > >> Yeah, I t
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 nec
On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule wrote:
> 2011/3/15 Robert Haas :
>> On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane wrote:
>>> Pavel Stehule 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 slown
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_chang
Excerpts from Tom Lane's message of mar mar 15 11:42:06 -0300 2011:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> Dimitri Fontaine 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
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
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 ti
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Dimitri Fontaine 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
Robert Haas 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. I think rather th
Tom Lane wrote:
> Dimitri Fontaine 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 cha
On Tue, Mar 15, 2011 at 10:25 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Tue, Mar 15, 2011 at 9:59 AM, Tom Lane wrote:
>> > Bruce Momjian writes:
>> >> I would like to apply the attached patch to git_changelog for use in
>> >> creating the major release notes. ?I specifically added thes
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
Robert Haas wrote:
> On Tue, Mar 15, 2011 at 9:59 AM, Tom Lane wrote:
> > Bruce Momjian 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 co
On Sat, Mar 12, 2011 at 1:36 AM, Tom Lane wrote:
> Robert Haas 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 VALIDATE, which is
>> already be
Tom Lane wrote:
> Bruce Momjian 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
Dimitri Fontaine 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 their meaning.
On Tue, Mar 15, 2011 at 9:59 AM, Tom Lane wrote:
> Bruce Momjian 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 Sho
Bruce Momjian 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 branch
> --r
Simon Riggs 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 patch
On Tue, Mar 15, 2011 at 06:03, sanjay verma 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 on Windows 2
49 matches
Mail list logo
