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
--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
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
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
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.
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
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 not
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
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 Masao wrote:
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
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 in
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 tiny
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 for
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 normally
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
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
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
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
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
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.
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
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 don't have the docs
toolchain
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
was discussed
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
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
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
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 did
try:
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
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
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,
f2 int,
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
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 to
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). The other ISO
-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 probe
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
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 on fe8, 32 bit without
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
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
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,
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, segment
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.
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 wanted
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 Join Removal
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
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 what
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 have a look to see if
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-
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:
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?
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 size
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
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? It, like
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
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
(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
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 InvalidOid
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'ing
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
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
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 have
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
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
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:
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 without errors.
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. Attached
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.
Problem
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:
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
...
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 problem
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 where it is safe
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 lock on the
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
--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
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(2000))
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 generates
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
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 implementation
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
--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
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 like update operation
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
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())
{
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
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),
!
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
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_bits),
!
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
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 all
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
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
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
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
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
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
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
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
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
2008/11/6 Andrew Dunstan [EMAIL PROTECTED]:
Pavel Stehule wrote:
postgres=# select version();
version
--
PostgreSQL 8.3.4 on
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
change, I
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 explain
100 matches
Mail list logo
