Tom Lane wrote:
"Michael Paesold" <[EMAIL PROTECTED]> writes:
Can you remember regressions in stable branches in the past?
Yes. Relax. If this were a data-corruption-in-the-backend issue,
I might feel that it mandates an immediate re-release. But it isn't
and it doesn't. You'll note that M
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Can you remember regressions in stable branches in the past?
Yes. Relax. If this were a data-corruption-in-the-backend issue,
I might feel that it mandates an immediate re-release. But it isn't
and it doesn't. You'll note that Michael M. himself
[moved to hackers]
Is this a regression in the stable branches? If so, shouldn't we do a new
release rather immediately? What do others think about this situation?
Can you remember regressions in stable branches in the past? How were those
it handled? I think "waiting for months" (i.e. for th
Robert Creager <[EMAIL PROTECTED]> writes:
> Is there anything I might be able to do (without the test case) that
> would help figure out what's happening?
oprofile stats would be enlightening, perhaps.
I'm particularly interested in why 7.4 is behaving better than newer
versions --- that does no
When grilled further on (Thu, 13 Oct 2005 22:44:54 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > I've been having this problem since trying to upgrade from 7.4.1 to 8.03,
and
> > now 8.1.
>
> Can you put together a test case that other people cou
Robert Creager <[EMAIL PROTECTED]> writes:
> I've been having this problem since trying to upgrade from 7.4.1 to 8.03, and
> now 8.1.
Can you put together a test case that other people could use to
reproduce it?
regards, tom lane
---(end of broadca
Bruce Momjian writes:
> I assume it is related to these two TODO entries:
> o Merge hardwired timezone names with the TZ database; allow either
> kind everywhere a TZ name is currently taken
Yes, the point here is that the datetime token table has a bunch of
hardwired zone name
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Shall I add JST to our zic database?
No. We have to update that from the upstream database every release;
maintaining our own private mods is not acceptable. If you want JST
to be recognized as a zic timezone, go lobby the upstream maintainers
for it.
A general ability to be able to dump views as if they were tables would
be more broadly applicable methinks?
Merlin Moncure wrote:
I have a situation where I need to hack pg_dump not to dump columns with
a particular name. If this is of interest to the community I can spend
a little extra effo
Tatsuo Ishii wrote:
> > > Also, JST doesn't work anymore, but JST9 does.
> >
> > JST9 is valid per the POSIX rules. JST isn't listed as a zone name in
> > the zic database, so it's not valid. (Try "Japan" instead.)
>
> Shall I add JST to our zic database? It's quite confusing that
> "2005-10-14
> > Also, JST doesn't work anymore, but JST9 does.
>
> JST9 is valid per the POSIX rules. JST isn't listed as a zone name in
> the zic database, so it's not valid. (Try "Japan" instead.)
Shall I add JST to our zic database? It's quite confusing that
"2005-10-14 12:00 JST" is allowed while ""SET
I've been having this problem since trying to upgrade from 7.4.1 to 8.03, and
now 8.1.
It's a dual Xenon machine:
Linux annette.stortek.com 2.4.22-26mdkenterprise #1 SMP Wed Jan 7 07:10:39 MST
2004 i686 unknown unknown GNU/Linux
PostgreSQL version is:
Magnus Hagander wrote:
> Has anybody tried building beta2 or later with MSVC? It doesn'?t work
> for me - it builds fine, but whenever I run with it I get a coredump
> from it whenever I try to connect.
>
> If I revert it to the 8.0 version of port/getaddrinfo.c, things work
> again.
>
> The prob
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Back out this because of fear of changing error strings:
> >
> > This makes the error messages for PREPARE TRANSACTION, COMMIT PREPARED
> > etc. match the docs, which talk about "transaction identifier" not
> > "gid" or "global transaction identi
Thanks for the well wishes.
It sounds like you were addressing a slightly different problem --
more ambitious than what I propose tackle do as a first step.
If I understand you, you were trying to develop your own
predictive costing formulas based on plans. I'm merely talking
about a tool to eval
Tom,
> I think my preference is to allow '24:00:00' (but not anything larger)
> as a valid input value of the time datatypes. This for two reasons:
> * existing dump files may contain such values
> * it's consistent with allowing, eg, '12:13:60', which we
> allow even though i
Bruce Momjian writes:
> Tom Lane wrote:
>> I think my preference is to allow '24:00:00' (but not anything larger)
>> as a valid input value of the time datatypes.
> Is this a must-fix for 8.1?
No, since it's a pre-existing issue, but it's the kind of thing that
should be changed during a major r
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > On Fri, 23 Sep 2005, Tom Lane wrote:
> >> postgresql-f
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Hi,
>
> I basically have a functional version for al
Bruce Momjian writes:
> Where are we on this?
We haven't decided what to do.
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes. This for two reasons:
* existing dump files may contain such values
* it's consistent
Tom Lane wrote:
> Bruce Momjian writes:
> > Where are we on this?
>
> We haven't decided what to do.
>
> I think my preference is to allow '24:00:00' (but not anything larger)
> as a valid input value of the time datatypes. This for two reasons:
> * existing dump files may contain such va
Where are we on this? I see current CVS behaving the same as below,
except the last query now returns 24:00:00.
---
Tom Lane wrote:
> Inserting into a time field with limited precision rounds off, which
> is good except for
Jim C. Nasby wrote:
> http://archives.postgresql.org/pgsql-bugs/2005-02/msg00135.php
>
> I think it may have been a bit early to disable pthread python support
> (http://archives.postgresql.org/pgsql-hackers/2005-09/msg01136.php), as
> Python was working fine on buildfarm member platypus. Maybe it
I haven't seen any replies to this, so I guess you are left with either
hacking psql yourself or getting Cygwin folks to fix it. Sorry.
---
Bill Bartlett wrote:
> Back in 2003 Bruce Momjian proposed adding a flag (-I) to ps
On Thu, Oct 13, 2005 at 08:36:39PM +0100, Dave Page wrote:
> When we first discussed this I posted a very simple example 'cd /'
> which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
> expected, quite possibly for the reason you suggest. Although the /
> is accepted, I don't believe
On Thu, 13 Oct 2005 14:20:46 -0500
Kevin Grittner <[EMAIL PROTECTED]> wrote:
> I can confirm that the patch was in the snapshot I picked up this
> morning at about 10:30 CDT. We've been using it since then and
> have not seen the problem in spite of attempting to provoke it with
> database vacuum
"Dave Page" writes:
> When we first discussed this I posted a very simple example 'cd /'
> which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
> expected, quite possibly for the reason you suggest. Although the / is
> accepted, I don't believe it can be called reliable as it obvio
On Thu, Oct 13, 2005 at 01:52:10PM -0500, Kevin Grittner wrote:
> Thanks, Josh, for the feedback.
>
> It sounds as though you are more focused on picking up costing
> problems which happen during production -- which is clearly
> valuable, but addresses a somewhat different set of needs than
> I wa
Dave Page wrote:
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32
Besides, Windows has accepted the forwa
On Thu, 13 Oct 2005 15:09:58 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > Might this be the same problem as the recent thread "database vacuum from
> > cron hanging" where Tom is: "I'm busy volatile-izing all the code in
> > bufmgr.c ... should be able
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32
> Besides, Windows has accepted the forward slash as directo
I can confirm that the patch was in the snapshot I picked up this
morning at about 10:30 CDT. We've been using it since then and
have not seen the problem in spite of attempting to provoke it with
database vacuums.
-Kevin
>>> Tom Lane <[EMAIL PROTECTED]> 10/13/05 2:09 PM >>>
Robert Creager <[E
Applied. Thanks.
---
Simon Riggs wrote:
> On Wed, 2005-09-28 at 14:26 -0400, Bruce Momjian wrote:
> > I have added a section to the top of the WAL docs explaining caching and
> > reliability issues:
> >
> > http://cand
I have a situation where I need to hack pg_dump not to dump columns with
a particular name. If this is of interest to the community I can spend
a little extra effort and work up a patch. I'd be curious to see if
anyone else thinks this is worthwhile.
Why would I want to do this? I use a global
Dave Page wrote:
We should probably document that pg_config may not work reliably with non-mingw
tools in that case. Microsoft code may or may not do what is expected with
front slashes.
BTW Thomas - I thought you said \\ did work when you were testing options for
me, or was that just msys
Robert Creager <[EMAIL PROTECTED]> writes:
> Might this be the same problem as the recent thread "database vacuum from cron
> hanging" where Tom is: "I'm busy volatile-izing all the code in bufmgr.c ...
> should be able to commit a fix soon."?
Seems reasonably likely, seeing that the original repo
On Thu, Oct 13, 2005 at 02:53:09PM -0400, Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
> > I do have a workaround in place that makes it work for me now. I do
> > $(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
> > platform for pgxs on Win32 is MinGW, per
Thanks, Josh, for the feedback.
It sounds as though you are more focused on picking up costing
problems which happen during production -- which is clearly
valuable, but addresses a somewhat different set of needs than
I was looking at. That said, it seems like there is potential to share
signifca
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I do have a workaround in place that makes it work for me now. I do
> $(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
> platform for pgxs on Win32 is MinGW, perhaps it should output forward
> slashes anyway.
I've already app
Dave Page wrote:
We should probably document that pg_config may not work reliably with non-mingw
tools in that case. Microsoft code may or may not do what is expected with
front slashes.
BTW Thomas - I thought you said \\ did work when you were testing options for
me, or was that just msys ra
I have a vacuum process kicked of by autovacuum that appears hung and causing
general grief. When I put too many queries at the db in this state, the Context
Switches cruises up to ~90k and stay there. Queries that normally take < 1
second are up to over a minute. The autovacuum thread has been
-Original Message-
From: "Tom Lane"<[EMAIL PROTECTED]>
Sent: 13/10/05 18:23:13
To: "Thomas Hallgren"<[EMAIL PROTECTED]>
Cc: "pgsql-hackers@postgresql.org"
Subject: Re: [HACKERS] pg_config --pgxs on Win32
>> The mingw GNU Make is not too happy about the
>> double backslashes.
> I said
On Wed, Oct 12, 2005 at 11:49:47PM -0400, Tom Lane wrote:
> That would certainly be better if possible, but AFAIK it's not.
> (Perhaps there is a gcc-specific hack, but certainly not one that's
> portable to all compilers. "volatile" is the only tool the C standard
> gives us.)
Indeed. The linux
Bruce Momjian wrote:
> Back out this because of fear of changing error strings:
>
> This makes the error messages for PREPARE TRANSACTION, COMMIT PREPARED
> etc. match the docs, which talk about "transaction identifier" not
> "gid" or "global transaction identifier".
I say make the change anyway
On Wed, 12 Oct 2005 18:44:50 +0100
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-09-14 at 13:32 -0400, Tom Lane wrote:
> > I wrote:
> > > Another thought came to mind: maybe the current data layout for LWLocks
> > > is bad. Right now, the spinlock that protects each LWLock data struct
> >
Bruce Momjian writes:
> I am playing with our allowed timezone settings and saw a few strange
> things. It understands "EST5EDT", but how does it understand "XYT5ABT"?
Because the code in src/timezone does what the POSIX standard says it
must do. The relevant man page on my HPUX box says
Kevin,
I'm looking at trying to fix some clear flaws in costing which cause
of our real-world queries to choose sub-optimal plans under PostgreSQL.
It's clear that there needs to be a tool to analyze the accuracy of
costing for a variety of queries, both to direct any efforts to fix
problems and
On Friday 09 September 2005 08:46, Stephan Szabo wrote:
> On Fri, 9 Sep 2005, Tom Lane wrote:
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > Is there a case other than a before trigger updating a row we will want
> > > to act upon later in the statement where we'll get a row with xmax of
> > >
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Something changed very recently in the output from pg_config --pgxs
> command on Win32. It now outputs double backslash everywhere instead
> of forward slashes. The mingw GNU Make is not too happy about the
> double backslashes.
I said that was a bad i
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA
I am playing with our allowed timezone settings and saw a few strange
things. It understands "EST5EDT", but how does it understand "XYT5ABT"?
test=> set timezone = 'XYT5ABT';
SET
test=> SELECT current_timestamp;
now
---
Something changed very recently in the output from pg_config --pgxs command on Win32. It now
outputs double backslash everywhere instead of forward slashes. The mingw GNU Make is not
too happy about the double backslashes. I do:
export PGXS := $(dir $(shell pg_config --pgxs))
and now it yields
Tom Lane wrote:
> Bruce Momjian writes:
> > Neil Conway wrote:
> >> If a function's return value for a particular set of arguments could
> >> change within a single table scan, the function is volatile -- ISTM
> >> xslt_process() clearly falls within that definition.
>
> > My thought was that a w
Tom Lane wrote:
> Bruce Momjian writes:
> > Well, should be marked as VOLATILE? A web lookup?
>
> Yes. Its value is determined by factors outside the database, so
> it has to be categorized as volatile.
OK, done.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@ca
Bruce Momjian writes:
> Well, should be marked as VOLATILE? A web lookup?
Yes. Its value is determined by factors outside the database, so
it has to be categorized as volatile.
regards, tom lane
---(end of broadcast)---
T
Tom Lane wrote:
> Bruce Momjian writes:
> > Attached is a cleaned up version of the patch (without wrapping). The
> > change is to use "$(CXX) $(CFLAGS)" instead of $(COMPILER). Does this
> > change break OS/X?
>
> Since our configure doesn't define CXX, I'm having a hard time imagining
> how i
Bruce Momjian writes:
> Neil Conway wrote:
>> If a function's return value for a particular set of arguments could
>> change within a single table scan, the function is volatile -- ISTM
>> xslt_process() clearly falls within that definition.
> My thought was that a web page lookup is going to be
Neil Conway wrote:
> On Wed, 2005-12-10 at 23:46 -0400, Bruce Momjian wrote:
> > Agreed. I have changed them both to stable. I think xslt_process()
> > should be stable because it is unlikely you would want a URL's contents
> > to change inside a transaction
>
> Why is it "unlikely"?
>
> If a f
David Fetter wrote:
Dept of second thoughts: actually, perhaps see if you can generate
the pg_description entries from the C comments in the
include/catalog header files. There's already a strong motivation
to hold those to shorter-than-a-line length, whereas the column
descriptions in catalogs
Ouch! I just remembered locale and character sets and
encoding. I can't even begin to get my head around what to
do with those, unless it is just to make the tool agnostic
regarding those issues and test against a variety of setups.
Does that seem adequate?
I flash back to my first attempts to u
60 matches
Mail list logo
