Hi,
I noticed Tom Lane made SELECT FOR UPDATE/SHARE work on inheritance trees.
But todo list is not updated to reflect this change.
http://wiki.postgresql.org/wiki/Todo#Inheritance
Actually, there is a patch trying to remove the ONLY clause on the foreign
key checks on the inheritance tables.
--On Mittwoch, Februar 11, 2009 13:18:11 -0500 Robert Haas
robertmh...@gmail.com wrote:
In any case it's not difficult to write a script that loops over all
of your tables with ALTER TABLE. It's probably not as fast as a
single UPDATE statement, but I suspect you'd need to have an enormous
Well for one thing because they don't scale well to billions of
records. For another they're even less like the standard or anything
any other database has.
I agree with you that there's no reason to actively deprecate OIDs or
hurt users who use them. But we should make it as easy as
On 11 Feb 2009, at 00:03, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, that makes less sense than the antijoin case. For antijoin
there is a well-defined value for the extended columns, ie null. For
a semijoin the RHS values might come from any of the rows that happen
to join to the current
Hi Tom,
Given I was using 8.3, it seemed quite right to set the reset statement
to ABORT; DISCARD ALL. Everything works fine, until a load spike
happens and pgpool-II reset queries start to lag behind, with DISCARD
ALL failing to acquire an exclusive locks on the pg_listen system table,
On Thu, 2009-02-12 at 09:50 +0200, Heikki Linnakangas wrote:
It occurs to me that we don't need this patch for hot standby if we
abuse the main xid array (SnapshotData.xip) to store the unobserved xids
instead of the subxid array. That one is always scanned in
XidInMVCCSnapshot. I think
Hi All,
I am involved in porting Spacewalk https://fedorahosted.org/spacewalk/'s
backend DB schema from Oracle to Postgres. We are almost done with table
migration, and are now attempting procedure/function porting.
A few things have been sorted out
(forgot to include general list earlier)
Hi All,
I am involved in porting Spacewalk https://fedorahosted.org/spacewalk/'s
backend DB schema from Oracle to Postgres. We are almost done with table
migration, and are now attempting procedure/function porting.
A few things have been sorted out
Simon Riggs wrote:
On Thu, 2009-02-12 at 09:50 +0200, Heikki Linnakangas wrote:
So far so good, but what about all the other callers of
SubTransGetParent()? For example, XactLockTableWait will fail an
assertion if asked to wait on a subtransaction which is then released.
I agree that it
Gurjeet Singh wrote:
that is, not passing anything for the OUT or INOUT parameters. This works
fine for a simple SELECT usage, but does not play well when this function is
to be called from another function, (and assuming that it'd break the
application code too, which uses Oracle syntax of
On Mon, Feb 02, 2009 at 07:37:46AM -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
Hmm. Actually, if I look at how things were before, I think we only
called SetEnvironmentVariable() in case we set a variable, and never if
we removed one. I'm not sure that's correct behavior, but it's
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
(A semijoin B on (Pab)) antijoin C on (Pbc)
= A semijoin (B antijoin C on (Pbc)) on (Pab)
I think this one is true, and it doesn't seem to be mentioned,
unless I'm missing something. It seems
On Thu, Feb 12, 2009 at 6:18 PM, Richard Huxton d...@archonet.com wrote:
Gurjeet Singh wrote:
that is, not passing anything for the OUT or INOUT parameters. This works
fine for a simple SELECT usage, but does not play well when this function
is
to be called from another function, (and
I wrote:
You've got a name, and you want a list of outstanding warrants for
parties with a matching name.
Correction, if that was the list you wanted, you would use an inner
join, not a semijoin. For purposes of this illustration I guess you
would be looking for a list of parties who have
On Thursday 12 February 2009 05:15:02 Bruce Momjian wrote:
I am working on pg_migrator TODO items. My current list is:
[long]
Can we clarify now that this is not going to ship with the PostgreSQL 8.4
tarball?
I am not aware of any server changes needed for 8.3-8.4 migration.
OK, Zdenek, any
Peter Eisentraut wrote:
On Thursday 12 February 2009 05:15:02 Bruce Momjian wrote:
I am working on pg_migrator TODO items. My current list is:
[long]
Can we clarify now that this is not going to ship with the PostgreSQL 8.4
tarball?
That is not really my decision, but I am not going to
I've been examining multi-major-version binary packaging again, and I was
wondering whether we have a good overview over which pieces of the
installation are backward compatible (that is, they can be shared between all
major versions) and which are not. For example, psql 8.4 can now presumably
On Wednesday 11 February 2009 12:05:03 Pavel Stehule wrote:
It works. And I thing, this should to solve lot of special task
related to increase compatibility with Oracle, Informix, or it could
be usefull for some others (json support).
postgres=# load 'decode';
LOAD
postgres=# select
BogDan Vatra wrote:
I've tested you patch in windows and in linux and it just work, it's a
killer feature. I have to tank you and all who worked on this.
On windows I have one little problem, mingw does not have strtok_r
function and I have to add it myself (see attached file).
Indeed, I could
2009/2/12 Peter Eisentraut pete...@gmx.net:
On Wednesday 11 February 2009 12:05:03 Pavel Stehule wrote:
It works. And I thing, this should to solve lot of special task
related to increase compatibility with Oracle, Informix, or it could
be usefull for some others (json support).
postgres=#
On Monday 02 February 2009 21:42:36 Zdenek Kotala wrote:
I attached fix for regression tests and Czech locale. It is not complete
yet, because I fighting with foreign_data test. But it fix three other
tests.
done
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, Feb 12, 2009 at 04:16:05PM +0200, Peter Eisentraut wrote:
Item Compatible across major versions?
(i.e. the 8.4 version works with 7.4+ server)
...
ecpg no?
It depends on which kind of compatibility you're looking for. The grammar
accepted will surely be
Peter Eisentraut wrote:
pg_restore yes?
I don't know how far back pg_restore works, but the reason I have not
produced a backport of parallel restore is that the HEAD version works
with dumps and servers at least as far back as 8.2 (and I was careful to
make sure it supported
Peter Eisentraut escreveu:
If no such list exists yet, perhaps we can complete the above one, document
it, and pass it on to the packagers.
Are you suggesting that if an user has 7.4 and install 8.3 then the package
will replace psql-7.4 with psql-8.3? It will confuse users more that help
Euler Taveira de Oliveira wrote:
Peter Eisentraut escreveu:
If no such list exists yet, perhaps we can complete the above one, document
it, and pass it on to the packagers.
Are you suggesting that if an user has 7.4 and install 8.3 then the package
will replace psql-7.4 with psql-8.3?
Alvaro Herrera escreveu:
Euler Taveira de Oliveira wrote:
Peter Eisentraut escreveu:
If no such list exists yet, perhaps we can complete the above one, document
it, and pass it on to the packagers.
Are you suggesting that if an user has 7.4 and install 8.3 then the package
will replace
I know we've already had a discussion on the naming of the pg_restore -m
option, but in any case this description in pg_restore --help is confusing:
-m, --multi-thread=NUM use this many parallel connections to restore
Either it is using that many threads in the client, or it is using that
Tao Ma feng_e...@163.com writes:
My question is: Is it possible to remove the ONLY from the RI checks after
Tom Lane made SELECT FOR UPDATE/SHARE work on inheritance trees?
No. The main thing standing in the way of RI on inheritance trees is
the lack of cross-tree uniqueness constraints.
We need insert rows to a catalog table that would store partitions info:
CATALOG(pg_partition,2336) BKI_WITHOUT_OIDS
{
Oid partrelid; /* partition table Oid */
Oid parentrelid;/* Parent table Oid */
int2parttype; /* Type of partition, list, hash,
Amit Gupta wrote:
The following code didn't work:
pg_partrel = heap_open(PartitionRelationId, AccessShareLock);
pg_partscan = systable_beginscan(pg_partrel, PartitionParentIndexId, true,
SnapshotNow, 1, skey);
while (HeapTupleIsValid(pg_parttup=
Amit Gupta wrote:
We need insert rows to a catalog table that would store partitions info:
CATALOG(pg_partition,2336) BKI_WITHOUT_OIDS
{
Oid partrelid; /* partition table Oid */
Oid parentrelid;/* Parent table Oid */
int2parttype; /* Type of
Peter Eisentraut wrote:
I know we've already had a discussion on the naming of the pg_restore -m
option, but in any case this description in pg_restore --help is confusing:
-m, --multi-thread=NUM use this many parallel connections to restore
Either it is using that many threads in the
Peter Eisentraut pete...@gmx.net writes:
I think what you want here is some way to define a function that takes an
arbitrary number of arguments of arbitrary type and let the function figure
everything out. I see no reason why this can't be a variant on CREATE
FUNCTION, except that of
bruce wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Now that pg_migrator is BSD licensed, and already in C, I am going to
spend my time trying to improve pg_migrator for 8.4:
http://pgfoundry.org/projects/pg-migrator/
What is the plan now? Get pg_upgrade working, get
Andrew Dunstan and...@dunslane.net writes:
The implementation is actually different across platforms: on Windows
the workers are genuine threads, while elsewhere they are forked
children in the same fashion as the backend (non-EXEC_BACKEND case). In
either case, the program will use up to
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The implementation is actually different across platforms: on Windows
the workers are genuine threads, while elsewhere they are forked
children in the same fashion as the backend
Tao Ma wrote:
Hi,
I noticed Tom Lane made SELECT FOR UPDATE/SHARE work on inheritance trees.
But todo list is not updated to reflect this change.
http://wiki.postgresql.org/wiki/Todo#Inheritance
OK, TODO updated to mark this as done.
--
Bruce Momjian br...@momjian.us
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The implementation is actually different across platforms: on Windows
the workers are genuine threads, while elsewhere they are forked
children in the same fashion as
On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The implementation is actually different across platforms: on Windows
the workers are genuine
Hi all,
I'm compiling PostgreSQL 8.3.6 on AIX 5.3.0.0 with GCC 4.2.0 and it is working.
But, after message All of PostgreSQL successfully made. Ready to
install., when it starts regression test, some unexpected (?) occurs.
First I doing only a *make* and it is doing *make install* instead just
Bruce Momjian br...@momjian.us writes:
I can think of three possible solutions, all involve recreating and
dropping the dropped column in the new schema:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more maintainable
than
Peter Eisentraut pete...@gmx.net writes:
I've been examining multi-major-version binary packaging again, and I was
wondering whether we have a good overview over which pieces of the
installation are backward compatible (that is, they can be shared between all
major versions) and which are
Matteo Beccati p...@beccati.com writes:
Seems like we could/should fix UNLISTEN * to not do anything if it is
known that the current backend never did any LISTENs.
Here's my proposed patch, both for HEAD and 8.3:
I'll take a look.
regards, tom lane
--
Sent via
This freezes the whole system even with autovacuum = off in
postgresql.conf. As before, the backends wait on a semop() call.
Fixed. There was a deadlock of LockBufferForCleanup and LockBuffer(SHARE).
Redesign that place to downgrade LockBufferForCleanup to LockBuffer(EXCLUSIVE)
with
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I can think of three possible solutions, all involve recreating and
dropping the dropped column in the new schema:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more
But the *real* problem is that you simply can not guarantee that
someone doesn't increase the size of the pending list between the time
If insertion process has bigger work_mem. Agree.
What did you think of the idea of simply abandoning support for
conventional indexscans in GIN? I agree
Matteo Beccati p...@beccati.com writes:
Seems like we could/should fix UNLISTEN * to not do anything if it is
known that the current backend never did any LISTENs.
Here's my proposed patch, both for HEAD and 8.3:
This seems a bit overcomplicated. I had in mind something like this...
Index:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more maintainable
than writing separate code that tries to parse the output.
I assume I would also drop the column in the
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
Right, that's what I meant --- do all the work within pg_dump.
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support (enabling this as
well as any other
Teodor Sigaev teo...@sigaev.ru writes:
What did you think of the idea of simply abandoning support for
conventional indexscans in GIN?
I don't like this idea because it forbids conventional indexscans even with
fastupdate=off.
So? Barring some evidence that there's a significant
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(4) add a switch to pg_dump to include dropped columns in its
schema output and then drop them. This seems far more maintainable
than writing separate code that tries to parse the output.
I assume I would also
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
Right, that's what I meant --- do all the work within pg_dump.
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support
Joshua D. Drake j...@commandprompt.com writes:
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
a long form only. And probably not even list it in the user
documentation.
Why wouldn't we want to list it?
Because it's for internal use only. Although the effect we're
discussing here is
On Thu, Feb 12, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Teodor Sigaev teo...@sigaev.ru writes:
What did you think of the idea of simply abandoning support for
conventional indexscans in GIN?
I don't like this idea because it forbids conventional indexscans even with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua D. Drake a écrit :
On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The implementation is actually
On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake j...@commandprompt.comwrote:
--num-workers or --num-connections would both work.
--num-parallel?
--
Jonah H. Harris, Senior DBA
myYearbook.com
Tom Lane ha scritto:
Matteo Beccati p...@beccati.com writes:
Seems like we could/should fix UNLISTEN * to not do anything if it is
known that the current backend never did any LISTENs.
Here's my proposed patch, both for HEAD and 8.3:
This seems a bit overcomplicated. I had in mind
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 12, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So? Barring some evidence that there's a significant performance win
from a conventional indexscan, this is a weak argument. AFAICS the only
significant advantage of the conventional
On 2009-02-12, at 14:15 , Jonah H. Harris wrote:
On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake j...@commandprompt.com
wrote:
--num-workers or --num-connections would both work.
--num-parallel?
--num-concurrent?
Michael Glaesemann
michael.glaesem...@myyearbook.com
--
Sent via
Matteo Beccati p...@beccati.com writes:
Tom Lane ha scritto:
This seems a bit overcomplicated. I had in mind something like this...
Much easier indeed... I didn't notice the unlistenExitRegistered variable.
Just for completeness, I attach another form of the patch that I thought
about for a
Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Thu, 2009-02-12 at 13:39 -0500, Tom Lane wrote:
a long form only. And probably not even list it in the user
documentation.
Why wouldn't we want to list it?
Because it's for internal use only. Although the effect
On Thu, Feb 12, 2009 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Just for completeness, I attach another form of the patch that I thought
about for a bit. This adds the ability for UNLISTEN ALL to revert the
backend to the state where subsequent UNLISTENs don't cost anything.
This could be
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 12, 2009 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Just for completeness, I attach another form of the patch that I thought
about for a bit. This adds the ability for UNLISTEN ALL to revert the
backend to the state where subsequent
Rusty Conover rcono...@infogears.com writes:
The gist__int_ops is the default operator class for integer[] arrays,
as shown at:
http://www.postgresql.org/docs/current/static/intarray.html
Ah, so you have contrib/intarray installed.
[ pokes at it... ] Seems like what we have here is another
Fujii Masao escribió:
I noticed two very minor issues while reading your docs:
This is because WAL files generated in the primary server before this
built-in
replication starts have to be transferred to the standby server by
using file-based log shipping. When TT
ITAGAKI Takahiro wrote:
With reloption patch, we can set WITH options to toast tables.
However, fillfactor for toast tables is useless, no?
Maybe what we should do is just reject fillfactor for toast tables for
now. I think this is easy to do.
--
Alvaro Herrera
John Lister john.lister...@kickstone.com writes:
GMT LOG: relation pg_class TID 15538/4: dead HOT-updated tuple ---
cannot shrink relation
Hmm. The comments in vacuum.c about this case suppose that it could
only be a transient condition, ie the tuple became dead while we were
looking at the
I whipped up a quick dtrace probe for one of our servers to monitor connection
attempts. My goal was to monitor for any connection attempts from a specific
role within the database. Unfortunatly you can't set logging of connections
for a specific user, and logging all connections on that
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 12, 2009 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Just for completeness, I attach another form of the patch that I thought
about for a bit. This adds the ability for UNLISTEN ALL to revert the
backend to the state
On Thu, Feb 12, 2009 at 02:16:39PM -0500, Michael Glaesemann wrote:
On 2009-02-12, at 14:15 , Jonah H. Harris wrote:
On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake j...@commandprompt.com
wrote:
--num-workers or --num-connections would both work.
--num-parallel?
--num-concurrent?
Hi,
I am the packager of postgresql for mandriva, and I receive this bug to
today
https://qa.mandriva.com/show_bug.cgi?id=47722
postgresql8.3-contribe missed some files like uuid-ossp.sql
Description of problem:
uuid-ossp was not found in the .spec file
By take a look in the /contrib/README
Hello,
I was helping a customer today with what is becoming a common theme with
a lot of work we do. Basically, It was working fine until recently.
Now 90% of the time it is as simple as running an ANALYZE VERBOSE and
picking apart relations that aren't being maintained properly and adjust
Hi,
I am the packager of postgresql for mandriva, and I receive this bug to
today
https://qa.mandriva.com/show_bug.cgi?id=47722
postgresql8.3-contribe missed some files like uuid-ossp.sql
Description of problem:
uuid-ossp was not found in the .spec file
By take a look in the /contrib/README
Olivier Thauvin olivier.thau...@aerov.jussieu.fr writes:
By take a look in the /contrib/README file, some items are missed
intagg
intarray
spi
start-scripts
xml2 (libxml2 ?)
Your complainant seems to be assuming that there's a one-to-one mapping
between contrib module names and .sql
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1530.patch
[3/5]
Olivier Thauvin wrote:
Hi,
I am the packager of postgresql for mandriva, and I receive this bug to
today
https://qa.mandriva.com/show_bug.cgi?id=47722
postgresql8.3-contribe missed some files like uuid-ossp.sql
Description of problem:
uuid-ossp was not found in the .spec file
By take a
Alvaro Herrera alvhe...@commandprompt.com wrote:
ITAGAKI Takahiro wrote:
With reloption patch, we can set WITH options to toast tables.
However, fillfactor for toast tables is useless, no?
Maybe what we should do is just reject fillfactor for toast tables for
now. I think this is easy
77 matches
Mail list logo
