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,
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
Some of these
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
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
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
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
held
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 of code
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 same
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 lane
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 inside a
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
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 it
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 seems awfully
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. Otherwise even the
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 looks
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 both
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 the
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
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 with Andrew's
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)---
TIP
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 behave
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 crashes immediately
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?
I'm
* 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 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 explain
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
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,
[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 anyone?
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
message emission
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-process all patch
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 soon. Otherwise
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
would not
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 checking rather
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:
[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
would be
Martijn van Oosterhout kleptog@svana.org 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
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
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 the opposite (or I would
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, the mistake
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.
No, it does
-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
change is
* 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, but the
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 *a*
* 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 is
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
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 the
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 problem is:
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
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
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 created.
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 pgindent replaces tabs as
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 :-)
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 to
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 traversed, which
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 to me that
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, which are
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 good reason to
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 requires
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 freeze and
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.
I
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 breaking people's
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 considerable
risk of subtly
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...)
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
local
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 guilty
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 could
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...) At the
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 the installer wants
[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 of
69 matches
Mail list logo
