Hi folks,
I am running a 9.0.3 Hot Standy + Streaming Replication slave which
occasionally segfaults (every 1-2 days). I rebuilt Postgres with
--enable-cassert and --enable-debug, switched on core dumping and
waited for some results.
The first crash since enabling debugging was a failed assert
On 04/05/2011 02:21 PM, Mischa Sandberg wrote:
Came across the following in a paper from Oct 2010. Was wondering is
this is old news I missed in this group.
http://pdos.csail.mit.edu/papers/linux:osdi10.pdf
about Linux optimization on multi-core CPU's.
Only a little old;
On 4/7/11, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 6, 2011 at 4:23 PM, Vladimir Kokovic
vladimir.koko...@gmail.com wrote:
Hi,
Does it make sense to treat these ?
ALTER TABLE s'd.s'd.s's'd. ADD COLUMN id bigint DEFAULT
nextval('s''d.s''d.s''d.ds''');
ERROR: improper relation
Brendan Jurd dire...@gmail.com writes:
TRAP: FailedAssertion(!((data - start) == data_size), File:
heaptuple.c, Line: 255)
[ scratches head ... ] That implies that heap_fill_tuple came to a
different conclusion about a tuple's data size than the immediately
preceding heap_compute_data_size.
On 7 April 2011 16:56, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
TRAP: FailedAssertion(!((data - start) == data_size), File:
heaptuple.c, Line: 255)
[ scratches head ... ] That implies that heap_fill_tuple came to a
different conclusion about a tuple's data
Vladimir Kokovic vladimir.koko...@gmail.com writes:
On 4/7/11, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 6, 2011 at 4:23 PM, Vladimir Kokovic
vladimir.koko...@gmail.com wrote:
ALTER TABLE s'd.s'd.s's'd. ADD COLUMN id bigint DEFAULT
nextval('s''d.s''d.s''d.ds''');
ERROR: improper
hi,
I think I see what is going on now. We are sometimes failing to set the
commitSeqNo correctly on the lock. In particular, if a lock assigned to
OldCommittedSxact is marked with InvalidSerCommitNo, it will never be
cleared.
The attached patch corrects this:
On Thu, Apr 7, 2011 at 6:49 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/07/2011 12:29 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frostsfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising
On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan and...@dunslane.net wrote:
On 04/06/2011 01:34 PM, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:27 PM, Peter Eisentrautpete...@gmx.net wrote:
* I have some doubts about whether the SDK is at all needed or
whether it would suffice by
2011/4/7 Tatsuo Ishii is...@postgresql.org:
In my understanding pqc is not designed to be working with pgpool.
Thus if a user want to use both query cache and query dispatching,
replication or failover etc. which are provided by pgpool, it seems
it's not possible. For this purpose maybe user
On 04/07/2011 03:48 AM, Alastair Turner wrote:
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more
On Thu, Apr 7, 2011 at 2:38 AM, Peter Eisentraut pete...@gmx.net wrote:
#-comments seem like a fine idea.
But it would have to be the user that would put the comment in there,
since we can't really install a default file.
What about preparing something like pgpass.sample and installing it
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that they apply to superuser?
I think that's just about
On 04/07/2011 03:07 PM, Brendan Jurd wrote:
On 7 April 2011 16:56, Tom Lanet...@sss.pgh.pa.us wrote:
Brendan Jurddire...@gmail.com writes:
TRAP: FailedAssertion(!((data - start) == data_size), File:
heaptuple.c, Line: 255)
[ scratches head ... ] That implies that heap_fill_tuple came to a
On 04/07/2011 07:33 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that
The attached, applied patch preserves
pg_largeobject_metadata.relfrozenxid in pg_upgrade.
This is needed only in 9.1 because only 9.0 had this table and no one is
upgrading from a 9.0 beta to 9.0 anymore. We basically don't backpatch
9.0 beta fixes at this point.
--
Bruce Momjian
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more reason.
I
Excerpts from Brendan Jurd's message of jue abr 07 03:07:32 -0300 2011:
Hi folks,
I am running a 9.0.3 Hot Standy + Streaming Replication slave which
occasionally segfaults (every 1-2 days). I rebuilt Postgres with
--enable-cassert and --enable-debug, switched on core dumping and
waited
Andrew Dunstan and...@dunslane.net writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then that's probably the way to go.
Otherwise it seems more trouble than
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
LOG: could not truncate directory pg_serial: apparent
wraparound
Did you get a warning with this text?:
memory for serializable conflict tracking is nearly exhausted
If not, there's some sort of cleanup bug to fix in the predicate
locking's
On 04/07/2011 11:01 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then that's probably the way to go.
2011/4/5 Masanori Yamazaki myamazak...@gmail.com:
Hello
I am sending my proposal about Google Summer Of Code2011.
It would be nice if you could give me your opinion.
Fantastic! Please submit your proposal through the GSoC website:
I'm getting some pressure at Red Hat to back-patch this fix:
http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php
(commit dcb2bda9b7042dbf43f876c94ebf35d951de10e9)
into the RHEL 8.4.x postgresql release. Since I have to do the work
anyway, it seems to me to be sensible to commit
On Thu, Apr 7, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm getting some pressure at Red Hat to back-patch this fix:
http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php
(commit dcb2bda9b7042dbf43f876c94ebf35d951de10e9)
into the RHEL 8.4.x postgresql release. Since
Hi,
On Thursday 07 April 2011 18:10:35 Tom Lane wrote:
I don't currently have a need to fix this before 8.4, and it looks like
the existing patch doesn't apply easily to 8.3 anyway. So I'm only
proposing to do this in 8.4.
Comments, objections?
I personally look forward to that as it has
Bruce Momjian wrote:
OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
the two reported pg_upgrade problems he saw via IRC. It seems toast
tables have xids and pg_dump is not preserving the toast relfrozenxids
as it should. Heap tables have preserved relfrozenxids, but
Original Message
Subject: [TESTERS] [PostgreSQL 9.1 alpha5] OpenBSD and Loongson
Date: Thu, 7 Apr 2011 16:22:46 +0200
From: postgre...@raveland.org
To: pgsql-test...@postgresql.org
Hi,
I need the following patch to make PostgreSQL happy
on Loongson with OpenBSD
On 4/7/11 9:16 AM, Bruce Momjian wrote:
OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
the two reported pg_upgrade problems he saw via IRC.
BTW, just for the release notes, RhodiumToad == Andrew Gierth.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Josh Berkus j...@agliodbs.com writes:
I need the following patch to make PostgreSQL happy
on Loongson with OpenBSD (http://www.openbsd.org/loongson.html).
These restrictions no longer exist on OpenBSD.
Tested with the latest alpha (9.1 alpha5) and with
the latest 9 release (9.0.3).
I'm a bit
Hi!
We need to get a headcount for the PL Summit at PgCon on Saturday, May
21, 2011.
Please sign up using this form: http://chesnok.com/u/1r
A wiki page has been started here:
http://wiki.postgresql.org/wiki/PgCon_2011_PL_Summit
We're also working on updating this page:
On 8 April 2011 00:16, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Brendan Jurd's message of jue abr 07 03:07:32 -0300 2011:
I am running a 9.0.3 Hot Standy + Streaming Replication slave which
occasionally segfaults (every 1-2 days). I rebuilt Postgres with
--enable-cassert
On Mon, Apr 4, 2011 at 9:25 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Sun, Apr 3, 2011 at 6:40 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Sat, Apr 2, 2011 at 8:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Mar 31, 2011 at 5:38 PM, Merlin
On Thu, Apr 7, 2011 at 1:28 PM, Merlin Moncure mmonc...@gmail.com wrote:
int ByteOffset = xid / BITS_PER_BYTE;
whoops, I just notice this was wrong -- the byte offset needs to be
taking bucket into account. I need to clean this up some more
obviously, but the issues at
--On 28. März 2011 13:38:23 +0100 Bernd Helmle maili...@oopsware.de wrote:
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables. Anyone see a problem with that?
Hmm yeah, seems i was thinking too
Random thought: Wouldn't it be better if there were a setting in psql
that set the linestyle to unicode only if the client encoding was
actually UTF8? This might become more relevant as we set the client
encoding automatically in psql in 9.1. Then a setting of, say,
unicode-auto would do the
On Thu, 2011-04-07 at 12:16 -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
the two reported pg_upgrade problems he saw via IRC. It seems toast
tables have xids and pg_dump is not preserving the toast relfrozenxids
On Thu, Apr 07, 2011 at 12:16:55PM -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
the two reported pg_upgrade problems he saw via IRC. It seems toast
tables have xids and pg_dump is not preserving the toast
Jeff Davis wrote:
I have added a personal regression test to show which
pg_class.relfrozenxid values are not preserved, and with this patch the
only ones not preserved are toast tables used by system tables, which
are not copied from the old cluster (FirstNormalObjectId = 16384). I am
Peter Eisentraut pete...@gmx.net wrote:
Wouldn't it be better if there were a setting in psql that set the
linestyle to unicode only if the client encoding was actually
UTF8?
Is UTF8 the only client encoding in which we currently support the
Unicode character set?
-Kevin
--
Sent via
Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
it would probably be good to have some kind of automatic testing for it.
Attached is something I hacked together that at least exposes the
current problems, easily available by typing make check and waiting.
It does not yet
Another issue:
...\src\tools\msvcinstall foo bar
bar== was unexpected at this time.
This makes it seemingly impossible to install into a standard location
such as under C:\Program Files\.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On tor, 2011-04-07 at 09:26 +0100, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan and...@dunslane.net wrote:
On 04/06/2011 01:34 PM, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:27 PM, Peter Eisentrautpete...@gmx.net wrote:
* I have some doubts about whether the
On Thu, Apr 7, 2011 at 22:11, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-04-07 at 09:26 +0100, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan and...@dunslane.net wrote:
On 04/06/2011 01:34 PM, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:27 PM, Peter
On Thu, Apr 7, 2011 at 3:46 PM, Bruce Momjian br...@momjian.us wrote:
Jeff Davis wrote:
I have added a personal regression test to show which
pg_class.relfrozenxid values are not preserved, and with this patch the
only ones not preserved are toast tables used by system tables, which
are
On Thu, Apr 7, 2011 at 4:11 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-04-07 at 09:26 +0100, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan and...@dunslane.net wrote:
On 04/06/2011 01:34 PM, Dave Page wrote:
On Wed, Apr 6, 2011 at 6:27 PM, Peter
I wrote:
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
LOG: could not truncate directory pg_serial: apparent
wraparound
there's some sort of cleanup bug to fix in the predicate
locking's use of SLRU. It may be benign, but we won't really know
until we find it. I'm investigating.
Robert Haas robertmh...@gmail.com wrote:
ISTM we need to force a minor release once we are sure this has
been corrected. We had also probably put out an announcement
warning people that have already used pg_upgrade of possible data
corruption. I'm not sure exactly what the language around
As you people think and may be possible that complete implementation of
Eager MVs cannot be completed in summer. So maybe i can pick up the work
left to be done in snapshot MVs. I have cloned the repository of pavel baros
from https://github.com/pbaros/postgres.git and i will be looking to find
On Thu, 2011-04-07 at 15:46 -0400, Bruce Momjian wrote:
OK, so the only other idea I have is to write some pretty complicated
query function that does a sequential scan of each toast table and pulls
the earliest xmin/xmax from the tables and use that to set the
relfrozenxid (pretty complicated
On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut pete...@gmx.net wrote:
Add traceback information to PL/Python errors
This mimics the traceback information the Python interpreter prints
with exceptions.
Jan Urbański
On my system this spits out a warning:
plpython.c: In function
On Thu, Apr 7, 2011 at 4:02 PM, Peter Eisentraut pete...@gmx.net wrote:
Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
it would probably be good to have some kind of automatic testing for it.
Attached is something I hacked together that at least exposes the
current
On 07/04/11 23:01, Robert Haas wrote:
On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut pete...@gmx.net wrote:
Add traceback information to PL/Python errors
This mimics the traceback information the Python interpreter prints
with exceptions.
Jan Urbański
On my system this spits out a
Jeff Davis wrote:
On Thu, 2011-04-07 at 15:46 -0400, Bruce Momjian wrote:
OK, so the only other idea I have is to write some pretty complicated
query function that does a sequential scan of each toast table and pulls
the earliest xmin/xmax from the tables and use that to set the
Jeff Davis wrote:
On Thu, 2011-04-07 at 15:46 -0400, Bruce Momjian wrote:
OK, so the only other idea I have is to write some pretty complicated
query function that does a sequential scan of each toast table and pulls
the earliest xmin/xmax from the tables and use that to set the
Robert Haas wrote:
Well, that won't work, because VACUUM can't be executed in a transaction
block or function.
Good point.
The only bright part of this is that missing clog will throw an error so
we are not returning incorrect data, and hopefully people will report
problems to us
On fre, 2011-02-25 at 21:32 +0200, Peter Eisentraut wrote:
According to the online documentation, the APIs are there:
http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
Now we'd need someone brave try to make it work. The starting point
would be to define HAVE_LOCALE_T and then make it
Bruce Momjian wrote:
Robert Haas wrote:
Well, that won't work, because VACUUM can't be executed in a transaction
block or function.
Good point.
The only bright part of this is that missing clog will throw an error so
we are not returning incorrect data, and hopefully people
On tor, 2011-04-07 at 17:03 -0400, Robert Haas wrote:
I think it's a worthwhile thing to do, but right now I think it would
be more helpful if you could help fix the breakage your patch created,
rather than working on new stuff.
This is part of that.
--
Sent via pgsql-hackers mailing list
On ons, 2011-04-06 at 11:49 -0400, Noah Misch wrote:
Peter, were you planning to complete this? I can take a swing at it, if it
would be helpful.
Help is always welcome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, 2011-04-07 at 17:06 -0400, Bruce Momjian wrote:
I want to avoid anything that requires a compile because they are hard
for many sites to install so TransactionIdPrecedes() is out. We will
need to do this in PL/pgSQL probably.
PL/pgSQL can't see dead rows, so that would not be correct.
Jeff Davis wrote:
On Thu, 2011-04-07 at 17:06 -0400, Bruce Momjian wrote:
I want to avoid anything that requires a compile because they are hard
for many sites to install so TransactionIdPrecedes() is out. We will
need to do this in PL/pgSQL probably.
PL/pgSQL can't see dead rows, so
Bruce Momjian wrote:
Jeff Davis wrote:
On Thu, 2011-04-07 at 17:06 -0400, Bruce Momjian wrote:
I want to avoid anything that requires a compile because they are hard
for many sites to install so TransactionIdPrecedes() is out. We will
need to do this in PL/pgSQL probably.
Bruce Momjian br...@momjian.us wrote:
all we need to do is set those hint bits before the clog gets
remove, so maybe just a SELECT * would do the trick!
Does that mean that those experiencing the problem are failing to do
the vacuumdb run which is recommended in the pg_upgrade instructions?
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
all we need to do is set those hint bits before the clog gets
remove, so maybe just a SELECT * would do the trick!
Does that mean that those experiencing the problem are failing to do
the vacuumdb run which is recommended in
On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
Any idea how to correct existing systems? Would VACUUM FREEZE of just
the toast tables work?
VACUUM FREEZE will never set the relfrozenxid backward. If it was never
preserved to begin with, I assume that the existing value could be
Jeff Davis wrote:
On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
Any idea how to correct existing systems? Would VACUUM FREEZE of just
the toast tables work?
VACUUM FREEZE will never set the relfrozenxid backward. If it was never
preserved to begin with, I assume that the
On Thu, Apr 7, 2011 at 5:20 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-04-07 at 17:03 -0400, Robert Haas wrote:
I think it's a worthwhile thing to do, but right now I think it would
be more helpful if you could help fix the breakage your patch created,
rather than working on new
On Thu, Apr 7, 2011 at 4:49 PM, AAMIR KHAN ak4u2...@gmail.com wrote:
As you people think and may be possible that complete implementation of
Eager MVs cannot be completed in summer. So maybe i can pick up the work
left to be done in snapshot MVs. I have cloned the repository of pavel baros
On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian br...@momjian.us wrote:
Jeff Davis wrote:
On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
Any idea how to correct existing systems? Would VACUUM FREEZE of just
the toast tables work?
VACUUM FREEZE will never set the relfrozenxid
On Thu, Apr 7, 2011 at 5:06 PM, Jan Urbański wulc...@wulczer.org wrote:
On 07/04/11 23:01, Robert Haas wrote:
On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut pete...@gmx.net wrote:
Add traceback information to PL/Python errors
This mimics the traceback information the Python interpreter
Robert Haas wrote:
On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian br...@momjian.us wrote:
Jeff Davis wrote:
On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
Any idea how to correct existing systems? ?Would VACUUM FREEZE of just
the toast tables work?
VACUUM FREEZE will never
You had better start by getting a clear statement from Pavel as to
whether he wishes to release the code in that repository under the
PostgreSQL license. I am not sure that he ever formally submitted it.
I don't think it's reasonable for a student to do that. That really
needs to be up to
On 08/04/11 00:25, Robert Haas wrote:
On Thu, Apr 7, 2011 at 5:06 PM, Jan Urbański wulc...@wulczer.org wrote:
On 07/04/11 23:01, Robert Haas wrote:
On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut pete...@gmx.net wrote:
Add traceback information to PL/Python errors
This mimics the traceback
It appears that the command processor on Windows 7 has a few quirks that
we need to deal with. If you see odd buildfarm or MSVC build script
failures on W7 that's a likely cause. I'm digging further and should
have some fixes before long.
cheers
andrew
--
Sent via pgsql-hackers mailing
On Thu, Apr 07, 2011 at 02:49:29PM -0500, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
Wouldn't it be better if there were a setting in psql that set the
linestyle to unicode only if the client encoding was actually
UTF8?
Is UTF8 the only client encoding in which we
Bruce Momjian wrote:
Yes, it will be reasonable.
That means that VACUUM FREEZE of the toast table, if there are no
concurrent transactions, will freeze all of the tuples; and the
newFrozenXid should always be seen as newer than the existing (and
wrong) relfrozenxid. Then, it will
On Thu, 2011-04-07 at 20:14 -0400, Bruce Momjian wrote:
So I think we have four possible approaches to correct databases:
1) SELECT * to set the hint bits
2) VACUUM to set the hint bits
3) VACUUM FREEZE to remove the old xids
4) some complicated function
I don't
Jeff Davis wrote:
On Thu, 2011-04-07 at 20:14 -0400, Bruce Momjian wrote:
So I think we have four possible approaches to correct databases:
1) SELECT * to set the hint bits
2) VACUUM to set the hint bits
3) VACUUM FREEZE to remove the old xids
4) some complicated
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on warts such as $varname that are
completely at odds with the style
Noah Misch wrote:
On Thu, Apr 07, 2011 at 12:16:55PM -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
the two reported pg_upgrade problems he saw via IRC. It seems toast
tables have xids and pg_dump is not
On Apr 7, 2011, at 6:58 PM, Tom Lane wrote:
Well, if we're going to consider 100% backwards compatibility a must,
then we should just stick with what the submitted patch does, ie,
unqualified names are matched first to query columns, and to parameters
only if there's no column match. This is
On Thu, Apr 7, 2011 at 9:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
that we should feel free to add on
On Thu, Apr 7, 2011 at 6:31 PM, Josh Berkus j...@agliodbs.com wrote:
You had better start by getting a clear statement from Pavel as to
whether he wishes to release the code in that repository under the
PostgreSQL license. I am not sure that he ever formally submitted it.
I don't think it's
Robert Haas wrote:
I am halfway tempted to say that we need to invent our own procedural
language that is designed not for compatibility with the SQL standard
or Oracle, but for non-crappiness.
I'm way ahead of you on that one. -- Darren Duncan
--
Sent via pgsql-hackers mailing list
84 matches
Mail list logo
