I made some notes about what you said about my patch, just so that I can
be sure that it is clear what it does.
On Sun, 11 Feb 2007, David Fetter wrote:
== PostgreSQL Weekly News - February 11 2007 ==
== Pending Patches ==
Jeremy Drake sent in a patch which implements regexp_replace with
What are the problems with just shuffling the last (and only
visible)
tuple to replace the HOT-hain root and be done with it ?
ctid stops being a reliable identifier.
A backend selecting the row by ctid would need to take one step to
the root slot to get at the tuple. This does seem
On 2/11/07, Jaime Casanova [EMAIL PROTECTED] wrote:
On 2/11/07, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
just for curiosity, why the code doesn't throw an error when using
sequences in the from_list of a select?
That's a feature, not a bug.
and why is
On Mon, Feb 12, 2007 at 12:48:06AM -0500, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
How about adding a new 2-byte field to header for in-page c_tid poiner
for HOT ?
We just finished sweating blood to get the tuple header size down to 23
bytes from 27 (which saves 8 bytes not 4
Currently tsearch2 does not accept non ascii stop words if locale is
C. Included patches should fix the problem. Patches against PostgreSQL
8.2.3.
I'm not sure about correctness of patch's description.
First, p_islatin() function is used only in words/lexemes parser, not stop-word
code.
I was just testing autovac once more, and happened to Ctrl-C the
regression run in the prepared_xacts test. Upon starting Postmaster
again, I see this:
LOG: recovering prepared transaction 14372
LOG: recovering prepared transaction 14377
Then, I reran make check, and got
==
Alvaro Herrera [EMAIL PROTECTED] writes:
I think we should set things up so that prepared transactions are
dropped when they concern a database being dropped. Opinions?
No. A prepared transaction is one that we have guaranteed we can commit
when the 2PC manager tells us to. Reneging on that
Alvaro Herrera wrote:
I think we should set things up so that prepared transactions are
dropped when they concern a database being dropped. Opinions?
Agreed, if you want to drop the database, you don't care about the
transactions in it anymore.
It seems straightforward to implement. We'll
[EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2007 at 12:48:06AM -0500, Tom Lane wrote:
We just finished sweating blood to get the tuple header size down to 23
bytes from 27 (which saves 8 bytes not 4 if MAXALIGN=8). We are not
going to blow that again on HOT.
I haven't had enough time to follow
Christopher Browne wrote:
[EMAIL PROTECTED] (Hideyuki Kawashima) wrote:
Joshua,
I appreciate your quick informative reply. And, I also really
appreciate your kind comments. Since I have joined this ML 3 hours
ago, I tried to be polite and slightly nervous. But I was relieved
by your
Heikki Linnakangas [EMAIL PROTECTED] writes:
Do we consider committing a transaction from another database a feature,
and fix NOTIFY/LISTEN, or should COMMIT PREPARED throw an error if
you're not connected to the same database?
Hmm ... if we were sure NOTIFY were the only sore spot I'd say
Tom Lane wrote:
Actually, I think we should completely separate the namespaces of the
global transaction identifiers, so that you could use the same gid in
two different databases without a conflict.
Really? They're supposed to be global.
Well yeah, the TM should be assigning globally
I've been looking at this again and had a few conversations about it. This may
be easier than I had originally thought but there's one major issue that's
bugging me. Do you see any way to avoid having every user function everywhere
use a new macro api instead of VARDATA/VARATT_DATA and
On Friday 09 February 2007 08:16, Doug Knight wrote:
I would also be interested in any creative ways to reduce the size and
time to backup databases/clusters. We were just having a conversation
about this yesterday. We were mulling over things like using rsync to
only backup files in the
Hi,
I have made a Sigres which accelerates INSERT/UPDATE on PostgreSQL using
UPS.
The philosophy of Sigres is considering a battery supplied memory as a
persistent device, instead of disk.
You can download it from http://sourceforge.jp/projects/sigres/ .
In my environment, Sigres is 7 times
I built the -base version of 8.2.3 today, for installation at a company
I'm helping out. The build (and later, the installation) gave me an error
about a missing directory test/regress. IIRC I downloaded
Jeroen T. Vermeulen wrote:
Is this a known problem? Is there any test procedure that builds the
base distribution before release?
Most of the core team is convinced that the postgresql-foo tarballs are
useless, but Marc insists on keeping them. But since they are nearly
useless, no one
On Tue, February 13, 2007 01:45, Peter Eisentraut wrote:
Most of the core team is convinced that the postgresql-foo tarballs are
useless, but Marc insists on keeping them. But since they are nearly
useless, no one tests them, so it is not surprising that they don't
work.
Well, hurray for
Here are the proposed signatures for the XML export functions.
While I have seen the output formats in use elsewhere, I could not find
any useful information on how to invoke these mappings, so the
following is purely my own invention.
table_to_xml(tbl regclass, nulls boolean, tableforest
Peter Eisentraut wrote:
Here are the proposed signatures for the XML export functions.
While I have seen the output formats in use elsewhere, I could not find
any useful information on how to invoke these mappings, so the
following is purely my own invention.
table_to_xml(tbl regclass, nulls
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
maintaining the wishlist I keep forgetting the IRC
Hey folks:
I posted this to the pgsql-novice mailing list but was told that it'd
probably be better to repost here. I've been working with a group trying to
implement UNIQUE index functionality in GiST (we started with hash, and have
branched out to try and understand some of the other
I looked into Ian Harding's problem reported here:
http://archives.postgresql.org/pgsql-general/2007-02/msg00530.php
It's possible to reproduce the problem in a simplified form in the
regression database, using this query:
explain
select * from
tenk1 a left join
(tenk1 b inner join
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
I built the -base version of 8.2.3 today, for installation at a company
I'm helping out.
There is no -base version. The split tarballs are a convenience for
downloading over slow lines; it is not intended that you can build after
downloading just
Tom Lane wrote:
Gene [EMAIL PROTECTED] writes:
... just my two cents. on a side note, would putting the wal on a
tmpfs partition give you something similar?
Indeed, I'm wondering why one needs to hack the Postgres core to throw
away data integrity guarantees; there are plenty of ways to
I was curious to see how postgres would perform with wal on a tmpfs vs disk
here are some numbers I got from pgbench. Let me know if I did something
stupid, this is the first time I've used pgbench. The wal on tmpfs method is
not significantly faster.
[[ WAL ON TMPFS ]]
pgbench -i -s 10 -U
Andrew Dunstan wrote:
. table_to_xml_and_xmlschema seems like a mouthful - can we shorten
it a bit?
Well, it gives you back a mouthful of data, too. :)
. what are the two ways of representing data that tableforest
distinguishes?
tableforest = false gives you something like
tablename
row
Tom Lane wrote:
There is no -base version. The split tarballs are a convenience
for downloading over slow lines; it is not intended that you can
build after downloading just some of them.
It used to be possible to build at least the -base tarball
independently. But again, none of this was
Peter Eisentraut wrote:
tableforest = false gives you something like
tablename
...
/tablename
tableforest = true gives you something like
tablename
...
/tablename
tablename
...
/tablename
...
How do you define the table name when fetching data using a join, union
etc. where the
Currently tsearch2 does not accept non ascii stop words if locale is
C. Included patches should fix the problem. Patches against PostgreSQL
8.2.3.
I'm not sure about correctness of patch's description.
First, p_islatin() function is used only in words/lexemes parser, not
stop-word
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
Log Message:
---
Fix backend crash in parsing incorrect tsquery.
Per report from Jon Rosebaugh [EMAIL PROTECTED]
Is this a security issue? Does it need a new security release? I hope
that the answer is not this is contrib, it isn't as
Tommy Gildseth wrote:
How do you define the table name when fetching data using a join,
union etc. where the data doesn't necessarily originate from a single
table?
If you use the query_to_xml function, then I just write table
without any particular name.
Another neat feature would be if
On 2/12/07, Gene [EMAIL PROTECTED] wrote:
I was curious to see how postgres would perform with wal on a tmpfs vs
disk here are some numbers I got from pgbench. Let me know if I did
something stupid, this is the first time I've used pgbench. The wal on tmpfs
method is not significantly faster.
Jeremy Drake wrote:
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
Log Message:
---
Fix backend crash in parsing incorrect tsquery.
Per report from Jon Rosebaugh [EMAIL PROTECTED]
Is this a security issue? Does it need a new security release?
We don't treat crashes to be security
On Tue, 13 Feb 2007, Peter Eisentraut wrote:
We don't treat crashes to be security issues of the kind that calls for
the full security exercise.
But if a security issue, by whatever definition of the term applies to
core, is found in contrib, it would result in the full security exercise,
Jeremy Drake [EMAIL PROTECTED] writes:
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
Fix backend crash in parsing incorrect tsquery.
Is this a security issue? Does it need a new security release?
We looked at this and determined that the worst that could be done with
it is crash the backend.
Gene [EMAIL PROTECTED] writes:
I was curious to see how postgres would perform with wal on a tmpfs vs disk
here are some numbers I got from pgbench. Let me know if I did something
stupid, this is the first time I've used pgbench. The wal on tmpfs method is
not significantly faster.
This
On Mon, 12 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
Fix backend crash in parsing incorrect tsquery.
Is this a security issue? Does it need a new security release?
We looked at this and determined that the worst that
On Sunday 11 February 2007 05:59, Martijn van Oosterhout wrote:
On Sat, Feb 10, 2007 at 12:20:35PM -0500, Tom Lane wrote:
I do
agree with adding a test when you think it is likely to be able to catch
a whole class of errors, or even a specific error if it seems especially
likely to
Bruce,
Thanks for your comments, and let me answer to your question.
Sigres is *not* significantly faster than just creating a file system on
the permanent memory and putting xlog on there.
Sigres is slightly faster than the case because each backend does not
call XLogWrite while bgWriter
Hideyuki Kawashima wrote:
Bruce,
Thanks for your comments, and let me answer to your question.
Sigres is *not* significantly faster than just creating a file system on
the permanent memory and putting xlog on there.
Sigres is slightly faster than the case because each backend does not
Peter Eisentraut wrote:
Jeroen T. Vermeulen wrote:
Is this a known problem? Is there any test procedure that builds the
base distribution before release?
Most of the core team is convinced that the postgresql-foo tarballs are
useless, but Marc insists on keeping them. But since they are
Gene,
I think tmpfs/ramfs method would increase the performance of PostgreSQL
when workload is write-intensive.
Does pgbench issue write intensive queries ? Since I do not know the
detailed queries issued in pgbench, I am happy if you teach me.
Regards,
-- Hideyuki
Gene wrote:
I was
On Mon, 12 Feb 2007, Tom Lane wrote:
I wrote:
* Add an oid[] column to pg_constraint that stores the equality operator
OIDs for a foreign-key constraint, in the same column order as conkey[]
and confkey[].
It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
generate PK = PK
Lukas Kahwe Smith wrote:
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
maintaining the
Stephan Szabo [EMAIL PROTECTED] writes:
I think #1, while ugly, is probably less ugly than the others, although I
guess it means even more work if the underlying type of the column is
changed.
Oy, I hadn't thought of that. [ considers... ] I *think* that it'll
work without special code,
Further, because pgbench writes many zero values to fixed length
columns, gzip can achieve better compression. There're another
suggestion to test with longer checkpoint interval. I will post the
result.
Thanks.
Martijn van Oosterhout wrote:
On Fri, Feb 09, 2007 at 01:00:10PM +0900, Koichi
I got a private email from Claudio saying he already answered this
question:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00285.php
I forgot I saw it, so I have added comments to the C code.
---
bruce
As suggested, the result I've posted used standard checkpoint_timeout.
With longer checkpoint timeout, overall WAL size tend to decrease. So
I've also run DBT-2. The measurement shows that the resultant WAL size
is reasonably small, while preserving full page writes to WAL,
maintaining the
I wrote:
I looked into Ian Harding's problem reported here:
http://archives.postgresql.org/pgsql-general/2007-02/msg00530.php
I've applied the attached patch, but it could do with some more
testing. Please try it out on your database and see if you get sane
answers ...
On Saturday 10 February 2007 13:59, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I'd say we probably want to keep the tgargs info for at least a version
or two after changing the implementation. Getting rid of using the args
info sounds like a good idea.
We whack the catalogs
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, I think we should completely separate the namespaces of the
global transaction identifiers, so that you could use the same gid in
two different databases without a conflict.
Really? They're supposed to be global.
Gregory Stark [EMAIL PROTECTED] writes:
Do you see any way to avoid having every user function everywhere
use a new macro api instead of VARDATA/VARATT_DATA and VARSIZE/VARATT_SIZEP?
Bruce and I had a long phone conversation about that today. We
concluded that there doesn't seem to be any
Matthew Campbell [EMAIL PROTECTED] writes:
I've been working with a group trying to
implement UNIQUE index functionality in GiST
... but we can't figure out how to
compare the two datums then. The actual data type of the value being
inserted would be different depending on the type of column
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
http://developer.postgresql.org/index.php/IRC2RWNames
Ah, excellent. Should we put this in the IRC topic line?
if there is still some space in the topic ... sure!
Is there any cross-check on the
Ühel kenal päeval, E, 2007-02-12 kell 17:23, kirjutas Heikki
Linnakangas:
[EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2007 at 12:48:06AM -0500, Tom Lane wrote:
We just finished sweating blood to get the tuple header size down to 23
bytes from 27 (which saves 8 bytes not 4 if MAXALIGN=8). We
indexes, then it must use operator number so-and-so for equality. But
there are lots of GiST opclasses that don't include equality at all; we
can't break that case.
There is a GiST support function for equality of keys, in btree_gist it's named
as gbt_*_same. Equality function has support
58 matches
Mail list logo
