Andrew Dunstan wrote:
> Hmm. OK. Well here is a patch that tries to fix the xmlconcat error,
> anyway. It seems to work, but maybe could stand a little tightening.
Can we take the patch for 9.0? The bug is registered as an open item:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
A
Tom, Robert, etc.
Ok, this issue seems to be specific to some versions of gcc. Note that
in testing this nobody enabled any special compile or environment
variables of any kind, so if there's a -Werror where it shouldn't be,
it's in our code.
Succeeds on:
Red Hat, gcc 4.4.3
OSX, gcc 4.2.1
Debian
On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas wrote:
> It's probably also easy to fix so that it doesn't NEED to be documented.
>
> The thing is, when dealing with new features, we reduce our overall
> maintenance burden if we get it right the first time. Obviously it's
> too late for major changes
Pei He wrote:
> The extension functions was developed by C++ mixed with C.
> ERROR: incompatible library
> "/home/hepei/bin/Chameleon/lib/libspgist_trie.so": missing magic block
> HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro.
You can use extern "C" blocks for PG_MOD
> No, you stuck in -Werror. Don't do that on bleeding-edge gcc (or
> bleeding-edge anything).
Found it ... Robert, you stuck a -Werror in the gzip file you uploaded
(but not, for some reason, the bzip).
--
-- Josh Berkus
Po
On 4/1/10 9:57 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Hmmm. I appear to have had a compile error with that alpha5 tarball,
>> in elog.c. No special options on compile, except an alternate directory
>> and port.
>
> No, you stuck in -Werror. Don't do that on bleeding-edge gcc (or
> bleed
Josh Berkus writes:
> Hmmm. I appear to have had a compile error with that alpha5 tarball,
> in elog.c. No special options on compile, except an alternate directory
> and port.
No, you stuck in -Werror. Don't do that on bleeding-edge gcc (or
bleeding-edge anything).
r
Guys,
Hmmm. I appear to have had a compile error with that alpha5 tarball,
in elog.c. No special options on compile, except an alternate directory
and port.
Ubunutu 9.10 server
GCC 4.3.3
Tries both:
./configure --with-pgport=5490 --prefix=/usr/local/pgsql/9.0/
and:
./configure --with-pgport=54
Dne 1.4.2010 5:39, Joseph Adams napsal(a):
I ended up reinventing the wheel and writing another JSON library:
http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
This is a first release, and it doesn't really have a name besides
"json". It's very similar to cJSON, except it is (sa
Robert, Dave,
Thanks so much for building these.
Hopefully we'll get a good turnout and get a lot of things tested.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
> Sure -- use CREATE UNIQUE INDEX.
>
> alvherre=# create function singleton(int) returns int immutable language sql
as $$ select 1 $$;
> CREATE FUNCTION
> alvherre=# create table singleton (a int);
> CREATE TABLE
> alvherre=# create unique index only_one on singleton (singleton(a));
> CREATE IND
On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas wrote:
> Can someone explain to me in plain language what problem this is
> trying to fix? I'm having trouble figuring it out.
The problem is that pg_xlogfile_name(pg_last_xlog_receive_location()) and
pg_xlogfile_name(pg_last_xlog_replay_location()) mi
Hi,
I have some old code for extension functions in Postgres 8.0. And, I
am trying to make it work with Postgres 8.2.
One problem is about the Magic Block.
The extension functions was developed by C++ mixed with C.
The code is like:
extern "C" Datum spgistinsert(PG_FUNCTION_ARGS)
{
...
}
I have
On Tue, 2010-03-30 at 22:40 -0400, Robert Haas wrote:
> I discovered tonight that if you shut down a server, create
> recovery.conf with standby_mode = 'on', and start it back up again,
> you get this:
>
> LOG: database system was shut down at 2010-03-30 22:34:09 EDT
> LOG: entering standby mode
On Thu, 2010-04-01 at 11:49 -0700, Josh Berkus wrote:
> > The thing is, when dealing with new features, we reduce our overall
> > maintenance burden if we get it right the first time. Obviously it's
> > too late for major changes, but minor adjustments to maintain the POLA
> > seem like exactly wh
On Thu, Apr 1, 2010 at 2:31 PM, Dave Page wrote:
> On Thu, Apr 1, 2010 at 5:24 AM, Robert Haas wrote:
>> This stuff is now also at:
>>
>> ftp://developer.postgresql.org/pub/source/9.0alpha5/
>
> Thanks Robert. We're working on this, but it seems that changes in the
> PG build have broken the debu
Josh Berkus writes:
> Oh, I agree. Since we have a separate WALSender limit, it seems
> counter-intuitive and difficult-to-admin to have the WALSenders also
> limited by superuser_connections. They should be their own separate
> connection pool, just like the other "background" processes.
+1
R
> The thing is, when dealing with new features, we reduce our overall
> maintenance burden if we get it right the first time. Obviously it's
> too late for major changes, but minor adjustments to maintain the POLA
> seem like exactly what we SHOULD be doing right now.
Oh, I agree. Since we have
On Thu, Apr 1, 2010 at 1:46 PM, Josh Berkus wrote:
> On 4/1/10 10:44 AM, Kevin Grittner wrote:
>> It seems within the realm of possibility that not all users would
>> think to boost superuser_reserved_connections by the number of
>> replication connections, and be surprised when they are unable to
On 4/1/10 10:44 AM, Kevin Grittner wrote:
> It seems within the realm of possibility that not all users would
> think to boost superuser_reserved_connections by the number of
> replication connections, and be surprised when they are unable to
> connect in an emergency.
Well, that's easy to add to
Tom Lane wrote:
> Having replication connections use superuser reserved slots seems
> exactly the behavior I'd expect given that they are running as
> superuser.
It seems within the realm of possibility that not all users would
think to boost superuser_reserved_connections by the number of
rep
Robert Haas writes:
> That seems pretty reasonable to me. I haven't checked how much code
> impact there is. I know Tom doesn't think we should change it at all,
> but surely pre-beta is the time to fix nasty corner cases that were
> added by recently committed patches?
What nasty corner case?
2010/4/1 Robert Haas :
> On Wed, Mar 31, 2010 at 11:05 AM, Pavel Stehule
> wrote:
>> Can somebody help me?
>
> I think it's pretty hopeless to try to debug this without the complete
> source code...
I am sorry. I am able to write test case, but I leaved it. Simply, I
don't use a function mremap.
On 04/01/2010 09:54 AM, Scott Marlowe wrote:
On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler wrote:
On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
I prefer to dump all my data in a big text file and grep it for the information
I need.
As long as you implement your own grep, that soun
On Tue, Mar 30, 2010 at 5:14 AM, Fujii Masao wrote:
> On Wed, Mar 3, 2010 at 11:03 PM, Fujii Masao wrote:
>> On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao wrote:
It's not clear what it should return, a TLI corresponding the filename
of the WAL segment the record was replayed from, so th
On Thu, Apr 1, 2010 at 9:09 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas wrote:
>>> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote:
You mean that we should change replication connection not to consume
superuser_reserved_connecti
On Wed, Mar 31, 2010 at 11:05 AM, Pavel Stehule wrote:
> Can somebody help me?
I think it's pretty hopeless to try to debug this without the complete
source code...
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On Thu, 2010-04-01 at 10:54 -0600, Scott Marlowe wrote:
> On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler
> wrote:
> > On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
> >
> >>> I prefer to dump all my data in a big text file and grep it for the
> >>> information I need.
> >>
> >> As long as
On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler wrote:
> On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
>
>>> I prefer to dump all my data in a big text file and grep it for the
>>> information I need.
>>
>> As long as you implement your own grep, that sounds about on par with
>> the curren
2010/4/1 :
>> Following a great deal of discussion, I'm pleased to announce that the
>> PostgreSQL Core team has decided that the major theme for the 9.1
>> release, due in 2011, will be 'NoSQL'.
>>
>
> Please, provide me your address so I can forward you the "health care"
> bills I had to pay due
Yeb Havinga writes:
>
>
>
>
>
>
> Tom Lane wrote:
>
>
> In principle it could look something like
[ etc etc ]
Please do not send HTML-only email to the lists. It's a PITA to work with.
Anyway, I hadn't looked at your patch before, but now that I have, it's
not even approximately wh
On Tue, Mar 30, 2010 at 3:26 AM, Zhai Boxuan wrote:
> To whom may concern,
> projects provided by postgres in google Summer Code of this year. I think
> the MERGE command in TO DO list is a suitable topic for me.
> I have read some infor about the MERGE command, which has not been
> implemented ye
On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
>> I prefer to dump all my data in a big text file and grep it for the
>> information I need.
>
> As long as you implement your own grep, that sounds about on par with
> the current trends! Go for it!
Well, first you have to implement your own
> Following a great deal of discussion, I'm pleased to announce that the
> PostgreSQL Core team has decided that the major theme for the 9.1
> release, due in 2011, will be 'NoSQL'.
>
Please, provide me your address so I can forward you the "health care"
bills I had to pay due to the heart attack
On Thu, Apr 1, 2010 at 9:59 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> While psql is careful to schema-qualify all references to built-in
>> objects (pg_catalog.*), it completely neglects to do this for built-in
>> operators,
>
> That's intentional because of the utter lack of readability
Alvaro Herrera writes:
> The reason it's not supported in table_constraint, IIUC, is that the
> standard doesn't allow it, and that syntax is standards-mandated.
The real problem is not so much extending the syntax as that there'd be
no way to represent the constraint in information_schema. Excl
On Wed, Mar 31, 2010 at 10:34:41PM -0400, Bruce Momjian wrote:
> Matthew Altus wrote:
> > Hey,
> >
> > After dealing with a production fault and having to rollback all the time,
> > I
> > kept typing a different word instead of rollback. So I created a patch to
> > accept this word as an alias
Dmitry Fefelov wrote:
> So, deferrable uniques now can be based on column/columns list only. It will
> be very useful if there will be possibility to specify functions in this
> list.
> Is it possible?
Sure -- use CREATE UNIQUE INDEX.
alvherre=# create function singleton(int) returns int imm
Heikki Linnakangas writes:
> Fujii Masao wrote:
>> Preventing superuser connections from consuming
>> superuser_reserved_connections
>> slots seems strange for me. So I'm leaning toward just removing superuser
>> privilege from replication connection again. Thought?
> That would be good, but I f
Bruce Momjian writes:
> + Exclusion constraints ensure that if any two rows are compared on
> + the specified columns or expressions using the specified operators,
> + at least one of these operator comparisons will be false. The syntax is:
Isn't that phrasing outright incorrect? Con
Peter Eisentraut writes:
> While psql is careful to schema-qualify all references to built-in
> objects (pg_catalog.*), it completely neglects to do this for built-in
> operators,
That's intentional because of the utter lack of readability that
results if you try to use OPERATOR() everywhere ...
Jeff wrote:
On Mar 30, 2010, at 8:15 AM, Stefan Kaltenbrunner wrote:
Peter Eisentraut wrote:
On tis, 2010-03-30 at 08:39 +0200, Stefan Kaltenbrunner wrote:
on fast systems pg_dump is completely CPU bottlenecked
Might be useful to profile why that is. I don't think pg_dump has
historically
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> While psql is careful to schema-qualify all references to built-in
> objects (pg_catalog.*), it completely neglects to do this for built-in
> operators, which can lead to surprising misbehaviors when users have
> created custom operators. Her
On Mar 30, 2010, at 8:15 AM, Stefan Kaltenbrunner wrote:
Peter Eisentraut wrote:
On tis, 2010-03-30 at 08:39 +0200, Stefan Kaltenbrunner wrote:
on fast systems pg_dump is completely CPU bottlenecked
Might be useful to profile why that is. I don't think pg_dump has
historically been develope
On Thu, Apr 1, 2010 at 5:24 AM, Robert Haas wrote:
> This stuff is now also at:
>
> ftp://developer.postgresql.org/pub/source/9.0alpha5/
Thanks Robert. We're working on this, but it seems that changes in the
PG build have broken the debugger again. Hopefully we can get it
sorted before the holida
Hello
this version has enhanced AllocSet allocator - it can use a mmap API.
Regards
Pavel Stehule
preload.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Fujii Masao wrote:
> On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas wrote:
>> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote:
>>> You mean that we should change replication connection not to consume
>>> superuser_reserved_connections slots in 9.0?
>> Yes.
I think it's good that walsenders can
Tom Lane wrote:
In principle it could look something like
(SubPlan N ($0 := b.oid))
but with a few parameters and a bunch of other stuff on the same line
that would get out of hand.
The patch I submitted to implement this, hits bogus varno:65001 in get_vari
On Thu, Apr 1, 2010 at 7:18 AM, Simon Riggs wrote:
> I'm not willing to investigate this further myself at this stage. This
> looks like risk for little benefit.
That's kind of what I figured. I'll see about fixing up Fujii-san's
patch and documenting the behavior; but it won't happen before the
On Thu, 2010-04-01 at 06:48 -0400, Robert Haas wrote:
> On Thu, Apr 1, 2010 at 4:42 AM, Fujii Masao wrote:
> > On Thu, Apr 1, 2010 at 12:16 AM, Robert Haas wrote:
> >> On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs wrote:
> > >From what I have seen, the comment about PM_WAIT_BACKENDS is
> >>
On Thu, Apr 1, 2010 at 4:42 AM, Fujii Masao wrote:
> On Thu, Apr 1, 2010 at 12:16 AM, Robert Haas wrote:
>> On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs wrote:
> >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect.
> "backends might be waiting for the WAL record tha
2010/4/1 Thom Brown :
> On 1 April 2010 09:13, Dave Page wrote:
>>
>> Following a great deal of discussion, I'm pleased to announce that the
>> PostgreSQL Core team has decided that the major theme for the 9.1
>> release, due in 2011, will be 'NoSQL'.
>>
>> There is a growing trend towards NoSQL d
On 1 April 2010 01:51, Robert Haas wrote:
> On Wed, Mar 31, 2010 at 11:24 AM, Thom Brown wrote:
> > [patch]
>
> As a general rule, I really appreciate people being willing to take
> the time to put proposed changes into patch form, even if they're
> small, but this three-line patch contains two
On 31 March 2010 06:58, Dmitry Fefelov wrote:
> For now Postgres able to create deferrable uniques with following syntax:
>
> ...
> and table_constraint is:
>
> [ CONSTRAINT constraint_name ]
> { UNIQUE ( column_name [, ... ] ) index_parameters |
> PRIMARY KEY ( column_name [, ... ] ) index_param
Nice to hear and thumbs up! I've just start planning to migrate one of
my telco 3Tb database running blunt oracle to coachDb but now of
course postgres looks better. Hopefully stupid transactions will be
abrogated to
wbr Ilya
On Thu, Apr 1, 2010 at 12:33 PM, Dave Page wrote:
> On Thu, Apr 1, 20
Ciao Dave,
> You may also notice that without SQL, the project name is somewhat
> misleading. To address that, the project name will be changed to
> 'PostgreQUEL' with the 9.1 release. We expect this will also put an
> end to the periodic debates on changing the project name.
Ahahahah ... nice fi
On Thu, Apr 1, 2010 at 12:16 AM, Robert Haas wrote:
> On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs wrote:
>>> > >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect.
>>> > "backends might be waiting for the WAL record that conflicts with their
>>> > queries to be replayed". Rec
On Wed, Mar 31, 2010 at 01:15:20PM +0200, Boszormenyi Zoltan wrote:
> I was thinking about something like the attached patch.
> It passes all the regression tests.
Thanks. Applied.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaF
On Thu, Apr 1, 2010 at 9:30 AM, Thom Brown wrote:
> I prefer to dump all my data in a big text file and grep it for the
> information I need.
There's no need to start showing off and get all technical y'know.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-hackers
On 1 April 2010 09:13, Dave Page wrote:
> Following a great deal of discussion, I'm pleased to announce that the
> PostgreSQL Core team has decided that the major theme for the 9.1
> release, due in 2011, will be 'NoSQL'.
>
> There is a growing trend towards NoSQL databases, with major sites
> li
Hi,
here's a little beautified patch:
- more logical parameter order in ECPGdump_a_type()
- use mm_strdup() instead of strdup() (I notoriously forget this)
- actually bail out with ET_FATAL if the local variable is
of a different type than the global variable that was used in
the DECLARE in th
Following a great deal of discussion, I'm pleased to announce that the
PostgreSQL Core team has decided that the major theme for the 9.1
release, due in 2011, will be 'NoSQL'.
There is a growing trend towards NoSQL databases, with major sites
like Twitter and Facebook utilising them extensively. N
62 matches
Mail list logo
