[EMAIL PROTECTED] schrieb:
On 1/4/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
...
Pulling branches from
anonvcvs regularly might be burdensome bandwidth-wise. So, like you
say, a
local mirror would be beneficial for patch testing.
Right some sort o
> >> Hello all,
> >>
> >> a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a
> >> Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x
> >> version and we even tried to install 8.2 and it did not work.
> >>
> >> Ok, the problem is: after installing all the files t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The only argument I can think of is that it allows applications to be
> >> sloppy about parsing a SQL script into individual commands before they
> >> send it. (I think initdb may be guilty of exactly that BTW...)
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The only argument I can think of is that it allows applications to be
>> sloppy about parsing a SQL script into individual commands before they
>> send it. (I think initdb may be guilty of exactly that BTW...) At the
>> same time you
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What value is allowing multiple queries via PQexec()
>
> The only argument I can think of is that it allows applications to be
> sloppy about parsing a SQL script into individual commands before they
> send it. (I think initdb may be
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
> Gavin Sherry wrote:
> >
> > With PLM, you could test patches against various code branches. I'd
> > guessed Mark would want to provide this capability. Pulling branches from
> > anonvcvs regularly might be burdensome bandwidth-wise. So, like you say, a
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What value is allowing multiple queies via PQexec()
The only argument I can think of is that it allows applications to be
sloppy about parsing a SQL script into individual commands before they
send it. (I think initdb may be guilty of exactly that BTW..
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> >>> Is there a good reason to not let psql -c behave exactly like psql from
> >>> STDIN?
> >>
> >> Backwards compatibility, mostly --- there seems to be a conside
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
>>> Is there a good reason to not let psql -c behave exactly like psql from
>>> STDIN?
>>
>> Backwards compatibility, mostly --- there seems to be a considerable
>> risk of subtly breaki
Gavin Sherry wrote:
>
> With PLM, you could test patches against various code branches. I'd
> guessed Mark would want to provide this capability. Pulling branches from
> anonvcvs regularly might be burdensome bandwidth-wise. So, like you say, a
> local mirror would be beneficial for patch testing.
Andrew Dunstan wrote:
> Simon Riggs wrote:
> > I'm not clear about the difference between the unapplied patches list
> > and the hold list. What is the significance of the two lists?
> >
>
> AIUI, the hold list is those patches providing new features that were
> held over between 8.2 feature f
On 1/4/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
> Gavin Sherry wrote:
> > On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> >
> >> 1. Pull source directly from repositories (cvs, git, etc.) PLM
> >> doesn't really track actually scm repositories. It req
Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Hm, that's an interesting point. psql's -c just shoves its whole
> >> argument string at the backend in one PQexec(), instead of dividing
> >> at semicolons as psql does with normal input.
>
> > Is there a
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
> Gavin Sherry wrote:
> > On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> >
> >> 1. Pull source directly from repositories (cvs, git, etc.) PLM
> >> doesn't really track actually scm repositories. It requires
> >> directories of source code to be traversed
Gavin Sherry wrote:
> On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
>
>> 1. Pull source directly from repositories (cvs, git, etc.) PLM
>> doesn't really track actually scm repositories. It requires
>> directories of source code to be traversed, which are set up by
>> creating mirrors.
>
> It seems
On Thu, 4 Jan 2007, Alvaro Herrera wrote:
> Gavin Sherry wrote:
> > On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> >
> > > 1. Pull source directly from repositories (cvs, git, etc.) PLM
> > > doesn't really track actually scm repositories. It requires
> > > directories of source code to be traver
Gavin Sherry wrote:
> On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
>
> > 1. Pull source directly from repositories (cvs, git, etc.) PLM
> > doesn't really track actually scm repositories. It requires
> > directories of source code to be traversed, which are set up by
> > creating mirrors.
>
> It
On Thu, 2007-01-04 at 21:41 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > S'OK, just thought it was funny I'd been doing it backwards all this
> > time: Actively been replacing tabs with spaces. :-)
>
> That explains why your patches always seemed to be so weird to me
LOL
> spacing-wise
Simon Riggs wrote:
> On Thu, 2007-01-04 at 16:01 -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > > Minor request for clarification:
> > > > I read in the Developer's FAQ that tabs should be interpreted as 4
> > > > spaces. ...and also that pgind
On Thu, 04 Jan 2007 22:55:52 +
Dave Page <[EMAIL PROTECTED]> wrote:
> Magnus Hagander wrote:
>
> > See the FAQ at http://www.postgresql.org/docs/faqs.FAQ_windows.html#3.3
> > (question 3.3).
>
> I discussed this briefly with Robert on IM yesterday - he told me the
> account was installer cre
On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> 1. Pull source directly from repositories (cvs, git, etc.) PLM
> doesn't really track actually scm repositories. It requires
> directories of source code to be traversed, which are set up by
> creating mirrors.
It seems to me that a better approach
In another thread I was made aware that current protocol may not be
easily extensible (if at all), and so the backend-data a certain driver
needs may not be so easily added.
http://www.postgresql.org/docs/current/static/protocol-message-formats.html
So if there is not already a roadmap for thi
Magnus Hagander wrote:
> Andreas 'ads' Scherbaum wrote:
>> Hello all,
>>
>> a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a
>> Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x
>> version and we even tried to install 8.2 and it did not work.
>>
>> Ok, the pr
Andreas 'ads' Scherbaum wrote:
> Hello all,
>
> a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a
> Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x
> version and we even tried to install 8.2 and it did not work.
>
> Ok, the problem is: after installing all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane replied:
>> So as a general rule, the system tables should be considered a special
>> case as far as transactional activity? To be more precise, you are saying
>> that a system table must be locked in access exclusive mode before any
>> chan
Florian Weimer <[EMAIL PROTECTED]> writes:
> Ah, does this mean that each WAL entry gets its own checksum?
Right.
> (I had assumed that PostgreSQLs WAL checksumming was justified by the
> partial write issue. The wild store could easily occur with a heap
> page, too, and AFAIK, tuples, aren't ch
On Thu, 2007-01-04 at 16:01 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > Minor request for clarification:
> > > I read in the Developer's FAQ that tabs should be interpreted as 4
> > > spaces. ...and also that pgindent replaces tabs as spaces.
>
* Tom Lane:
> I think short burst errors are fairly likely: the kind of scenario I'm
> worried about is a wild store corrupting a word of a WAL entry while
> it's waiting around to be written in the WAL buffers.
Ah, does this mean that each WAL entry gets its own checksum? In this
case, Adler32
Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Minor request for clarification:
> > I read in the Developer's FAQ that tabs should be interpreted as 4
> > spaces. ...and also that pgindent replaces tabs as spaces.
>
> No, it does the opposite (or I would hope so anyway).
Sorry, t
Andrew Dunstan wrote:
> Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >
> >> Minor request for clarification:
> >> I read in the Developer's FAQ that tabs should be interpreted as 4
> >> spaces. ...and also that pgindent replaces tabs as spaces.
> >>
> >
> > No, it does th
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Tom Lane:
>> There's a lot of math behind CRCs but AFAIR Adler's method is pretty
>> much ad-hoc.
> Correct me if I'm wrong, but the main reason for the WAL CRC is to
> detect partial WAL writes (due to improper caching, for instance).
Well, that's *
* Tom Lane:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>> Have you tried switching to Adler32 instead of CRC32?
>
> Is anything known about the error detection capabilities of Adler32?
> There's a lot of math behind CRCs but AFAIR Adler's method is pretty
> much ad-hoc.
Correct me if I'm wrong,
OSDL had a tool called PLM with a primary goal to test patches against
the Linux kernel. It applied them and built them on multiple
platforms. It's a pretty simple idea and here are some links to what
it did; the systems appear to still be up for the moment so here are a
couple of links to what
Martijn van Oosterhout writes:
> On Mon, Jan 01, 2007 at 05:53:35PM -0500, Tom Lane wrote:
>> One way we could handle this is to say that reverse-sort indexes are
>> implemented by adding explicit catalog entries for reverse-sort opclasses,
>> with no additions to the underlying btree index mechan
[EMAIL PROTECTED] wrote:
On 1/4/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 1/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
>> > That also happens. The only way I can see of ensuring it does not
>> happen
On Thu, 2007-01-04 at 13:17 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Wouldn't it be better to issue ReadyForQuery() and then issue the stat
> > stuff in the gap between processing?
>
> To me, "ready for query" means "ready for query", not "I think I might
> be ready
On 1/4/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 1/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
>> > That also happens. The only way I can see of ensuring it does not
>> happen
>> > would be to auto-proc
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Wouldn't it be better to issue ReadyForQuery() and then issue the stat
> stuff in the gap between processing?
To me, "ready for query" means "ready for query", not "I think I might
be ready soon". Otherwise you could argue for trying to move the
messag
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Oneliner that adds the capability to deal with defines that set string
> values - " needs to be quoted in XML.
Applied, thanks.
regards, tom lane
---(end of broadcast)---
TIP 6:
On Thu, 2007-01-04 at 12:13 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote:
> >> "It works most of the time" doesn't exactly satisfy me.
>
> > It seemed safer to allow a very rare error through to the next level of
> > error
[EMAIL PROTECTED] wrote:
On 1/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
> That also happens. The only way I can see of ensuring it does not
happen
> would be to auto-process all patch submissions.
Sounds a good idea. Patch farm anyon
In postgres.c main loop, I note that we issue ReadyForQuery() *after*
updating pgstat and setting the ps display.
Wouldn't it be better to issue ReadyForQuery() and then issue the stat
stuff in the gap between processing?
That way we would be less likely to care about pgstat and the ps,
potenti
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote:
>> "It works most of the time" doesn't exactly satisfy me.
> It seemed safer to allow a very rare error through to the next level of
> error checking rather than to close the door so tight that recovery
Florian Weimer <[EMAIL PROTECTED]> writes:
> Have you tried switching to Adler32 instead of CRC32?
Is anything known about the error detection capabilities of Adler32?
There's a lot of math behind CRCs but AFAIR Adler's method is pretty
much ad-hoc.
regards, tom lane
On Thu, 2007-01-04 at 17:58 +0100, Florian Weimer wrote:
> * Simon Riggs:
>
> >> Surely not. Otherwise even the "on" setting is not really a defense.
> >
> > Only when the CRC is exactly zero, which happens very very rarely.
>
> Have you tried switching to Adler32 instead of CRC32?
No. Please e
* Simon Riggs:
>> Surely not. Otherwise even the "on" setting is not really a defense.
>
> Only when the CRC is exactly zero, which happens very very rarely.
Have you tried switching to Adler32 instead of CRC32?
--
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH
On 1/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
> That also happens. The only way I can see of ensuring it does not happen
> would be to auto-process all patch submissions.
Sounds a good idea. Patch farm anyone? Auto apply/make check?
On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> Recovery can occur with/without same setting of wal_checksum, to avoid
> >>> complications from
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, that's an interesting point. psql's -c just shoves its whole
>> argument string at the backend in one PQexec(), instead of dividing
>> at semicolons as psql does with normal input.
> Is there a good reason to not let psql -c
Gregory Stark <[EMAIL PROTECTED]> writes:
> This is pre-operator-families, I thought "preferred type" was new with them.
No, preferred types have been around for a very long time.
regards, tom lane
---(end of broadcast)---
T
In response to Tom Lane <[EMAIL PROTECTED]>:
> Bill Moran <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >>> Might be more robust to say
> >>> if (trace_temp_files >= 0)
>
> > I specified in the GUC config that minimum allowable value is -1.
>
> I'd still tend to go
Hi,
Tom Lane wrote:
Hm, that's an interesting point. psql's -c just shoves its whole
argument string at the backend in one PQexec(), instead of dividing
at semicolons as psql does with normal input. And so it winds up as
a single transaction because postgres.c doesn't force a transaction
commi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I believe this is happening because the numeric is being cast to float8 and
>> then the float4-float8 cross-data-type operator is being used. It seems like
>> it would be preferable to cast it to float4 and use
Gregory Stark <[EMAIL PROTECTED]> writes:
> I believe this is happening because the numeric is being cast to float8 and
> then the float4-float8 cross-data-type operator is being used. It seems like
> it would be preferable to cast it to float4 and use the non-cross-data-type
> operator. They're bo
Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
Minor request for clarification:
I read in the Developer's FAQ that tabs should be interpreted as 4
spaces. ...and also that pgindent replaces tabs as spaces.
No, it does the opposite (or I would hope so anyway).
Sure look
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> Recovery can occur with/without same setting of wal_checksum, to avoid
>>> complications from crashes immediately after turning GUC on.
>>
>> Surely not.
On Thu, 2007-01-04 at 10:00 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > In this thread, I outlined an idea for reducing cost of WAL CRC checking
> > http://archives.postgresql.org/pgsql-hackers/2006-10/msg01299.php
> > wal_checksum = on (default) | off
>
> This still see
Am Donnerstag, 4. Januar 2007 16:36 schrieb Tom Lane:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Hm, that's an interesting point. psql's -c just shoves its whole
> argument string at the backend in one PQexec(), instead of dividing
> at semicolons as psql does with normal input. And so i
I noticed this odd discrepancy:
postgres=# select -0.999::numeric(3,3)::float4 = -0.999::numeric(3,3);
?column?
--
f
(1 row)
I believe this is happening because the numeric is being cast to float8 and
then the float4-float8 cross-data-type operator is being used. It seems like
it wou
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> I've just found the stumbling block: the -c option of psql wraps all in
> a transaction, as man psql says:
> ...
> Thank you for clarification, I wouldn't have expected that (especially
> because CREATE DATABASE itself says, it cannot be run insid
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Minor request for clarification:
> I read in the Developer's FAQ that tabs should be interpreted as 4
> spaces. ...and also that pgindent replaces tabs as spaces.
No, it does the opposite (or I would hope so anyway).
regards, tom
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> In this thread, I outlined an idea for reducing cost of WAL CRC checking
> http://archives.postgresql.org/pgsql-hackers/2006-10/msg01299.php
> wal_checksum = on (default) | off
This still seems awfully dangerous to me.
> Recovery can occur with/without
Bill Moran <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>>> Might be more robust to say
>>> if (trace_temp_files >= 0)
> I specified in the GUC config that minimum allowable value is -1.
I'd still tend to go with Andrew's suggestion because it makes this
particular bit
On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
> Simon Riggs wrote:
> > I'm not clear about the difference between the unapplied patches list
> > and the hold list. What is the significance of the two lists?
> >
>
> AIUI, the hold list is those patches providing new features that were
Simon Riggs wrote:
I'm not clear about the difference between the unapplied patches list
and the hold list. What is the significance of the two lists?
AIUI, the hold list is those patches providing new features that were
held over between 8.2 feature freeze and 8.2 branch. Since they have
Minor request for clarification:
I read in the Developer's FAQ that tabs should be interpreted as 4
spaces. ...and also that pgindent replaces tabs as spaces.
Trouble is, there are tabs throughout the code. What gives?
Should I be replacing tabs as spaces, or leaving them alone? At all?
Only in
I have tested with local-enabled environment and found a bug. Included
is the new version of patches.
Teodor, Oleg, what do you think about these patches?
If ok, shall I commit to CVS head?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi,
>
> Here are patches against tsearch2 with CVS head. Currently
On Mon, 2007-01-01 at 19:56 -0500, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > Bruce Momjian wrote:
> > > I will start processing the patches held for 8.3 this week or next, now
> > > that the holiday break is over:
> > >
> > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> > >
> >
Hi,
Tom Lane wrote:
It should happen automatically at commit of the CREATE DATABASE ... and
you'd not be able to see the pg_database row before that anyway. So I'm
not clear on what you're worried about.
I've just found the stumbling block: the -c option of psql wraps all in
a transaction, a
69 matches
Mail list logo
