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
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
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
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
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:
> 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:
> > 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
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
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
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
---
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
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
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
> > >
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
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
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 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, 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
-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
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
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
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
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
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
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
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
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
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 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
-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
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
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, 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" 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, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> > 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
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
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 <[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.
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
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
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:
> 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
[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
"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
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
60 matches
Mail list logo
