On Wed, Feb 2, 2011 at 11:43 PM, Robert Haas wrote:
> Committed.
I did some more polishing of the documentation as well.
It would be good to have some buildfarm coverage of this code. Can we
find anyone brave enough to set up a buildfarm critter using
--with-selinux?
--
Robert Haas
Enterprise
On Wed, Feb 02, 2011 at 11:20:44PM +0200, Peter Eisentraut wrote:
> On l??r, 2011-01-29 at 02:52 -0500, Noah Misch wrote:
> > The new documentation is helpful. It would be useful to document the
> > implications of marking your user-defined type COLLATABLE. As best I can
> > tell,
> > you should
2011/1/27 KaiGai Kohei :
> (2011/01/27 22:26), Robert Haas wrote:
>> 2011/1/27 KaiGai Kohei:
>>> - Error messages become obtaining "%m", when the error was
>>> originated from the libselinux interfaces. It will provides
>>> DBA a hint why interactions with SELinux does not work well.
>>
>> No s
I am seeing the following compiler warning for the past few days:
basebackup.c:213: warning: variable `ptr' might be clobbered by
`longjmp' or `vfork'
and I see this comment in the file:
/*
* Actually do a base backup for the specified tablespaces.
*
On Tue, Feb 1, 2011 at 3:17 AM, Simon Riggs wrote:
> ERRCODE_DATABASE_DROPPED 57P04 looks best
So I guess the only remaining issue is whether we should distinguish
the error message text, as well as the error codes. Tom was in favor
of that upthread, and I am too. Right now we have:
On Wed, Feb 2, 2011 at 8:16 PM, Itagaki Takahiro
wrote:
> On Mon, Jan 31, 2011 at 05:17, Robert Haas wrote:
>>> The attached patch changes LogCheckpointEnd so that it logs
>>> the number of WAL files created/deleted/recycled even in
>>> restartpoint.
>>
>> This patch looks good to me. For now, I
On Mon, Jan 31, 2011 at 05:17, Robert Haas wrote:
>> The attached patch changes LogCheckpointEnd so that it logs
>> the number of WAL files created/deleted/recycled even in
>> restartpoint.
>
> This patch looks good to me. For now, I'm marking it Ready for
> Committer. Absent objections, I will
Brendan Jurd wrote:
> On 3 February 2011 10:54, Bruce Momjian wrote:
> > It seems LIKE is considering the trailing CHAR(10) field spaces as
> > significant, even though our documentations says:
> >
> -- snip --
> >
> > It says trailing spaces are not significant for character comparisons
> > --- t
On 3 February 2011 10:54, Bruce Momjian wrote:
> It seems LIKE is considering the trailing CHAR(10) field spaces as
> significant, even though our documentations says:
>
-- snip --
>
> It says trailing spaces are not significant for character comparisons
> --- the real question is whether LIKE is
I found a little LIKE/CHAR() surprise --- below is a table and query
against a CHAR(10) field:
test=> CREATE TABLE test (x char(10));
CREATE TABLE
test=> INSERT INTO test values ('hi');
INSERT 0 1
test=> SELECT * FROM test WHERE x = 'hi';
x
Aidan Van Dyk writes:
> My concern with this approach (upgrade is forced through all
> intermetiary versions) is that the shared libray now for version 15
> *has* to have all the "intermediary" compatibility for *all* versions
> in it. So it has to have functions with all symbols so the "CREATE
>
On Wed, Feb 2, 2011 at 12:31 PM, David E. Wheeler wrote:
> They are identical except for the extra line in the second one. If I had, say
> 15 different versions of an extension, then I'd have 15 upgrade scripts.
> That's fine. But in your plan, the script to upgrade from version 1 to
> version
On 03/02/11 10:08, Vaibhav Kaushal wrote:
Since postgres has 'Elephants' as its LOGO / ICON, I apologize in particular
about that email and request the moderators / admins to kindly forgive me
let me stay in the list. I sincerely apologize for the mistake.
This is probably the best list to acc
Heikki Linnakangas wrote:
On 02.02.2011 19:36, Kevin Grittner wrote:
>> If that part is right, it shouldn't take me very long to finish
>> the specs and capture the expected results.
> Looks good.
First cut on the rest of it pushed. I'll want to go over it again to
confirm, but I think all
On tor, 2010-12-23 at 15:32 +0100, Jan Urbański wrote:
> with plpy.subxact():
> plpy.execute("insert into t values (1)")
> plpy.execute("insert into t values (2)")
> plpy.execute("ooops")
Looks pretty cool, but maybe s/subxact/subtransaction/.
--
Sent via pgsql-hackers mailing list
On lör, 2011-01-29 at 02:52 -0500, Noah Misch wrote:
> I'm reviewing this patch as part of CommitFest 2011-01.
Thank you very much for this thorough review.
> This no longer applies cleanly against git master, so I've done my testing
> against 52713d0.
I will send an updated patch soon, when I
Hello all,
I am sorry for sending an email about elephants to the hackers list. It was
accidental.
This mailing list is the only mailing list which I am subscribed to. Most
others are on a different email address.
Actually I was using some website which said that it was trying to save
trees and
Hi ,I have just shown my support for India's forests. Please see the mail below and support our forests at http://www.greenpeace.org/india/en/What-We-Do/Stop-Climate-Change/Quit-Coal/support-the-forests/
Regards,
Dear ,
The attached patch simplifies pg_upgrade's checking of executables, per
suggestion from Robert Haas.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/e
> >>> You mentioned that you were going to add a few paragraphs to the
> >>> documentation saying that you can now actually catch SPI errors. I
> >>> haven't seen that yet.
> >>
> >> Yeah, I'm procrastinating the doc writing part ;) Will spit something
> >> out by the end of the (CET) day.
> >
> >
On Wed, 2011-02-02 at 14:26 +0100, Magnus Hagander wrote:
> Attached patch adds some more "metadata" to walsender results:
>
> * Adds the current xlog insert location as a third column in IDENTIFY_SYSTEM
> * Adds a resultset at the start of a base backup that contains the
> start xlog location (as
On Wed, Feb 2, 2011 at 12:31 PM, David E. Wheeler wrote:
>
> They are identical except for the extra line in the second one. If I had, say
> 15 different versions of an extension, then I'd have 15 upgrade scripts.
> That's fine. But in your plan, the script to upgrade from version 1 to
> versi
"David E. Wheeler" writes:
> On Feb 2, 2011, at 10:14 AM, Aidan Van Dyk wrote:
>
>> My concern with this approach (upgrade is forced through all
>> intermetiary versions) is that the shared libray now for version 15
>> *has* to have all the "intermediary" compatibility for *all* versions
>> in it
On Feb 2, 2011, at 10:22 AM, Dimitri Fontaine wrote:
> Either one line in the Makefile or a new file with the \i equivalent
> lines, that would maybe look like:
>
> SELECT pg_execute_sql_file('upgrade.v14.sql');
> SELECT pg_execute_sql_file('upgrade.v15.sql');
>
> So well… I don't see how you'
On Feb 2, 2011, at 10:14 AM, Aidan Van Dyk wrote:
> My concern with this approach (upgrade is forced through all
> intermetiary versions) is that the shared libray now for version 15
> *has* to have all the "intermediary" compatibility for *all* versions
> in it. So it has to have functions with
"David E. Wheeler" writes:
>> upgrade.null-v15.sql: upgrade.v14.sql upgrade.v15.sql
>> cat upgrade.v14.sql upgrade.v15.sql > $@
>
> Sure, if you know Make really well. But then I need to add a line to
> the Makefile for every bloody upgrade script. Gross.
Either one line in the Makefile or a
On Sun, 2011-01-30 at 17:14 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > On Sun, 2011-01-30 at 02:55 +, Thom Brown wrote:
> >> postgres=# select '[18,20]'::numrange @> 19;
> >> ERROR: operator does not exist: numrange @> integer
> >> LINE 1: select '[18,20]'::numrange @> 19;
> >> ^
> >> HI
On Feb 2, 2011, at 10:04 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> They are identical except for the extra line in the second one. If I
>> had, say 15 different versions of an extension, then I'd have 15
>> upgrade scripts. That's fine. But in your plan, the script to upgrade
>>
"David E. Wheeler" writes:
> They are identical except for the extra line in the second one. If I
> had, say 15 different versions of an extension, then I'd have 15
> upgrade scripts. That's fine. But in your plan, the script to upgrade
> from version 1 to version 15 would have all the same code a
Heikki Linnakangas wrote:
> A comment would be in order to explain why we only print the
> primary message.
Done:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=ddeea22db06ed763b39f716b86db248008a3aa92
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 02.02.2011 19:36, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Suppressing detail seems easiest. AFAICS all the variable parts are
in errdetail.
I pushed that with some work on the tests. If you could review the
changes to isolationtester.c to confirm that they look sane, I'd
apprecia
Heikki Linnakangas wrote:
> Suppressing detail seems easiest. AFAICS all the variable parts are
> in errdetail.
I pushed that with some work on the tests. If you could review the
changes to isolationtester.c to confirm that they look sane, I'd
appreciate it.
http://git.postgresql.org/gitweb
On Feb 2, 2011, at 9:19 AM, Dimitri Fontaine wrote:
> I see there no solution to your reaction here. Please take the time to
> tell us more about what exactly it is that you hated, and how to make it
> lovely. We won't make any progress with your current commenting style.
Here is your example o
"David E. Wheeler" writes:
> On Feb 2, 2011, at 9:03 AM, Dimitri Fontaine wrote:
>
>> Well, fair enough I suppose. Or it would be if you gave me an
>> alternative that provides a simpler way to support those 3 upgrades.
>
> I did: a naming convention with upgrade scripts that have the version
>
I'm sorry I'm late to this party. I haven't been keeping up with pgsql-hackers.
I'd kind'a hoped that this functionality could be tied into extending
PL/Perl to handle named arguments. That way the perl variables
corresponding to the named arguments could be given references without
breaking any c
On 02/02/2011 11:45 AM, Tim Bunce wrote:
But why are we bothering to keep $prolog at
all any more, if all we're going to pass it is&PL_sv_no all the
time? Maybe we'll have a use for it in the future, but right now we
don't appear to unless I'm missing something.
PostgreSQL::PLPerl::NYTProf wou
On Feb 2, 2011, at 9:03 AM, Dimitri Fontaine wrote:
> Well, fair enough I suppose. Or it would be if you gave me an
> alternative that provides a simpler way to support those 3 upgrades.
I did: a naming convention with upgrade scripts that have the version number in
them. You rejected it.
> Of
"David E. Wheeler" writes:
> On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:
>
>> Well, you write 3 scripts.
>>
>> Let's consider an example, the lo contrib, with its 3 objects:
>>
>> CREATE DOMAIN lo AS pg_catalog.oid;
>> CREATE OR REPLACE FUNCTION lo_oid(lo) …
>> CREATE OR REPLACE FUNCT
On Wed, Feb 2, 2011 at 17:43, Heikki Linnakangas
wrote:
> On 02.02.2011 16:36, Magnus Hagander wrote:
>>
>> When running pg_basebackup with -x to include all transaction log, the
>> server will still throw a warning about xlog archiving if it's not
>> enabled - that is completely irrelevant since
On Mon, Jan 31, 2011 at 02:22:37PM -0500, Andrew Dunstan wrote:
>
>
> On 01/15/2011 12:31 AM, Alex Hunsaker wrote:
> >On Tue, Dec 7, 2010 at 07:24, Tim Bunce wrote:
> >>Changes:
> >>
> >>Sets the local $_TD via C instead of passing an extra argument.
> >>So functions no longer start with
On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:
> Well, you write 3 scripts.
>
> Let's consider an example, the lo contrib, with its 3 objects:
>
> CREATE DOMAIN lo AS pg_catalog.oid;
> CREATE OR REPLACE FUNCTION lo_oid(lo) …
> CREATE OR REPLACE FUNCTION lo_manage() …
>
> Now, the upgrad
On 02.02.2011 16:36, Magnus Hagander wrote:
When running pg_basebackup with -x to include all transaction log, the
server will still throw a warning about xlog archiving if it's not
enabled - that is completely irrelevant since pg_basebackup has
included it already (and if it was gone, the base b
Luis Ochoa wrote:
> Hi everyone, I just want to know something about postgresql parser, because
> I want to add a new feature for pgAdmin graphical query builder (GQB) that
> allow an user to create a query graphical model from a sql statment, and I
> just want to reuse postgres parser code (reuse
On 02.02.2011 17:52, Kevin Grittner wrote:
I found two problems with this, and I'm not sure how to handle
either. If we can figure out an approach, I'm happy to work on it.
(1) We don't have much in the way of detail yet. I put a different
detail message on each, so that there is more evidenc
I'm trying to follow where we are on SQL-MED and it's difficult. We have
patches on patches and working out what's current is by no means easy.
Is there an available git repo I can pull from that contains the current
state? That would be *so* much easier than trying to extract a
non-trivial n
Tom Lane wrote:
> Andrew Dunstan writes:
> > On 02/01/2011 05:47 PM, Bruce Momjian wrote:
> >> Tom Lane wrote:
> >>> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
> >>> and it's difficult to see how to get any real improvement without tackling
> >>> that.
>
> >> Do we
Heikki Linnakangas wrote:
> I converted the next test, receipt-report, grab that from my git
> repository first. It produces over two hundred permutations, so
> it's going to be a bit tedious to check the output for that, but I
> think it's still acceptable so that we don't need more complicated
Hi,
Anssi Kääriäinen writes:
> There is one make check error:
> test rules... FAILED
I forgot to update the pg_available_extensions system view in the tests,
but failed to do so in the extension's patch too, where Itagaki fixed
it. Will fix if not beaten to it, in which case
On 2011-01-28 10:12 AM +0200, I wrote:
I still didn't
address the issue with pg_advisory_unlock_all() releasing transaction
scoped locks, but I'm going to.
.. and here's the patch. I'm not too confident with the code I added to
storage/lmgr/lock.c, but it seems to be working.
Earlier there
Itagaki Takahiro writes:
> The latest extension might drop some functions.
Then the upgrade script contains the DROP commands.
> I'm still not clear what "upgrade" means. if module authors wrote
> functions with C, they can just replace .so to upgrade. If with
> SQL or PL/pgSQL, they should exec
When running pg_basebackup with -x to include all transaction log, the
server will still throw a warning about xlog archiving if it's not
enabled - that is completely irrelevant since pg_basebackup has
included it already (and if it was gone, the base backup step itself
will fail - actual error and
On 02.02.2011 16:27, Kevin Grittner wrote:
Heikki Linnakangas wrote:
It produces over two hundred permutations, so it's going to be a
bit tedious to check the output for that, but I think it's still
acceptable so that we don't need more complicated rules for what is
accepted. IOW, we can just p
Heikki Linnakangas wrote:
> I converted the next test, receipt-report, grab that from my git
> repository first.
Will do.
> It produces over two hundred permutations, so it's going to be a
> bit tedious to check the output for that, but I think it's still
> acceptable so that we don't need m
On 02.02.2011 16:11, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 02.02.2011 12:20, Heikki Linnakangas wrote:
The tests don't seem very complicated, and they don't seem to
depend much on the dtester features. How hard would it be to
rewrite the test engine in C or perl?
I'm thinking o
Heikki Linnakangas wrote:
> On 02.02.2011 12:20, Heikki Linnakangas wrote:
>> The tests don't seem very complicated, and they don't seem to
>> depend much on the dtester features. How hard would it be to
>> rewrite the test engine in C or perl?
>>
>> I'm thinking of defining each test in a simpl
On Wed, Feb 2, 2011 at 5:22 AM, Ibrar Ahmed wrote:
> Hi!,
>
> I have reviewed/tested this patch.
>
> OS = "Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC
> 2010 i686 GNU/Linux"
> PostgreSQL Version = Head (9.1devel)
>
> Patch gives the desired results(still testing), but co
On 11-01-27 05:11 PM, Jan Urbański wrote:
On 23/12/10 15:32, Jan Urbański wrote:
Here's a patch implementing explicitly starting subtransactions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the spi-in-subxacts patch sent eari
Attached patch adds some more "metadata" to walsender results:
* Adds the current xlog insert location as a third column in IDENTIFY_SYSTEM
* Adds a resultset at the start of a base backup that contains the
start xlog location (as returned by do_pg_start_backup)
* Adds a resultset at the end of a
Hi!,
I have reviewed/tested this patch.
OS = "Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC
2010 i686 GNU/Linux"
PostgreSQL Version = Head (9.1devel)
Patch gives the desired results(still testing), but couple of questions with
this portion of the code.
*
if (conn->
Heikki,
On 02/02/2011 02:04 PM, Heikki Linnakangas wrote:
> TypeError: __init__() got an unexpected keyword argument 'showTimingInfo'
> make: *** [dcheck] Virhe 1
>
> At that point I had no idea what's wrong.
Hm.. looks like Kevin already uses the latest dtester code from git.
You can either do
On Wed, Feb 2, 2011 at 20:29, Dimitri Fontaine wrote:
> I didn't think about "detach", I'm not sure I see the use case…
The latest extension might drop some functions.
> It's not about upgrading major versions, it's about upgrading
> extensions. The only time you will need to run the scripts in
On 02.02.2011 14:48, Markus Wanner wrote:
Heikki,
On 02/02/2011 11:20 AM, Heikki Linnakangas wrote:
I couldn't get it to run on my basic Debian system, clearly I'm
doing something wrong, but it will be even harder for people on more
exotic platforms.
On Debian you only need 'python-twisted' a
On 02.02.2011 12:20, Heikki Linnakangas wrote:
On 26.01.2011 13:36, Simon Riggs wrote:
I looked at the patch to begin a review and immediately saw "dtest".
There's no docs to explain what it is, but a few comments fill me in a
little more. Can we document that please? And/or explain why its an
e
Heikki,
On 02/02/2011 11:20 AM, Heikki Linnakangas wrote:
> I couldn't get it to run on my basic Debian system, clearly I'm
> doing something wrong, but it will be even harder for people on more
> exotic platforms.
On Debian you only need 'python-twisted' and the dtester sources [1],
IIRC. What
Itagaki Takahiro writes:
> Excuse me for asking, but could you explain what is the purpose?
> Which is true, "upgrade to 9.1 from past versions" or "upgrade
> from 9.1 to future versions"? Also, how much advantage will we
> have compared with uninstall_MODULE.sql + CREATE EXTENSION?
Both are "tr
On Wed, Feb 2, 2011 at 03:21, Dimitri Fontaine wrote:
> PFA version 3 of the ALTER EXTENSION PATCH, cleaned and merged against
> recent HEAD and extension's branch from which I just produced the v30
> patch.
Excuse me for asking, but could you explain what is the purpose?
Which is true, "upgrade
On 26.01.2011 13:36, Simon Riggs wrote:
I looked at the patch to begin a review and immediately saw "dtest".
There's no docs to explain what it is, but a few comments fill me in a
little more. Can we document that please? And/or explain why its an
essential part of this commit? Could we keep it o
67 matches
Mail list logo
