On Thu, Nov 6, 2008 at 3:36 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> Wow thanks! That's very helpful (though it might have been more
> fair to your time if you just kicked it back to me saying "rewrite
> the docs" so they make sense)!
>
Maybe ... but I figured it would take more time to fully e
Hi Simon,
On Wed, Nov 5, 2008 at 11:01 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> I would think we would want this integrated into the server as an
> additional special backend, similar to WALWriter. If it works for now,
> that's fine for other testing. This is not an especially difficult
> chan
2008/11/6 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> Pavel Stehule wrote:
>>
>> postgres=# select version();
>> version
>>
>> --
>> PostgreSQL 8.3.
Charlie Savage wrote:
A couple of months ago I noted that 8.3.4 doesn't compile on Vista using
MingW+msys under certain conditions:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01496.php
8.3.5 has the same problem.
Attached are two one line patches that fix it.
Sorry, I attached
A couple of months ago I noted that 8.3.4 doesn't compile on Vista using
MingW+msys under certain conditions:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01496.php
8.3.5 has the same problem.
Attached are two one line patches that fix it.
Thanks,
Charlie
--- libpq-int.h 2008-11-
Hi all,
Attached test shows a regression in analyze command.
Expected rows in an empty table is 2140 even after an ANALYZE is executed
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
psql (8.4devel)
You
Hi
I have completed the review for Patch "Table command", Here is results
1. The patch actually implements that.
2. The feature work as advertised.
3. So far, I have not found any possible dangers that can be caused by this
pacth
4. Since it is just an alternative to "select * from
While working on the join elimination patch, I was going through the
trigger code and found quite a bit of nastiness in regard to naming
and variable repurposing related to the addition of replication roles
in 8.3. The most obvious issue is that tgenabled was switched from a
bool to char to suppor
On Fri, Oct 31, 2008 at 7:42 PM, Emmanuel Cecchet <[EMAIL PROTECTED]> wrote:
> Hi Nikhil,
>
i'm looking at this one:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
> Here are a couple of questions:
> - How do you ALTER the table to repartition it?
fair question. but the patch was ad
Tom Lane wrote:
Why is InitIndexFreeSpaceMap coded to test for the FSM file already
existing? AFAICS it cannot yet exist and it should be an error anyway
if it does.
Hmm. The FSM file can exist, if the index isn't created anew, but
truncated and rebuilt. However, we normally create a new relf
OK, here's an updated version...
1. Use IncrBufferRefCount() so that we can do unconditional
ReleaseBuffers elsewhere. I'm not sure this is really any simpler,
and although IncrBufferRefCount() is pretty cheap, it's certainly not
as cheap as a NULL pointer test.
2. Consolidate a bunch of logic i
>>> >> Problem is how to move tuple from page to another and keep indexes in
>>> >> sync.
>>> >> One solution is to perform some think like "update" operation on the
>>> >> tuple.
>>> >> But you need exclusive lock on the page and pin counter have to be zero.
>>> >> And
>>> >> question is where
On Wed, Nov 05, 2008 at 04:06:11PM -0800, Bryce Cutt wrote:
> The error is causes by me Asserting against the wrong variable. I
> never noticed this as I apparently did not have assertions turned on
> on my development machine. That is fixed now and with the new patch
> version I have attached al
The error is causes by me Asserting against the wrong variable. I
never noticed this as I apparently did not have assertions turned on
on my development machine. That is fixed now and with the new patch
version I have attached all assertions are passing with your query and
my test queries. I add
Andrew Dunstan wrote:
KaiGai Kohei wrote:
*** 80,88
HeapTupleHeaderGetNatts(oldheader)) &&
((newheader->t_infomask & ~HEAP_XACT_MASK) ==
(oldheader->t_infomask & ~HEAP_XACT_MASK)) &&
! memcmp(((char *)newheader) + offsetof(HeapTupleHeaderData,
t_b
Pavel Stehule wrote:
postgres=# select version();
version
--
PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.3.2 20
KaiGai Kohei wrote:
*** 80,88
HeapTupleHeaderGetNatts(oldheader)) &&
((newheader->t_infomask & ~HEAP_XACT_MASK) ==
(oldheader->t_infomask & ~HEAP_XACT_MASK)) &&
! memcmp(((char *)newheader) + offsetof(HeapTupleHeaderData,
t_bits),
!
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the
new
one before comparing?
OK, that
I am working on a set returning function and have a question about
switching memory contexts. Basically, what I want to know is whether
memory allocated in one context can be referenced when a different
context is current. The docs give examples like:
if (SRF_IS_FIRSTCALL())
{
fun
Kevin Grittner wrote:
> An idea for a possible enhancement to PostgreSQL: allow creation of a
> temporary table without generating any disk I/O. (Creating and
> dropping a three-column temporary table within a database transaction
> currently generates about 150 disk writes).
Most of these are ca
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Wed, Nov 05, 2008 at 09:41:52PM +, Gregory Stark wrote:
>> "Robert Haas" <[EMAIL PROTECTED]> writes:
>>
>> >> Problem is how to move tuple from page to another and keep indexes in
>> >> sync.
>> >> One solution is to perform some think
--On Mittwoch, November 05, 2008 19:20:07 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
No, I think that should just be a no-op. We don't for instance throw
error when you ALTER OWNER to the existing owner.
Hmm okay. When looking at this i was remembering the discussion we had for
SET SCHEMA a
Why is InitIndexFreeSpaceMap coded to test for the FSM file already
existing? AFAICS it cannot yet exist and it should be an error anyway
if it does. The smgrexists probe is hardly free, so losing it would be
good.
regards, tom lane
--
Sent via pgsql-hackers mailing lis
Bernd Helmle <[EMAIL PROTECTED]> writes:
> * We really should error out when trying to copy into the same tablespace
> the database already lives in.
No, I think that should just be a no-op. We don't for instance throw
error when you ALTER OWNER to the existing owner.
> * The current implementa
Kevin Grittner wrote:
An idea for a possible enhancement to PostgreSQL: allow creation of a
temporary table without generating any disk I/O. (Creating and
dropping a three-column temporary table within a database transaction
currently generates about 150 disk writes).
If some circumstances don
On Wed, Nov 5, 2008 at 16:00, Kevin Grittner
<[EMAIL PROTECTED]> wrote:
> An idea for a possible enhancement to PostgreSQL: allow creation of a
> temporary table without generating any disk I/O. (Creating and
> dropping a three-column temporary table within a database transaction
> currently gener
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> This patch:
>> As noted by Andrew Gierth, there's really no need any more to force a junk
>> filter to be used when INSERT or SELECT INTO has a plan that returns raw
>> disk tuples.
> made this test case crash:
> CREATE TABLE xtable (padding char(
--On Mittwoch, November 05, 2008 01:10:22 +0100 Guillaume Lelarge
<[EMAIL PROTECTED]> wrote:
Tom Lane a écrit :
Guillaume Lelarge <[EMAIL PROTECTED]> writes:
Should I provide a complete new patch with Bernd's and Tom's changes?
Please --- it's better if you integrate it since you know the p
An idea for a possible enhancement to PostgreSQL: allow creation of a
temporary table without generating any disk I/O. (Creating and
dropping a three-column temporary table within a database transaction
currently generates about 150 disk writes).
If some circumstances don't make it feasible to a
On Wed, Nov 05, 2008 at 09:41:52PM +, Gregory Stark wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>
> >> Problem is how to move tuple from page to another and keep indexes in sync.
> >> One solution is to perform some think like "update" operation on the tuple.
> >> But you need exclusive
"Robert Haas" <[EMAIL PROTECTED]> writes:
>> Problem is how to move tuple from page to another and keep indexes in sync.
>> One solution is to perform some think like "update" operation on the tuple.
>> But you need exclusive lock on the page and pin counter have to be zero. And
>> question is whe
> Problem is how to move tuple from page to another and keep indexes in sync.
> One solution is to perform some think like "update" operation on the tuple.
> But you need exclusive lock on the page and pin counter have to be zero. And
> question is where it is safe operation.
But doesn't this prob
Tom Lane wrote:
It's kind of annoying to introduce a search when it's so seldom needed,
though. How about something like
/* fast path for common case */
if (key[i].sk_attno == irel->rd_index->indkey.values[i])
key[i].sk_attno = i + 1;
else
... sea
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
made this test case crash:
CREATE TABLE xtable (padding char(2000)) WITH OIDS;
INSERT INTO xtable VALUES('1');
ALTER TABLE xtable SET WITHOUT OIDS;
INSERT INTO xtable (SELECT * FROM xtable);
with assertion failure:
TRAP: FailedAssertion("!(!(t
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout napsal(a):
>> Is this really such a big deal? You do the null-update on the last
>> tuple of the page and then you do have enough room. So Phase one moves
>> a few tuples to make room. Phase 2 actually converts the pages inplace.
>
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Basically, this comment and code in genam.c:
> ...
> is wrong, because it assumes that there's only one scankey per index
> column, but that's not true for toast_fetch_datum_slice(), which uses
> two scankeys for the chunkid, to fetch a range. Atta
On Wed, Nov 05, 2008 at 09:04:04AM -0800, David E. Wheeler wrote:
> On Nov 5, 2008, at 6:40 AM, Kenneth Marshall wrote:
>
>> I installed and ran the citext tests both with and without
>> the patch and had failures both times. The patch applied
>> cleanly and the "make;make install" completed withou
Heikki Linnakangas wrote:
> made this test case crash:
>
> CREATE TABLE xtable (padding char(2000)) WITH OIDS;
> INSERT INTO xtable VALUES('1');
> ALTER TABLE xtable SET WITHOUT OIDS;
> INSERT INTO xtable (SELECT * FROM xtable);
>
> with assertion failure:
>
> TRAP: FailedAssertion("!(!(tup->t_da
This patch:
commit 35ad25ad66fa3999bbc0bb59ca13cef3d750fb07
Author: Tom Lane <[EMAIL PROTECTED]>
Date: Sat Jul 26 19:15:35 2008 +
As noted by Andrew Gierth, there's really no need any more to force a junk
filter to be used when INSERT or SELECT INTO has a plan that returns raw
Martijn van Oosterhout napsal(a):
On Wed, Nov 05, 2008 at 03:04:42PM +0100, Zdenek Kotala wrote:
Greg Stark napsal(a):
It is exceptional case between V3 and V4 and only on heap, because you save
in varlena. But between V4 and V5 we will lost another 4 bytes in a page
header -> page header will
A bug was introduced a while ago by this patch:
> commit 447f7364dd7227a32b58a2aff24f587dd7d7051a
> Author: Tom Lane <[EMAIL PROTECTED]>
> Date: Sat Apr 12 23:14:21 2008 +
>
> Create new routines systable_beginscan_ordered,
systable_getnext_ordered,
> systable_endscan_ordered that
Tom Lane wrote:
I wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
OK, that will be easy enough. I assume I should still put InvalidOid
back again afterwards, in case someone downstream relies on it.
Can't imagine what ...
Actually ... what *could* change in the f
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the new
one before comparing?
OK, that will be easy enough. I
I wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> OK, that will be easy enough. I assume I should still put InvalidOid
>> back again afterwards, in case someone downstream relies on it.
> Can't imagine what ...
Actually ... what *could* change in the future is that we might support
UPDATE
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... however, it seems reasonable to assume that the *new* tuple is just
>> local storage. Why don't you just poke the old tuple's OID into the new
>> one before comparing?
> OK, that will be easy enough. I assume I should still put I
(Sorry for the cross posting)
Command Prompt is sponsoring "multiple PostgreSQL version installation
with RPMs" project, which has been in my todo list for a really long
time. The aim is to be able to install different PostgreSQL versions
with RPMs, like Debian folks have been doing for a long ti
Tom Lane wrote:
I wrote:
This method is utterly, utterly unacceptable; you're probably trashing
the contents of a disk buffer there.
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the new
one be
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The attached patch sets the OID to InvalidOid for the duration of the
memcmp if the HEAP_HASOID flag is set, and restores it afterwards.
This method is utterly, utterly unacceptable; you're probably trashing
the contents of a
On Wed, Nov 5, 2008 at 12:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> The "Join Removal" item fails to point to a patch, also.
>
> I've removed that entry now. The patch was being worked on by Jonah but
> it looks like we didn't make the deadline.
Well, what is the official deadline on it? I
On 5-Nov-08, at 1:00 PM, Tom Lane wrote:
I wrote:
Huh, is it possible that Linux rejects O_SYNC for a file on ramdisk?
I found this in the Fedora 9 manpage for open(2):
O_DIRECT support was added under Linux in kernel version
2.4.10. Older
Linux kernels simply ignore this fla
On Wed, Nov 05, 2008 at 03:04:42PM +0100, Zdenek Kotala wrote:
> Greg Stark napsal(a):
> It is exceptional case between V3 and V4 and only on heap, because you save
> in varlena. But between V4 and V5 we will lost another 4 bytes in a page
> header -> page header will be 28 bytes long but tuple s
I wrote:
> This method is utterly, utterly unacceptable; you're probably trashing
> the contents of a disk buffer there.
... however, it seems reasonable to assume that the *new* tuple is just
local storage. Why don't you just poke the old tuple's OID into the new
one before comparing?
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The attached patch sets the OID to InvalidOid for the duration of the
> memcmp if the HEAP_HASOID flag is set, and restores it afterwards.
This method is utterly, utterly unacceptable; you're probably trashing
the contents of a disk buffer there. Even
I wrote:
> Huh, is it possible that Linux rejects O_SYNC for a file on ramdisk?
I found this in the Fedora 9 manpage for open(2):
O_DIRECT support was added under Linux in kernel version 2.4.10. Older
Linux kernels simply ignore this flag. Some filesystems may not imple-
me
Andrew Dunstan wrote:
> KaiGai Kohei wrote:
>
>> Hi,
>>
>> The suppress_redundant_updates_trigger() works incorrectly
>> on the table defined with "WITH_OIDS" option.
>>
>>
>>
>
> Good catch!
>
> I think ideally we'd just adjust the comparison to avoid the system
> attributes.
>
> I'll
Dave Cramer <[EMAIL PROTECTED]> writes:
> On 5-Nov-08, at 12:21 PM, Tom Lane wrote:
>> nvalid argument"?? On the platforms I have handy, the only documented
>> reason for open(2) to fail with EINVAL is illegal value of the flags
>> argument, which should be impossible. What platform is this and w
Tom,
On 5-Nov-08, at 12:21 PM, Tom Lane wrote:
nvalid argument"?? On the platforms I have handy, the only documented
reason for open(2) to fail with EINVAL is illegal value of the flags
argument, which should be impossible. What platform is this and what
wal_sync_method are you using?
Red
On Wed, 2008-11-05 at 12:26 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In the current commitfest page we have this entry:
> > pg_start_backup checkpoint issue
> > However the URL it points to is broken (there's no message-id)
> > What to do about it?
>
> The "Joi
On Wed, 2008-11-05 at 14:16 -0300, Alvaro Herrera wrote:
> In the current commitfest page we have this entry:
>
> pg_start_backup checkpoint issue
>
> However the URL it points to is broken (there's no message-id)
>
> What to do about it?
Nothing yet. It's a minor issue, but not one I
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In the current commitfest page we have this entry:
> pg_start_backup checkpoint issue
> However the URL it points to is broken (there's no message-id)
> What to do about it?
The "Join Removal" item fails to point to a patch, also.
Dave Cramer <[EMAIL PROTECTED]> writes:
> 2008-11-05 11:43:45 EST [14853] LOG: selected new timeline ID: 4
> 2008-11-05 11:43:45 EST [14853] LOG: archive recovery complete
> 2008-11-05 11:43:48 EST [14853] FATAL: could not open file "pg_xlog/
> 000416ED007F" (log file 5869, segme
In the current commitfest page we have this entry:
pg_start_backup checkpoint issue
However the URL it points to is broken (there's no message-id)
What to do about it?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Cu
On Nov 5, 2008, at 6:40 AM, Kenneth Marshall wrote:
I installed and ran the citext tests both with and without
the patch and had failures both times. The patch applied
cleanly and the "make;make install" completed without errors.
I have attached the two regression.diffs files, one without
the pa
I am trying to move a db from one machine to another.
pg_standby applies all the logs fine, then I trigger it and this
happens ???
2008-11-05 11:43:45 EST [14853] LOG: restored log file
"000316ED007E" from archive
2008-11-05 11:43:45 EST [14853] LOG: selected new timeline I
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/11/4 Tom Lane <[EMAIL PROTECTED]>:
>> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>> a) server crash after creating tsearch2 function (I use tsearch2
>>> contrib from 8.3)
>>
>> I couldn't reproduce that with the script you gave.
> I tested it o
Brendan Jurd wrote:
Reviewing this patch now; I'm working from the 'iso8601' branch in
... I thought I'd post a patch of my own (against your branch)
and accompany it with a few explanatory notes.
Wow thanks! That's very helpful (though it might have been more
fair to your time if you just ki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Nov 5, 2008 at 8:20 AM, Tom Lane wrote:
> Joshua Tolley writes:
>> On Mon, Oct 20, 2008 at 03:42:49PM -0700, Lawrence, Ramon wrote:
>>> We propose a patch that improves hybrid hash join's performance for large
>>> multi-batch joins where the
On Thu, Oct 2, 2008 at 9:31 PM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> Ron Mayer wrote:
> This patch (that works on top of the IntervalStyle patch I
> posted earlier today) adds support for ISO8601 standard[0]
> "Time Interval" "Durations" of the "format with designators"
> (section 4.4.4.2.1). T
Joshua Tolley <[EMAIL PROTECTED]> writes:
> On Mon, Oct 20, 2008 at 03:42:49PM -0700, Lawrence, Ramon wrote:
>> We propose a patch that improves hybrid hash join's performance for large
>> multi-batch joins where the probe relation has skew.
> I also recommend modifying docs/src/sgml/config.sgml t
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
Attached is my latest parallel restore patch. I think it's
functionally complete for Unix.
Many bugs have been fixed since the last patch, and the hardcoded
limitation to two table dependencies is removed. It seems fairly
robust in my rec
KaiGai Kohei wrote:
> Hi,
>
> The suppress_redundant_updates_trigger() works incorrectly
> on the table defined with "WITH_OIDS" option.
>
> --
> (*) The latest 8.4devel tree without SE-PostgreSQL patch
>
> postgres=# CREATE TABLE min_updates_test (
>f1 text,
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There is a tiny problem with this implementation: It returns null for an
> empty array, not zero. This is because array_lower and/or array_upper
> return null for an empty array, which makes sense for those cases. We
> could fix this by putting a
On Mon, Oct 20, 2008 at 03:42:49PM -0700, Lawrence, Ramon wrote:
>We propose a patch that improves hybrid hash join's performance for large
>multi-batch joins where the probe relation has skew.
I also recommend modifying docs/src/sgml/config.sgml to include the
enable_hashjoin_usestatmcvs
I installed and ran the citext tests both with and without
the patch and had failures both times. The patch applied
cleanly and the "make;make install" completed without errors.
I have attached the two regression.diffs files, one without
the patch applied and the other with the patch.
Regards,
Ken
Brendan Jurd wrote:
On Wed, Nov 5, 2008 at 7:34 AM, Ron Mayer <[EMAIL PROTECTED]> wrote:
Brendan Jurd wrote:
...new interval
Review of the other two patches coming soon to a mail client near you.
Oh - and for review of the next patch, ISO 8601's spec would no doubt
be useful.
I think this
2008/11/5 Peter Eisentraut <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>>
>> Hello
>>
>> 2008/11/5 Peter Eisentraut <[EMAIL PROTECTED]>:
>>>
>>> Decibel! wrote:
ISTM it'd be useful to have an array_length function (since I just wrote
one for work ;), so here's a patch. Note that I do
Hi,
> To be reviewed easily, I'm splitting Synch Rep patch into some pieces.
Attached is a patch only to start and manage walsender process. This patch
don't include replication itself, walreceiver and signal handling patch, etc.
The outline of this patch is as follow:
Authentication
--
Pavel Stehule wrote:
Hello
2008/11/5 Peter Eisentraut <[EMAIL PROTECTED]>:
Decibel! wrote:
ISTM it'd be useful to have an array_length function (since I just wrote
one for work ;), so here's a patch. Note that I don't have the docs
toolchain setup, so I wasn't able to test the doc patches.
Th
Greg Stark napsal(a):
I don't think this really qualifies as "in place upgrade" since it would
mean creating a whole second copy of all your data. And it's only online
got read-only queries too.
I think we need a way to upgrade the pages in place and deal with any
overflow data as exceptional
Hi Fujii,
Here's some initial thoughts on the structure of this. I've deliberately
not yet read other comments, so we have some independent viewpoints.
Sorry if that means we end up saying same thing twice.
On Fri, 2008-10-31 at 20:36 +0900, Fujii Masao wrote:
> 1) Walsender
>
> This is new pr
I don't think this really qualifies as "in place upgrade" since it
would mean creating a whole second copy of all your data. And it's
only online got read-only queries too.
I think we need a way to upgrade the pages in place and deal with any
overflow data as exceptional cases or else there
On Wed, 2008-11-05 at 21:05 +1300, Mark Kirkwood wrote:
> So this one is entirely user error!
No worries. I'd rather have false positives, since can often reveal some
usability problem. I think we're OK here for now though.
Thanks very much for testing.
--
Simon Riggs www.2ndQuadra
Tom Lane napsal(a):
I concur that I don't want to see this patch adding more than the
absolute unavoidable minimum of overhead for data that meets the
"current" layout definition. I'm disturbed by the proposal to stick
overhead into tuple header access, for example.
OK. I agree that it is ov
On Tue, 2008-11-04 at 09:52 +, Simon Riggs wrote:
> > postgres=# \c bench
> > FATAL: database "bench" does not exist
> > Previous connection kept
>
> CREATE DATABASE didn't trigger the db flat file update, code for which
> existed and was triggered in the cases when a transaction would norm
On Mon, Oct 20, 2008 at 03:42:49PM -0700, Lawrence, Ramon wrote:
>We propose a patch that improves hybrid hash join's performance for large
>multi-batch joins where the probe relation has skew.
I'm running into problems with this patch. It applies cleanly, and the
technique you provided fo
Hello
2008/11/5 Peter Eisentraut <[EMAIL PROTECTED]>:
> Decibel! wrote:
>>
>> ISTM it'd be useful to have an array_length function (since I just wrote
>> one for work ;), so here's a patch. Note that I don't have the docs
>> toolchain setup, so I wasn't able to test the doc patches.
>
> There is a
On Tue, Oct 28, 2008 at 08:59:53PM +0100, Magnus Hagander wrote:
> The attached patch tries to implement regexp support in the usermaps
> (pg_ident.conf).
Hi Magnus,
I am currently reviewing your patch.
I found out that the execution of
pfree(regexp_pgrole);
(there's only one such line i
Decibel! wrote:
ISTM it'd be useful to have an array_length function (since I just wrote
one for work ;), so here's a patch. Note that I don't have the docs
toolchain setup, so I wasn't able to test the doc patches.
There is a tiny problem with this implementation: It returns null for an
empt
Hi, Simon,
On Wed, Nov 5, 2008 at 7:07 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-11-04 at 22:59 +0900, Fujii Masao wrote:
>> Hi, thank you for taking time to review the patch.
>>
>> On Fri, Oct 31, 2008 at 11:12 PM, Heikki Linnakangas
>> <[EMAIL PROTECTED]> wrote:
>> > Fujii Masa
2008/11/4 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I started upgrade our databases from 8.1 to 8.3. I found two strange
>> bugs related to tsearch2.
>
> Did you follow the advice here:
> http://www.postgresql.org/docs/8.3/static/textsearch-migration.html
yes I
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
We've talked about this many times before, so I'm sure you know what my
opinion is. Let me phrase it one more time:
1. You *will* need a function to convert a page from old format to new
format. We do want to get rid of the old format pag
Andrew Dunstan wrote:
Attached is my latest parallel restore patch. I think it's functionally
complete for Unix.
Many bugs have been fixed since the last patch, and the hardcoded
limitation to two table dependencies is removed. It seems fairly robust
in my recent testing.
this version see
Hi, Pgsql-hackers.
Full list of changes of two related projects (SQL5 & HTML6) at current moment
(not reflected in documentation yet).
===terms
master table is table, to primary key of which this (slave) table refers
(terms "master" and "slave" are used only for MTD).
if master table is no
> An old page which never goes away. New page formats are introduced for a
> reason -- to support new features. An old page lying around indefinitely means
> some pages can't support those new features. Just as an example, DBAs may be
> surprised to find out that large swathes of their database are
Just a superficial review. I haven't really looked hard at this yet.
1 - Patch does not apply cleanly on latest git repository, although
there is no hunk failed but there are some hunk succeeded messages.
2- Patch contains unnecessary spaces and tabs which makes the patch
unnecessarily big. IMHO
On Tue, Nov 04, 2008 at 01:03:44PM -0500, Tom Lane wrote:
> I'm quite unhappy with the invasiveness of the proposed gram.y changes.
Keep in mind that this is work in progress. I'm still working on this stuff and
yes, I'm trying to simplify things.
> The @ECPG annotations are bad enough, but why a
On Tue, 2008-11-04 at 22:59 +0900, Fujii Masao wrote:
> Hi, thank you for taking time to review the patch.
>
> On Fri, Oct 31, 2008 at 11:12 PM, Heikki Linnakangas
> <[EMAIL PROTECTED]> wrote:
> > Fujii Masao wrote:
> >>
> >> Attached is a patch for a synchronous log-shipping replication which
>
Hi,
The suppress_redundant_updates_trigger() works incorrectly
on the table defined with "WITH_OIDS" option.
--
(*) The latest 8.4devel tree without SE-PostgreSQL patch
postgres=# CREATE TABLE min_updates_test (
f1 text,
f2 int,
f3 int) with o
--On Dienstag, November 04, 2008 17:12:15 -0800 Unicron
<[EMAIL PROTECTED]> wrote:
I am reviewer of Patch "Table command". I wanted to build code checked
out from code repo
got via rsyn, but I didn't find relating code in file "gram.y". Do i need
to add the code to the file?
The patch doesn't
I wrote:
Yeah - I was doing it wrong (using immediate). However retesting with
'fast' gets the same result on this platform (Freebsd 7.1). However on
Linux (Ubuntu 8.04) 'fast' shutdown and restart work fine - somewhat
puzzling - I'll try a fresh checkout on the Freebsd boxes, as there
may b
100 matches
Mail list logo
