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
"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 broadcast
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
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.
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 s
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 HO
"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?
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
>> documen
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
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 tabl
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
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 thi
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
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 ( NEW.
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 prob
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 ) RET
-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
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
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 in
"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),
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 p
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 w
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 usuall
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 ha
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
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 modif
"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
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
> -
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);
GenerateTsearchFile
Teodor Sigaev wrote:
All windows boxes are failed on tsdicts test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2007-09-12%2007:00:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-09-12%2003:00:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baiji&
All windows boxes are failed on tsdicts test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2007-09-12%2007:00:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-09-12%2003:00:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baiji&dt=2007-09-11%2022:00:01
wit
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 i
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
Ü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
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.
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
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
CV
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.
38 matches
Mail list logo
