On Mon, Sep 26, 2005 at 09:54:46PM -0700, Joshua D. Drake wrote:
> >[ raised eyebrow... ] Has bizgres obtained a crystal ball from
> >somewhere? There is *no* way anyone could provide you anything that
> >has any legitimate claim on the name "PG 8.2" three months from now.
> >
> >
>
> I **think
Tom Lane wrote:
To my mind the main rationale for continuing to support 7.2 is that it
was the last pre-schema release, and so people whose apps haven't yet
been fixed to cope with schemas will be on their own once we drop it.
While each release has some portability gotchas, I don't think there
h
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> No, because you're thinking in terms of the backend environment, and
>> generally in the backend the answer to "when to use malloc directly"
>> is "never".
> Well, except before MemoryContext mechanism is set up?
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> No, because you're thinking in terms of the backend environment, and
> generally in the backend the answer to "when to use malloc directly"
> is "never".
>
Well, except before MemoryContext mechanism is set up? For example, the
functions(e.g., GUC, vfd) u
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> There are several places in both backend and tools that forget to check the
> return value of malloc(). For example(8.0.1),
> backend/port/dynloader/beos.c/pg_dlopen()
Dead port, probably not worth fixing.
> backend/bootstrap/bootstr
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no* way anyone could provide you anything that
has any legitimate claim on the name "PG 8.2" three months from now.
I **think** what he meant was that depending on what Bizgres has done in
the next three
There are several places in both backend and tools that forget to check the
return value of malloc(). For example(8.0.1),
backend/port/dynloader/beos.c/pg_dlopen()
backend/bootstrap/bootstrap.c/AddStr()
port/strdup.c/strdup()
bin/pg_dump/common.c/findParentsByOid()
...
I am t
Steve Atkins <[EMAIL PROTECTED]> writes:
> We'll be skipping 8.0 completely and the next step will probably be to
> 8.1.something (or possibly 8.2.something, depending on how bizgres
> looks in 3 months time).
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no
A nice pg_upgrade utility would make a big difference. Clearly an
in-place upgrade is possible, but maintaining is hard. There are two
broad ways of running a pg_upgrade project - one that is entirely
independent of the main codebase and one that puts requirements on the
main codebase developers
On Mon, Sep 26, 2005 at 09:27:28PM -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >
> >
> >>On Mon, 26 Sep 2005, Andrew Dunstan wrote:
> >>
> >>
> >>>Maybe something like this would do: "We will attempt to maintain support
> >>>of each maj
Tom,
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that. I'm hesitant to push that idea very hard myself, because it would
lo
The question at hand is when are we willing to pull the plug
completely and declare that even security holes and data-loss risks
won't get fixed.
It is definitely a sensitive issue because we (my community hat on) want
to make sure
and not alienate people because we won't support a version
On Mon, Sep 26, 2005 at 05:57:08PM -0400, Tom Lane wrote:
> I had originally been planning to back-port this fix:
> http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
> as far as 7.2. I've completed the back-port as far as 7.3, but
> found that 7.2 would be significantly more wor
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I think there should be levels of support.
There already are, in that only fairly major bugs get backpatched to the
way-back releases. I think that's right --- the older a release is, the
more it means that people still using it value stability over
This sounds reasonable to me ... I think it is more then most software
projects do, isn't it?
To translate that into reality: 7.2 (2002-02-04) would be dead already,
and 7.3 (2002-11-27) will be dead around the time we are likely to
release 8.1. Do people feel comfortable with that? It seem
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 26 Sep 2005, Tom Lane wrote:
>> I'd prefer to measure the time from the release of the follow-on
>> version, so I'd make it "2 years from release of following major
>> version"; that would give people a clearer idea of the time frame
>> in wh
On Mon, 26 Sep 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: "We will attempt to maintain support
of each major version for 3 years after its release, although this will
not always be possible
Jim C. Nasby wrote:
If a database is created with a 64 bit version of initdb, would a 32bit
backend be able to talk to it? Likewise, would a backend compiled by a
different compiler be able to?
Not in my experience at least from going 32 bit intel to 64bit opteron.
If there was some kind
Ron Peacetree <[EMAIL PROTECTED]> writes:
> Let's start by assuming that an element is <= in size to a cache line and a
> node fits into L1 DCache. [ much else snipped ]
So far, you've blithely assumed that you know the size of a cache line,
the sizes of L1 and L2 cache, and that you are working
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: "We will attempt to maintain support
of each major version for 3 years after its release, although this will
not always be possible. After th
Alvaro Herrera wrote:
> On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote:
>> Joshua D. Drake wrote:
>
>>> Autovacuum is integrated into the backend for 8.1
>> Can I set the autovacuum parameter per table instead of per
>> engine ?
>
> Yes.
Finally :-)
good work.
Regards
Gaetano
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 26 Sep 2005, Andrew Dunstan wrote:
>> Maybe something like this would do: "We will attempt to maintain support
>> of each major version for 3 years after its release, although this will
>> not always be possible. After that time any major s
[ Forgot to answer this part ]
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> On Mon, 26 Sep 2005, Tom Lane wrote:
>> I have a corporate need to keep supporting 7.3, at least to the extent
>> of critical bug fixes, because Red Hat is still on the hook to support
>> that version in RHEL3 for awhile lo
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Gerbil's looking better lately:
> http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=gerbil&br=REL8_0_STABLE
Yeah. We've been poking at it off-list, and it seems that the problem
was a local build failure due to not having a clean copy of the
repository (
I looked at the recently noted problem that pgxs builds only work
if the installation paths recorded in Makefile.global are accurate;
which pretty much breaks our claim to supporting relocatable
installations.
What I propose we do about this is change the path setup section
of Makefile.global to l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 3. How to show that a value is continued? As you can see below I use
>...
> I remember a discussion on this before but couldn't find it in the
> archives. Either a reference or some other hints would be appreciated.
I think we liked the "+" charac
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Tom Lane wrote:
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like "X amount of time after the release of the
following major version". But X probably has to depend on how big
the compatibility gotchas are
Tom Lane wrote:
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like "X amount of time after the release of the
following major version". But X probably has to depend on how big
the compatibility gotchas are in the following version, so we're still
rea
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> ""Jim C. Nasby"" <[EMAIL PROTECTED]> wrote
>> If a database is created with a 64 bit version of initdb, would a 32bit
>> backend be able to talk to it? Likewise, would a backend compiled by a
>> different compiler be able to?
> The key problem I believ
Gerbil's looking better lately:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=gerbil&br=REL8_0_STABLE
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
""Jim C. Nasby"" <[EMAIL PROTECTED]> wrote
> If a database is created with a 64 bit version of initdb, would a 32bit
> backend be able to talk to it? Likewise, would a backend compiled by a
> different compiler be able to?
>
The key problem I believe is the serials of ALIGNOF macros. Especially f
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> There are some 7.3 users around (I remember some on Slony lists, etc),
> therefore we should keep supporting it. But maybe we can announce that
> "7.3 will become unsupported after XXX time" so that people will know
> before we abandon the support. The
If a database is created with a 64 bit version of initdb, would a 32bit
backend be able to talk to it? Likewise, would a backend compiled by a
different compiler be able to?
If there was some kind of incompatability, would the backend just refuse
to start, or would it start and start silently tras
Hi,
On Mon, 26 Sep 2005, Tom Lane wrote:
This brings up the question of whether we should officially abandon
support for 7.2 and/or later branches. I don't think anyone is planning
on supporting old branches forever, but when do we stop?
I have a corporate need to keep supporting 7.3, at le
I had originally been planning to back-port this fix:
http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
as far as 7.2. I've completed the back-port as far as 7.3, but found
that 7.2 would be significantly more work because the API of
heap_fetch() would need to change from what i
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> So what happens if you attempt to put a value greater than 2^32 into a
> bigint on a non-int64 platform?
You get the same error as if you tried to store a value greater than 2^64.
regards, tom lane
---(e
Ron,
Having rested my brain for the last few days, your theory made for
interesting reading... Rather than argue the technical specs, I'd
love to see an implementation :)
-JonahOn 9/26/05, Dann Corbit <[EMAIL PROTECTED]> wrote:
> -Original Message-> From: [EMAIL PROTECTED] [mailto:pgsql-
On Sat, Sep 24, 2005 at 12:13:11PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
> >> For that matter, we can't even guarantee that they work at all: not
> >> all platforms even *have* int64 types.
>
> > What platfor
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Ron Peacetree
> Sent: Monday, September 26, 2005 10:47 AM
> To: pgsql-hackers@postgresql.org; pgsql-performance@postgresql.org
> Subject: [HACKERS] [PERFORM] A Better External Sort?
>
>
Tom Lane wrote:
Speaking as a pgFoundry admin, I would say if they aren't actively
maintained we don't want them either. pgFoundry is not a dumping ground
for modules that are dying.
I didn't say they were dying --- the ones we thought were dead, we
already dropped. I was responding t
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Is there any particular reason why psql doesn't re-run a query that
> failed due to disconnect from the server after re-connecting? I've
> thought maybe it's because it might somehow be dangerous, but I can't
> think of any case where that's actually tru
> Changes
> ---
> Win32 signal handling patch (Magnus)
Unless someone else steps up to doing this one, please remove it from
the list. I will not have time to dig into this patch before 8.1.
//Magnus
---(end of broadcast)---
TIP 9: In versions
Bruce Momjian wrote:
[ Joe, would you review this? ]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
The patch itself is pret
Is there any particular reason why psql doesn't re-run a query that
failed due to disconnect from the server after re-connecting? I've
thought maybe it's because it might somehow be dangerous, but I can't
think of any case where that's actually true.
--
Jim C. Nasby, Sr. Engineering Consultant
>From: Ron Peacetree <[EMAIL PROTECTED]>
>Sent: Sep 24, 2005 6:30 AM
>Subject: Re: [HACKERS] [PERFORM] Releasing memory during External sorting?
>
>... the amount of IO done is the most
>important of the things that you should be optimizing for in
>choosing an external sorting algorithm.
>
>
>
>Si
On Mon, Sep 26, 2005 at 01:23:03PM -0500, Jim C. Nasby wrote:
> Is there any particular reason why psql doesn't re-run a query that
> failed due to disconnect from the server after re-connecting? I've
> thought maybe it's because it might somehow be dangerous, but I can't
> think of any case where
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The modules proposed to be moved out aren't actively maintained now;
>> if they were we'd probably be keeping them in core.
> Speaking as a pgFoundry admin, I would say if they aren't actively
> maintained we don't want them either.
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
/contrib move to pgfoundry
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new servers.
The modules proposed to be moved out a
On Mon, Sep 26, 2005 at 01:13:08PM -0400, Christopher Petrilli wrote:
> On 9/26/05, David Fetter <[EMAIL PROTECTED]> wrote:
> > I've run into something that concerns me. It's pretty much an 8.2
> > issue, but I'm hoping to stimulate some discussion on it. It's
> > PostgreSQL's log files. Right n
Should that be marked as a beginner TODO?
On Thu, Sep 22, 2005 at 11:04:23PM -0400, Bruce Momjian wrote:
>
> Added to TODO:
>
> * Add options to pg_config to show the share_dir, sysconfdir,
> pkgincludedir, and localedir
>
>
> --
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>> I have a client with a database that contains 4000 relations according
>>> to vacuum verbose, and \d in psql is painfully slow. In particular...
It's presumably mostly in the pg_table_is_visible() calls. Not sure if
we can do much to speed those up,
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> * Add options to pg_config to show the share_dir, sysconfdir,
>> pkgincludedir, and localedir
> Should that be marked as a beginner TODO?
It could, but I think it's going to get DONE in the next few days as
a necessary step in fixing the pgxs relocata
Andreas Pflug <[EMAIL PROTECTED]> writes:
> - query is truncated due to UDP restrictions.
Are you confusing the logs with pg_stat_activity?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
David Fetter wrote:
...log file formats in 8.0
* CSV
* YAML
* XML
* Piped logs, as Apache can do
* DB handle. I know this one will be controversial.
[...]
1. Am I the only one who would wants an option for machine-readable logs?
I'd very much like a format that can be easily loaded into
On Sun, Sep 25, 2005 at 10:10:22AM +0300, Hannu Krosing wrote:
> On L, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
> > I have a client with a database that contains 4000 relations according
> > to vacuum verbose, and \d in psql is painfully slow. In particular...
> >
> >-> Seq Scan on pg_c
As a work-around, you can use the scripts at
http://cvs.distributed.net/viewcvs.cgi/stats-sql/tools/
On Thu, Sep 22, 2005 at 02:16:58PM -0400, Jonathan Beit-Aharon wrote:
>
> Hi,
> I'm not a member of this list, so please CC me on responses and
> discussion.
> After a system crash PostgreSQL star
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
- query is truncated due to UDP restrictions.
Are you confusing the logs with pg_stat_activity?
Not confused. I'm talking about the case where statement logging is
enabled, I could have mentioned that...
Regards,
Andreas
--
On Sat, Sep 24, 2005 at 08:25:30PM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
>
> >Would it be difficult to vacuum as part of a dump? The reasoning behind
> >this is that you have to read the table to do the dump anyway, so it
> >would be a good time to be able to piggy-back other operati
On Sun, Sep 25, 2005 at 11:50:14AM -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Perhaps VACUUM could send some statistics after each N pages and this
> > would then be available through something similar to pg_statistics
> > table.
>
> Why not just have it send some text
On Sun, Sep 25, 2005 at 10:10:22AM +0300, Hannu Krosing wrote:
> > Also, not sure if this matters, but they're occasionally getting errors
> > like 'Did not find relation named "table that exists"' (where 'table
> > that exists' is the name of some table that is in the catalog) from \d.
> > Does an
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> /contrib move to pgfoundry
> Well pgFoundry isn't ready to have a load of code that is
> that actively maintained put on it. It still needs to be moved to
> its new servers.
The modules proposed to be moved out aren't actively maintained now;
if t
David Fetter wrote:
Folks,
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant effort to parse. For
exam
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Joshua D. Drake wrote:
> >
> >>>/contrib move to pgfoundry
> >>
> >>Is this actually happening?
> >
> >
> > Josh has talked about it, but not sure where he is.
>
> Well pgFoundry isn't ready to have a load of code that is
> that actively maintai
Bruce Momjian wrote:
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new serve
Interesting. I am thinking we could put markers like '|' in the log
output, and then have some secondary process either remove them or add
special formatting to match the requested output format.
---
David Fetter wrote:
> Fo
David Fetter wrote:
Simple logging is a default that should probably not change, but I'm
thinking that for people who want to find something out from the logs,
we could see about a kind of plugin architecture which would enable
things like:
* CSV
* YAML
* XML
* Piped logs, as Apache can do
*
> -Original Message-
> From: Ron Peacetree [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 24, 2005 3:31 AM
> To: Dann Corbit; pgsql-hackers@postgresql.org; pgsql-
> [EMAIL PROTECTED]
> Subject: RE: [HACKERS] [PERFORM] Releasing memory during External
sorting?
>
> From: Dann Corbit
Tom Lane wrote:
Hm, so the proposal is "round unless that would produce 24:00:00, in
which case truncate"? Seems a bit ugly but it would follow the letter
of the spec, and avoid rejecting inputs that we used to accept. It's
still not very clear what to do with '23:59:60.9' though.
I'd handl
Joshua D. Drake wrote:
>
> > /contrib move to pgfoundry
>
> Is this actually happening?
Josh has talked about it, but not sure where he is.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard
On 9/26/05, David Fetter <[EMAIL PROTECTED]> wrote:
> I've run into something that concerns me. It's pretty much an 8.2
> issue, but I'm hoping to stimulate some discussion on it. It's
> PostgreSQL's log files. Right now, they're (sometimes just barely ;)
> human-readable, but they take signific
/contrib move to pgfoundry
Is this actually happening?
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.comman
[ Joe, would you review this? ]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> b) If SD is TIME WITHOUT TIME ZONE, then TV is SV, with
>> implementation-defined rounding or truncation if necessary.
>>
>> So it's "implementation-defined" what we do.
> IMHO Since 23:59:59.99 probably means "the last milliseconds o
Folks,
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant effort to parse. For
example, pqa, a very cleve
Here are the open items for 8.1:
PostgreSQL 8.1 Open Items
=
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.
Changes
---
Win32 signal handli
Patch applied. Thanks.
---
Marko Kreen wrote:
> On Fri, Aug 12, 2005 at 10:27:16PM -0400, Bruce Momjian wrote:
> > Where are we going with this patch? It doesn't test specific OS's known
> > to fail.
>
> I hoped people m
We have what may be a bug in beta2. We have two databases running beta2,
one on Linux and one on Windows. The hardware is identical. The
configurate files are identical. They are being fed identical streams
of data modifications (primarily inserts, very few deletes). We've been
running this se
On Mon, 26 Sep 2005, Michael Paesold wrote:
to be something else than the libpq expects. But how to fix it?! Has the
protocol change or what?
Umm, I think the protocol version is up to 3 or 4 now. I think libpq
supports all the way back to 7.0, I don't know if anyone tests earlier
than that.
On Mon, 26 Sep 2005, Tom Lane wrote:
> b) If SD is TIME WITHOUT TIME ZONE, then TV is SV, with
> implementation-defined rounding or truncation if necessary.
>
> So it's "implementation-defined" what we do.
Truncation would avoid the problem but of course loses some of t
Tom Lane wrote:
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If T
On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote:
> Joshua D. Drake wrote:
> > Autovacuum is integrated into the backend for 8.1
>
> Can I set the autovacuum parameter per table instead of per
> engine ?
Yes.
--
Alvaro Herrera Architect, http://www.Enterp
Tom Lane wrote:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
>> On Mon, 26 Sep 2005, Tom Lane wrote:
>>> No, I think the usual notation for a leap-second is '23:59:60'.
>>> We do allow 60 in the seconds field for this purpose.
>
>> Yes, and it can go up to 23:59:60.99 (depending on how many
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If TD is the datetime da
Jochem van Dieten <[EMAIL PROTECTED]> writes:
> On 9/26/05, Dennis Bjorklund wrote:
>> One reason is because it's what the standard demand.
> Could you cite that? The only thing I can find in the SQL standard is
> that the hour field in an INTERVAL can not exceed 23, not datetimes.
SQL99 has
Joshua D. Drake wrote:
> Hannu Krosing wrote:
>
>> On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote:
>>
>>
>>
>>> Actually this also probably would not gain you much in 8.1
>>> as vacuum in theory is already dealing with itself.
>>>
>>
>> Interesting. Could you explain it in a more deta
On Mon, 26 Sep 2005, Tom Lane wrote:
=?iso-8859-2?Q?Micha=B3_J=EAczalik?= <[EMAIL PROTECTED]> writes:
I have a very old postgres 6.4 installation. I'm trying to connect to it
from a fresh, up-to-date Debian-host, but I'm constantly getting (from DBI
and PHP as well) this error message:
# ./u
On 9/26/05, Dennis Bjorklund wrote:
> On Sun, 25 Sep 2005, Tom Lane wrote:
>>
>> Alternatively: why are we forbidding the value 24:00:00 anyway? Is
>> there a reason not to allow the hours field to exceed 23?
>
> One reason is because it's what the standard demand.
Could you cite that? The only th
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 26 September 2005 16:01
> To: Dave Page
> Cc: Андрей Репко; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Server process exited with unexpected
> status 128.
>
> "Dave Page" writes:
> >> [mailto:[EMAIL P
Tom Lane <[EMAIL PROTECTED]> writes:
> That's an urban legend. There never have been, and never will be, two
> leap seconds instituted in the same minute. We really should reject
> anything larger than '23:59:60'.
I don't understand. The last second of a normal minute goes from 59.0 to
59.999
"Dave Page" writes:
>> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
>>> max_stack_depth = 65536 # min 100, size in KB
>>
>> Hmm, maybe this is the problem. Are we sure Windows will
>> allow a 64M stack?
> Looks like we used 4MB in the backend by default:
> http://archives.po
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 26 September 2005 15:47
> To: Андрей Репко
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Server process exited with unexpected
> status 128.
>
> [ looking again... ]
[ looking again... ]
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?= <[EMAIL PROTECTED]>
writes:
> max_stack_depth = 65536 # min 100, size in KB
Hmm, maybe this is the problem. Are we sure Windows will allow a 64M stack?
regards, tom lane
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?= <[EMAIL PROTECTED]>
writes:
> When I try to execute the next SQL statement, sever was crashed:
> DELETE FROM ma_data WHERE id in (-1,212803,. );
> ... - is 500k text like id separated by ",". Its about 10 values.
I wouldn't be too s
On Mon, 26 Sep 2005, Tom Lane wrote:
> > Yes, and it can go up to 23:59:60.99 (depending on how many fractional
> > seconds one want).
>
> That's an urban legend. There never have been, and never will be, two
> leap seconds instituted in the same minute. We really should reject
> anything
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Mon, 26 Sep 2005, Tom Lane wrote:
>> No, I think the usual notation for a leap-second is '23:59:60'.
>> We do allow 60 in the seconds field for this purpose.
> Yes, and it can go up to 23:59:60.99 (depending on how many fractional
> seconds on
On Mon, 26 Sep 2005, Tom Lane wrote:
> > Actually, I think there is a case where 24:00 is a proper time. Isn't
> > it used for adding leap seconds ?
>
> No, I think the usual notation for a leap-second is '23:59:60'.
> We do allow 60 in the seconds field for this purpose.
Yes, and it can go up
On Mon, Sep 26, 2005 at 10:28:48AM +0200, Michal Jeczalik wrote:
> Heh, that's what I'm currently doing, but it's not so easy to compile 6.4
> on a new system. configure states that the compiler cannot create
> executables, but I ripped this check out of it. Anyway, something goes
> wrong while
Hello pgsql-hackers,
When I try to execute the next SQL statement, sever was crashed:
DELETE FROM ma_data WHERE id in (-1,212803,. );
... - is 500k text like id separated by ",". Its about 10 values.
Run from pgplsql function, like EXECUTE st;.
postgresql-2005-09-25_00.log:
200
=?iso-8859-2?Q?Micha=B3_J=EAczalik?= <[EMAIL PROTECTED]> writes:
> I have a very old postgres 6.4 installation. I'm trying to connect to it
> from a fresh, up-to-date Debian-host, but I'm constantly getting (from DBI
> and PHP as well) this error message:
> # ./update_dns.pl
> DBI connect('dbnam
Dave Cramer <[EMAIL PROTECTED]> writes:
> Actually, I think there is a case where 24:00 is a proper time. Isn't
> it used for adding leap seconds ?
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
I suppose there's another pos
1 - 100 of 107 matches
Mail list logo
