Tom Lane a écrit :
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?
It certainly will show up if you do it before the packagers pull their
CVS copies.
No, it will
Guillaume Lelarge wrote:
Tom Lane a écrit :
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?
It certainly will show up if you do it before the packagers pull their
CVS
Dave Page a écrit :
Guillaume Lelarge wrote:
Tom Lane a écrit :
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?
It certainly will show up if you do it before the
Zdenek Kotala wrote:
Marko Kreen wrote:
On 9/11/07, Zdenek Kotala [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
This is crashing because of the crippled OpenSSL on some version
of Solaris. Zdenek Kotala posted a workaround for that, I am
cleaning it but have not found the time to finalize it.
Ühel kenal päeval, E, 2007-09-10 kell 11:01, kirjutas Alvaro Herrera:
Mark Mielke wrote:
Simon Riggs wrote:
ISTM we would be able to do this fairly well if we implemented
Index-only columns. i.e. columns that don't exist in the heap, only in
an index.
Taken to the extreme, all columns
On Tue, 2007-09-11 at 18:56 -0400, Bruce Momjian wrote:
Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
8.0.14, 7.4.18, 7.3.20. The CVS branches are nearly ready. The
releases will happen sometime early next week. The packagers have been
contacted.
The following bug fix
Tom Lane wrote:
While editing Bruce's README.HOT documentation I ran into a problem.
I had idly added the following text after thinking about the different
sorts of snapshots we use:
---
Another unpleasant consequence is that it is no longer very meaningful to
use SnapshotAny in an index
All windows boxes are failed on tsdicts test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2007-09-12%2007:00:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-09-12%2003:00:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baijidt=2007-09-11%2022:00:01
with
Teodor Sigaev wrote:
All windows boxes are failed on tsdicts test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2007-09-12%2007:00:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-09-12%2003:00:01
Do you mean something like this:
./src/tools/msvc/Install.pm
*** ./src/tools/msvc/Install.pm.origWed Sep 12 16:30:25 2007
--- ./src/tools/msvc/Install.pm Wed Sep 12 16:31:29 2007
***
*** 66,71
--- 66,72
GenerateTimezoneFiles($target,$conf);
Correct, that fixes the problem. I've verified it on my machine, and
committed the patch.
//Magnus
On Wed, Sep 12, 2007 at 04:32:57PM +0400, Teodor Sigaev wrote:
Do you mean something like this:
./src/tools/msvc/Install.pm
*** ./src/tools/msvc/Install.pm.origWed Sep 12 16:30:25 2007
---
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, the proposed HOT code in indexam.c that special-cases SnapshotAny
is a crock ...
It was written under the assumption that all tuples in a HOT chain have
the same index key, which isn't true after CREATE INDEX as you pointed
Hi
When I initially proposed to use the latest *committed* xid as the xmax instead
of ReadNewTransactionId(), I believed that this would cause tuples created by a
later aborted transaction not to be vacuumed until another transaction (with a
higher xid) commits later. The idea was therefore
Dave Page [EMAIL PROTECTED] writes:
Guillaume Lelarge wrote:
Is it Marc's job to sync the translation on PostgreSQL CVS with those
from the pgtranslation project ? I remember this is a part of the build
process but I don't know who does this.
No, thats Peter.
Peter usually does it --- in
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 12 Sep 2007, Tom Lane wrote:
Argh! Can someone quote chapter and verse from the ICC manual about
this? I was just following what Sergey said was the approved spelling
of the switch ...
Here are the docs for the two options.
So why have they
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Guillaume Lelarge wrote:
Is it Marc's job to sync the translation on PostgreSQL CVS with those
from the pgtranslation project ? I remember this is a part of the build
process but I don't know who does this.
No, thats Peter.
Peter usually
Simon Riggs [EMAIL PROTECTED] writes:
The following bug fix has not yet been applied to CVS
http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php
Frankly, this looks much more like it creates a bug than fixes one.
I have not looked at all of the original thread, but this adds a wart
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter usually does it --- in theory any committer could, but he actually
knows what to do and the rest of us would have to study ;-)
Study or figure it out? If it hasn't already been it should be
documented as part of the release process.
Florian G. Pflug [EMAIL PROTECTED] writes:
Therefore, I suggest that we rename latestCompletedXid to latestCommittedXid,
and update it only on commits. Admittedly, this won't bring any measurable
performance benefit in itself (it will slightly reduce the average snapshot
size, though), but not
All,
A Hibernate developer pointed out the following odd behavior to me in 8.2.1:
create table test ( test1 text );
create table test2 ( test_col text );
create rule test_insert as on insert to test do instead insert into test2
values ( NEW.test1 ) RETURNING test2.test_col;
postgres=# insert
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Therefore, I suggest that we rename latestCompletedXid to latestCommittedXid,
and update it only on commits. Admittedly, this won't bring any measurable
performance benefit in itself (it will slightly reduce the average snapshot
size,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Berkus wrote:
All,
A Hibernate developer pointed out the following odd behavior to me in 8.2.1:
create table test ( test1 text );
create table test2 ( test_col text );
create rule test_insert as on insert to test do instead insert into
Josh Berkus [EMAIL PROTECTED] writes:
A Hibernate developer pointed out the following odd behavior to me in 8.2.1:
create table test ( test1 text );
create table test2 ( test_col text );
create rule test_insert as on insert to test do instead insert into test2
values ( NEW.test1 ) RETURNING
Tom,
What the RETURNING clause in the rule does is let you define the data
that should be returned if the rewritten INSERT had a returning clause
to start with.
Hmmm. Aha, that works:
postgres=# insert into test values ( 'mary' ) returning test1;
test1
---
mary
So, this should
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
A Hibernate developer pointed out the following odd behavior to me in 8.2.1:
create table test ( test1 text );
create table test2 ( test_col text );
create rule test_insert as on insert to test do instead insert into test2
values (
I find the HOT patch's representation of redirected line pointers pretty
klugy. It's got a magic offset number to mean one thing, and a magic
length number to mean something else, and the assumption that either of
these can't correspond to a real offset or length seems pretty weak.
(It would fail
Richard Huxton [EMAIL PROTECTED] writes:
Tom Lane wrote:
What the RETURNING clause in the rule does is let you define the data
that should be returned if the rewritten INSERT had a returning clause
to start with.
Sorry - haven't got a CSV download here, or I'd check myself. Does this
just
Tom,
Josh, this *is* documented; see the CREATE RULE reference page for full
details, and there's at least passing references here:
http://developer.postgresql.org/pgdocs/postgres/rules-update.html#RULES-UPD
ATE-VIEWS
Yeah, it's just hard to find since it's buried in an offhand example in a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am unsure if I should backpatch to 8.1: the code in cluster.c has
changed, and while it is relatively easy to modify the patch, this is a
rare bug and nobody has reported it in CLUSTER (not many people clusters
temp tables, it
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of
Tom Lane a écrit :
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter usually does it --- in theory any committer could, but he actually
knows what to do and the rest of us would have to study ;-)
Study or figure it out? If it hasn't already been it should be
documented as part of
Tom Lane [EMAIL PROTECTED] writes:
LP_UNUSED 0
LP_NORMAL 1
LP_REDIRECT 2
LP_DEAD 3
This seems hardly any uglier than the way the code stands today, and
certainly a lot less ugly than what the current HOT patch proposes.
Comments?
If I
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
LP_UNUSED 0
LP_NORMAL 1
LP_REDIRECT 2
LP_DEAD 3
This seems hardly any uglier than the way the code stands today, and
certainly a lot less ugly than what the current HOT patch proposes.
Gregory Stark [EMAIL PROTECTED] writes:
If I understand correctly this still leaves open the possibility of
implementing in the future quick pruning as we've been speculating about. We
could represent that with a line pointer which is LP_DEAD but still has a
length and offset. I'm not sure we
On 9/13/07, Tom Lane [EMAIL PROTECTED] wrote:
What I'm thinking is that we should instead do this by extending the use
of the lp_flags field. lp_flags is two bits, which we currently define
as independent LP_USED and LP_DELETE bits, but in fact LP_DELETE is
never used in heap pages. (It is
Zdenek Kotala wrote:
I would like to inform, that New Zealand changed DST rules and new
timezone files are available. See
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended
Patch for head attached. I kept zic.c untouched, but I think it
Pavan Deolasee [EMAIL PROTECTED] writes:
Sounds good to me. I saw you committed this change. Do you want me
to update HOT patch to use this or you are already doing that ?
I'll clean up my own mess ;-)
regards, tom lane
---(end of
On 9/13/07, Bruce Momjian [EMAIL PROTECTED] wrote:
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
You mean May 1, 2007 ;-)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
38 matches
Mail list logo
