Jan Wieck <[EMAIL PROTECTED]> writes:
> In the case of a postmaster crash, I think something in the system
> is so wrong that I'd prefer an immediate shutdown.
I agree. Allowing existing backends to commit transactions after the
postmaster has died doesn't strike me as being that useful, and is
pr
Why? You can reconstruct it with a simple "ANALYZE" command. Dumping
and restoring would mean nailing down cross-version assumptions about
what it contains, which doesn't seem real forward-looking...
I seem to recall that people like that kind of thing so that the dump is
really the current stat
> > I don't think we want that. IMHO the preferred behavior if the
> > postmaster crashes should be like a "smart shutdown" --- you don't spawn
> > any more backends (obviously) but existing backends should be allowed to
> > run until their clients exit. That's how things have always worked
> > a
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Has anyone given any thought as to whether dumping and restoring
> pg_statistic is worthwhile?
Why? You can reconstruct it with a simple "ANALYZE" command. Dumping
and restoring would mean nailing down cross-version assumptions about
what it
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't think we want that. IMHO the preferred behavior if the
>> postmaster crashes should be like a "smart shutdown" --- you don't spawn
>> any more backends (obviously) but existing backends should be allowed to
>> run until their clien
I don't think so --- we weren't trying to use it as an actual column
datatype back then.
7.4 has a problem though :-( ... this is one of the "damn I wish we'd
caught that before release" ones, since it can't easily be fixed without
initdb. Reminds me that I need to get to work on making pg_upgrade
Joe Conway <[EMAIL PROTECTED]> writes:
> anyarray has been defined this way since 7.3 -- any concerns there?
I don't think so --- we weren't trying to use it as an actual column
datatype back then.
7.4 has a problem though :-( ... this is one of the "damn I wish we'd
caught that before release" o
> -Original Message-
> From: Mike Mascari [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 24, 2004 4:37 PM
> To: Dann Corbit
> Cc: Peter Eisentraut; PostgreSQL-development
> Subject: Re: [HACKERS] Is indexing broken for bigint columns?
>
>
> Dann Corbit wrote:
>
> > PostgreSQL is
Tom Lane wrote:
Hoo, I'm surprised no one noticed this during 7.4 development/testing.
The problem applies for any datatype that requires double alignment,
which includes int8, float8, and timestamp as well as most of the
geometric types. pg_statistic is declared as using type "anyarray",
and this
Dann Corbit wrote:
> > Dann Corbit wrote:
> > > http://www.phpbuilder.com/columns/smith20010821.php3?page=3
>
> http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-INT
>
> PostgreSQL is the only database that requires casts to do an index
> lookup.
This issue has been discussed on the
Dann Corbit wrote:
PostgreSQL is the only database that requires casts to do an index
lookup.
Possibly (quite probably) true, but you don't show any evidence that
SQL*Server, Oracle, or MySQL uses indexes either. Like I said
before, Tom (of course) already has a fix is already in the
developmen
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 24, 2004 3:38 PM
> To: Dann Corbit; PostgreSQL-development
> Subject: Re: [HACKERS] Is indexing broken for bigint columns?
>
>
> Dann Corbit wrote:
> > http://www.phpbuilder.com/columns/smit
Dann Corbit wrote:
> http://www.phpbuilder.com/columns/smith20010821.php3?page=3
http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-INT
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
> -Original Message-
> From: Mike Mascari [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 24, 2004 3:27 PM
> To: Dann Corbit
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Is indexing broken for bigint columns?
>
>
> Dann Corbit wrote:
> > http://www.phpbuilder.com/columns/smi
Shelby Cain <[EMAIL PROTECTED]> writes:
> The select statements return different data for
> most_commons_vals depending on whether n_distinct is
> included in the select clause or not.
> I only seem to get the behavior below against int8
> columns - but I haven't interated through every
> conceivab
Dann Corbit wrote:
http://www.phpbuilder.com/columns/smith20010821.php3?page=3
bigint indexes work fine. The queries probably referenced 32-bit
integer constants that were neither quoted nor CAST. I always start
bigint sequences at 5 billion. This ensures that client applications
aren't assumi
Title: Message
http://www.phpbuilder.com/columns/smith20010821.php3?page=3
On Tue, 2004-02-24 at 12:11, Richard Huxton wrote:
> On Tuesday 24 February 2004 16:11, Jonathan M. Gardner wrote:
> >
> > I've written a summary of my findings on implementing and using
> > materialized views in PostgreSQL. I've already deployed eagerly updating
> > materialized views on several v
Richard Huxton wrote:
On Tuesday 24 February 2004 16:11, Jonathan M. Gardner wrote:
I've written a summary of my findings on implementing and using
materialized views in PostgreSQL. I've already deployed eagerly updating
materialized views on several views in a production environment for a
company
On Tuesday 24 February 2004 16:11, Jonathan M. Gardner wrote:
>
> I've written a summary of my findings on implementing and using
> materialized views in PostgreSQL. I've already deployed eagerly updating
> materialized views on several views in a production environment for a
> company called RedWe
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> 1. Is there any reason to exclude underscore as the first char of a
> dollar quoting delimiter (after the $), e.g. $_foo_$? I'm happy either
> way, just want to be as liberal as is reasonable.
I think we had agreed to "same rules as identifiers, excep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've written a summary of my findings on implementing and using
materialized views in PostgreSQL. I've already deployed eagerly updating
materialized views on several views in a production environment for a
company called RedWeek: http://redweek.com
On Tue, 24 Feb 2004, Shridhar Daithankar wrote:
> http://www.osnews.com/printer.php?news_id=6136
That page gets a "please don't link to printer ready pages error" and
redirects to here:
http://www.osnews.com/story.php?news_id=6136
---(end of broadcast)---
On Tuesday 24 February 2004 21:15, scott.marlowe wrote:
> On Tue, 24 Feb 2004, Shridhar Daithankar wrote:
> > http://www.osnews.com/printer.php?news_id=6136
>
> That page gets a "please don't link to printer ready pages error" and
> redirects to here:
>
> http://www.osnews.com/story.php?news_id=613
I have 2 small questions.
1. Is there any reason to exclude underscore as the first char of a
dollar quoting delimiter (after the $), e.g. $_foo_$? I'm happy either
way, just want to be as liberal as is reasonable.
2. David Fetter asked me the other day if there was any limit on the
length of
George Weaver wrote:
I'm not sure of the detail behind winsup/cygwin/localtime.cc, but there are
problems with how Cygwin handles dates and times on Windows.
See http://www.cygwin.com/ml/cygwin/2003-07/msg01016.html.
If there is any relevance, I think it is imperative that the Win32 version
of Po
Claudio Natoli <[EMAIL PROTECTED]> writes:
> The join and rules failures don't look material, AFAICS, as the right rows
> are returned, just not necessarily in the expected order... is this an
> issue? Is the order mandated in these cases. Again, afaIcs, it isn't, but
> strictly I'm out of my depth
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Claudio Natoli said:
>> a) Provide "post-1970-only" versions of the expected regression test
>> output, for use under win32
>> b) Remove pre-1970 dates from *all* regression test files
>> c) Code up "pg_localtime" for win32
> I don't think a) and b) a
> > I will look at c) unless someone comes up with a better idea
> > or someone else gets in first.
>
> That would be great. Grab a hold of the cygwin sources.
> winsup/cygwin/localtime.cc claims that it is in the public
> domain... needs a closer look that I've given it, but might be a
> goo
> I will look at c) unless someone comes up with a better idea
> or someone else gets in first.
That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public domain... needs a
closer look that I've given it, but might be a good starting point.
Hi,
I've already subscribed my e-mail address to the
pgsql-hackers.
The method I've used to convert DBMirror to a
peer-to-peer replicator was two DBMirror instances
with one considered slave of other as the master.
Here, I've stopped the loop back by dropping the
trigger when INSERT, DELETE, UPDA
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Maybe there should be a provision similar to the stats collector's
check-for-read-ready-from-a-pipe?
the case of the bgwriter is a bit of a twist here. In contrast to the
collectors it is connected to the shared memory. So it c
http://www.osnews.com/printer.php?news_id=6136
Shridhar
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Claudio Natoli said:
>
>
> 7 of these fail pretty much *only* due to localtime returning NULL for
> pre-1970 dates, specifically: date, timestamp, timestampz, abstime,
> tinterval, horology, arrays. To resolve this, seems like there are 3
> solutions:
>
> a) Provide "post-1970-only" versions of the
Hi,
On Tuesday 24 February 2004 12:11, Claudio Natoli wrote:
> Hi all,
>
> my next TODO item for the Win32 port was to try to bring all the regression
> tests up.
>
> Pleased to report that, with a great deal of hackage + kludges (which I
> hope to refine and submit as patches for review over the
Hi all,
my next TODO item for the Win32 port was to try to bring all the regression
tests up.
Pleased to report that, with a great deal of hackage + kludges (which I hope
to refine and submit as patches for review over the next couple weeks), all
but 10 tests pass!
7 of these fail pretty much
36 matches
Mail list logo
