Hello
I checked query and I was surprised with very strange plan:
postgres=# create table a(a int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"a_pkey" for table "a"
CREATE TABLE
postgres=# create table b(b int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will
(2010/01/12 10:27), Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane wrote:
>>> Robert Haas writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan for how to organize all of our permissions checks
ough
On Tue, 2010-01-12 at 08:24 +0100, Stefan Kaltenbrunner wrote:
> Fujii Masao wrote:
> > On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith wrote:
> >> I don't think anybody can deploy this feature without at least some very
> >> basic monitoring here. I like the basic proposal you made back in
> >> Sep
Fujii Masao wrote:
On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith wrote:
I don't think anybody can deploy this feature without at least some very
basic monitoring here. I like the basic proposal you made back in September
for adding a pg_standbys_xlog_location to replace what you have to get from
Greg Smith wrote:
> I don't think anybody can deploy this feature without at least some very
> basic monitoring here. I like the basic proposal you made back in
> September for adding a pg_standbys_xlog_location to replace what you
> have to get from ps right now:
> http://archives.postgresql.org
> The consensus view on this thread seems to be that we should have a
> time-based code freeze, but not a time-based release. No one has
> argued (and I sincerely hope no one will argue) that we should let the
> last CommitFest drag on and on, as we did for 8.4. However, many
> people are still e
On 01/07/10 22:37, Andres Freund wrote:
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
Andres Freund writes:
I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as "revert to old code and add two step killing (thats
likely around 10 lines or so)".
On 01/07/10 22:37, Andres Freund wrote:
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
Andres Freund writes:
I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as "revert to old code and add two step killing (thats
likely around 10 lines or so)".
On Tue, Jan 12, 2010 at 1:24 PM, Greg Smith wrote:
> It's impossible for the database to have any idea whatsoever how people are
> going to want to be alerted. Provide functions to monitor things like
> replication lag, like the number of segments queued up to feed to
> archive_command, and let p
On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith wrote:
> I don't think anybody can deploy this feature without at least some very
> basic monitoring here. I like the basic proposal you made back in September
> for adding a pg_standbys_xlog_location to replace what you have to get from
> ps right now:
2010/1/12 Matteo Beccati :
> So, I've decided to spend a bit more time on this and here is a proof of
> concept web app that displays mailing list archives reading from the AOX
> database:
>
> http://archives.beccati.org/
Seems to work.
> Please take it as an exercise I've made trying to learn
On Mon, Jan 11, 2010 at 11:15 PM, Greg Smith wrote:
> Personally, I'd like the topic of a thread on "damage control" to be all
> about testing the one big patch that's already in there (HS), its related
> bits like the VACUUM FULL changes, and potentially SR too. Those are things
> that are touch
Fujii Masao wrote:
On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer
wrote:
Personally, I'd be uncomfortable enabling something like that without _both_
an admin alert _and_ the ability to refresh the slave's base backup without
admin intervention.
What feature do you specifically need as
Fujii Masao wrote:
On Sun, Jan 10, 2010 at 8:17 PM, Simon Riggs wrote:
What could happen is that the standby could slowly lag behind master. We
don't have any way of monitoring that, as yet. Setting ps display is not
enough here.
I agree that the statistical information about replicat
Bruce Momjian wrote:
I think the big issue with 8.4 was, do we close the commit-fest when we
have open issues, and we aren't clear on how to fix them? A lot of
unresolve issues get kept for that pre-beta period because all of a
sudden we have to resolve all those complex problems. I don't see t
On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer
wrote:
> Personally, I'd be uncomfortable enabling something like that without _both_
> an admin alert _and_ the ability to refresh the slave's base backup without
> admin intervention.
What feature do you specifically need as an alert? Just writing
t
On Sun, Jan 10, 2010 at 8:17 PM, Simon Riggs wrote:
> What could happen is that the standby could slowly lag behind master. We
> don't have any way of monitoring that, as yet. Setting ps display is not
> enough here.
I agree that the statistical information about replication activity is
very usef
There is a memory leak in dblink when we cancel a query during
returning tuples. It could leak a PGresult because memory used
by it is not palloc'ed one. I wrote a patch[1] before, but I've
badly used global variables to track the resource.
The attached is a cleaned up patch rewritten to use a tup
On Mon, Jan 11, 2010 at 7:54 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> plus, it looks like that most of the patents have either expired, or
>> are about to expire. lzo is used all over the place, including the
>> linux kernel...i think the burden of proof rests with anyone claiming
>> ther
On Sat, Jan 9, 2010 at 4:25 PM, Heikki Linnakangas
wrote:
> I don't think we need all that, a simple select() should be enough.
> Though I must admit I'm not very familiar with select/poll().
I'm not sure whether poll(2) should be called for this purpose. But
poll(2) and select(2) seem to often c
Robert Haas wrote:
> On Mon, Jan 11, 2010 at 9:45 PM, Bruce Momjian wrote:
> > We could if we could all stop long enough to address them. ?I think
> > there is the feeling that a great idea will pop up eventually, and only
> > when we are looking at beta do we realize we are out of time, and the
>
On Mon, Jan 11, 2010 at 9:45 PM, Bruce Momjian wrote:
> We could if we could all stop long enough to address them. I think
> there is the feeling that a great idea will pop up eventually, and only
> when we are looking at beta do we realize we are out of time, and the
> hard, sometime distasteful
FYI, I consider all the issues below to be addressed (we did all but
#4), and pg_migrator will take advantage of these new facilities for 8.5.
---
Bruce Momjian wrote:
> pg_migrator has become more popular recently, so it se
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > 2) Right now pg_migrator renames old tablespaces to .old, which fails
> > if the tablespaces are on mount points. I have already received a
> > report of such a failure. $PGDATA also has that issue, but that
> > renaming has to be done by the user
Robert Haas wrote:
> On Mon, Jan 11, 2010 at 9:30 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> The consensus view on this thread seems to be that we should have a
> >> time-based code freeze, but not a time-based release. ?No one has
> >> argued (and I sincerely hope no one will argue) tha
On Mon, Jan 11, 2010 at 9:30 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> The consensus view on this thread seems to be that we should have a
>> time-based code freeze, but not a time-based release. No one has
>> argued (and I sincerely hope no one will argue) that we should let the
>> last C
Robert Haas wrote:
> The consensus view on this thread seems to be that we should have a
> time-based code freeze, but not a time-based release. No one has
> argued (and I sincerely hope no one will argue) that we should let the
> last CommitFest drag on and on, as we did for 8.4. However, many
>
On Mon, Jan 11, 2010 at 8:14 PM, David Fetter wrote:
> On Mon, Jan 11, 2010 at 07:50:23PM -0500, Bruce Momjian wrote:
>> Josh Berkus wrote:
>> > I'll also say: if we can't make time-based releases work, we're
>> > probably dead as a project. MySQL and Ingres both tried
>> > feature-based releases
Robert Treat writes:
> pagila=# select * from information_schema.table_privileges;
> TRAP: FailedAssertion("!(idx[0] < (((int *) (((char *) (acl)) +
> sizeof(ArrayType)))[0]))", File: "acl.c", Line: 1740)
> server closed the connection unexpectedly
> This probably means the server termina
> They weren't "easily identified", or we'd have found them before 8.4.0
> release. I think the notion that 8.4.0 was much worse than previous .0
> releases is largely bogus, anyway; we've just forgotten all the bugs in
> older releases ...
It was worse than some, and better than others.
Bruce'
pagila=# select * from information_schema.table_privileges;
TRAP: FailedAssertion("!(idx[0] < (((int *) (((char *) (acl)) +
sizeof(ArrayType)))[0]))", File: "acl.c", Line: 1740)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or
Robert Haas wrote:
> On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I have looked this over a little bit and I guess I don't see why the
> >> lack of a grand plan for how to organize all of our permissions checks
> >> ought to keep us from removing this one on the g
Tom Lane wrote:
> Michael Meskes writes:
> > On Fri, Jan 08, 2010 at 03:41:10PM +0100, Stefan Kaltenbrunner wrote:
> >> Hmm not sure I find that commit message really helpful - but is it
> >> actually of any use to maintain a Changelog file specifically for
> >> ECPG?
>
> > Makes it easier to see
Simon Riggs wrote:
> > * I don't think we should require superuser rights for replication.
> > Although you see all WAL and potentially all data in the system through
> > that, a standby doesn't need any write access to the master, so it would
> > be good practice to create a dedicated account with
On Mon, Jan 11, 2010 at 07:50:23PM -0500, Bruce Momjian wrote:
> Josh Berkus wrote:
> > I'll also say: if we can't make time-based releases work, we're
> > probably dead as a project. MySQL and Ingres both tried
> > feature-based releases, and look where they are now.
>
> That is a simplification
Bruce Momjian writes:
> Robert Treat wrote:
>> There are three reasons I'd probably be comfortable with that; 1) the CF
>> process means we've likely had more eyes on the code going in than in past
>> releases.
> The reality check is that was had commit-fests for 8.4 development and
> 8.4.0 had
Robert Treat wrote:
> > Now the other approach we could take is that we'll ship *something*
> > on 7 Mar, even if it's less stable than what we've traditionally
> > considered to be beta quality. I don't think that really helps
> > much though; it just means we need more time in beta.
> >
>
> The
On Mon, 2010-01-11 at 19:54 -0500, Tom Lane wrote:
> Merlin Moncure writes:
> > plus, it looks like that most of the patents have either expired, or
> > are about to expire. lzo is used all over the place, including the
> > linux kernel...i think the burden of proof rests with anyone claiming
> >
Merlin Moncure writes:
> plus, it looks like that most of the patents have either expired, or
> are about to expire. lzo is used all over the place, including the
> linux kernel...i think the burden of proof rests with anyone claiming
> there are patent problems, not the other way around. lzo is
On Mon, 2010-01-11 at 19:50 -0500, Bruce Momjian wrote:
> Josh Berkus wrote:
> > I'll also say: if we can't make time-based releases work, we're probably
> > dead as a project. MySQL and Ingres both tried feature-based releases,
> > and look where they are now.
>
> That is a simplification. We h
Josh Berkus wrote:
> I'll also say: if we can't make time-based releases work, we're probably
> dead as a project. MySQL and Ingres both tried feature-based releases,
> and look where they are now.
That is a simplification. We have always done time-based releases with
adjustments for feature/sta
On Mon, Jan 11, 2010 at 5:25 PM, Kevin Grittner
wrote:
> Dimitri Fontaine wrote:
>
>>>
> http://archives.postgresql.org/pgsql-performance/2009-08/msg00053.php
>>
>> I knew I was forgetting about something, thanks for the reminder.
>> Damn it, patents.
>
> I'm not sure that there was anything ther
Peter Eisentraut wrote:
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type' an alternate syntax for SQL
conformance.
I don't really understand the purpose of that.
What is the p
Peter Eisentraut wrote:
On ons, 2010-01-06 at 23:46 +0100, Arie Bikker wrote:
Hope this is the right attachement type (I'm new at this)
BTW. here a some nice examples:
- Get the number of attributes of the first childnode:
select ( xpath('count(@*)',(xpath('*[1]','g="j"/>'))[1]))[1];
- an
On Mon, Jan 11, 2010 at 4:18 PM, Jonas J wrote:
> I get the dbt2 project from the git tree. And i'm trying to make it work
> with postgres. The problem is in one of the dbt2 shell scripts. Since I dont
> understand of Shell Script Programing, here is my problem: (I will post the
> script on the en
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
> ISTM that the ultimate would be a 'create table (_) without storage'
> (or some'm) and make 'create type' an alternate syntax for SQL
> conformance.
I don't really understand the purpose of that.
> For various reasons, we've inter
Dimitri Fontaine wrote:
>>
http://archives.postgresql.org/pgsql-performance/2009-08/msg00053.php
>
> I knew I was forgetting about something, thanks for the reminder.
> Damn it, patents.
I'm not sure that there was anything there which absolutely ruled
out using LZ0; all of the patents still
Il 11/01/2010 15:00, Abhijit Menon-Sen ha scritto:
I'll keep this short: Oryx, the company behind Archiveopteryx (aox), is
no longer around, but the software is still maintained. The developers
(myself included) are still interested in keeping it alive. It's been a
while since the last release, b
On Mon, Jan 11, 2010 at 05:42:08PM -, Greg Sabino Mullane wrote:
> > Is there a reason why you're suggesting using DBI? There is also the Pg
> > perl module which works as well and is one tenth of the size. It also
> > doesn't have external dependancies. It's just a plain wrapper around
> > lib
"Kevin Grittner" writes:
> Are the concerns from previous discussions off-base?
>
> http://archives.postgresql.org/pgsql-performance/2009-08/msg00053.php
I knew I was forgetting about something, thanks for the reminder. Damn
it, patents.
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-
Hi guys,
I get the dbt2 project from the git tree. And i'm trying to make it work
with postgres. The problem is in one of the dbt2 shell scripts. Since I dont
understand of Shell Script Programing, here is my problem: (I will post the
script on the end)
1 - I executed:
dbt2-pgsql-load-db -d /tm
Dimitri Fontaine wrote:
> The topic came on IRC and it might be that the later attempts at
> using another library missed one of the offering, namely FastLZ.
> It's made for being quick rather than minimize size, it's MIT
> licenced, 551 lines of portable ansi-C code, already tested on a
> host
Hi,
The topic came on IRC and it might be that the later attempts at using
another library missed one of the offering, namely FastLZ. It's made for
being quick rather than minimize size, it's MIT licenced, 551 lines of
portable ansi-C code, already tested on a host of systems and compilers.
htt
Thanks for all the feedback!
I'm going to try to summarize and address the issues raised.
(Meanwhile I've started spliting the patch into at least three parts,
per Andrew's suggestion: utility functions, the GUCs, the rest.)
* Long GUC values
I think the underlying assumption that they'll be l
Peter Eisentraut wrote:
On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
CREATE TYPE persons_type AS
* Magnus Hagander [100109 13:05]:
> On Sat, Jan 9, 2010 at 18:33, Aidan Van Dyk wrote:
> > * Magnus Hagander [100109 12:03]:
> >
> >> If that's the only remaining obstacle, I'm willing to work up some
> >> test scripts around that. But I'm not going to do that if it's going
> >> to fall over on
Peter,
> "Typed tables" is the official SQL standard name for the feature, and
> it's also used in DB2 documentation. So I kind of would prefer to keep
> it.
Sorry, I missed the SQL standard part in the thread. Ignore the noise.
Oh, and BTW, +1 on accepting this, pending patch quality and all
Alex Hunsaker writes:
> On Fri, Jan 8, 2010 at 07:27, Tom Lane wrote:
>> Then, somebody who wants the feature would build with, say,
>> Â Â Â Â -DLINUX_OOM_ADJ=0
>> or another value if they want that.
> Here is a stab at that.
Applied with some editorialization. I concluded that it'd be bet
2010/1/11 Teodor Sigaev :
> knngist uses that implementation of rb-tree. One more candidate is a ts_stat
> which now uses unbalanced binary tree.
Ah, OK. That's great if we can reuse that code in 2 or 3 places.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
2010/1/11 Teodor Sigaev :
>> I have reviewed this patch and it looks good to me. The only
>> substantive question I have is why gist_point_consistent() uses a
>> different coding pattern for the box case than it does for the polygon
>> and circle cases? It's not obvious to me on the face of it wh
...and I would say the same logic applies to this patch, maybe even
moreso. Tom has already applied a partial workaround for this
problem, and I'm feeling like it won't be trivial to figure out what
That partial workaround is not work for some corner cases:
http://www.sai.msu.su/~megera/wiki/20
I have reviewed this patch and it looks good to me. The only
substantive question I have is why gist_point_consistent() uses a
different coding pattern for the box case than it does for the polygon
and circle cases? It's not obvious to me on the face of it why these
aren't consistent.
gist_cir
Peter Eisentraut writes:
> On mån, 2010-01-11 at 10:44 -0500, Tom Lane wrote:
>> I think you could probably use the existing tag field; no need for a new
>> one.
> Sorry, which tag field are you referring to?
The one called "tag" in the source code. It prints out as "Name":
--
-- Name: binary
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Is there a reason why you're suggesting using DBI? There is also the Pg
> perl module which works as well and is one tenth of the size. It also
> doesn't have external dependancies. It's just a plain wrapper around
> libpq, which for the purpo
On mån, 2010-01-11 at 10:44 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > pg_dump sorts its output first by object type, then by object name, and
> > then processes all that for dependencies. This works well, but for
> > overloaded functions this still gives a random sort order that can
>
Peter Eisentraut writes:
> pg_dump sorts its output first by object type, then by object name, and
> then processes all that for dependencies. This works well, but for
> overloaded functions this still gives a random sort order that can
> produce annoying diffs in the dump.
> Would it be accepta
On Mon, Jan 11, 2010 at 10:14 AM, Pavel Stehule wrote:
> I could to start with
> https://commitfest.postgresql.org/action/patch_view?id=251
OK. Please edit that patch and list your name as the reviewer.
One thing I forgot to mention is - if you are volunteering to review,
please reply to me OF
Hello
I could to start with https://commitfest.postgresql.org/action/patch_view?id=251
Regards
Pavel
2010/1/11 Robert Haas :
> Well, folks, it's that time again! CommitFest 2010-01 will begin in
> just a few days (specifically, Fri Jan 15 00:00:00 UTC) and we are in
> need of reviewers. If you
Well, folks, it's that time again! CommitFest 2010-01 will begin in
just a few days (specifically, Fri Jan 15 00:00:00 UTC) and we are in
need of reviewers. If you're willing to help out, please drop me an
email and I'll assign you a patch; if you have a preference, please
let me know that, too.
pg_dump sorts its output first by object type, then by object name, and
then processes all that for dependencies. This works well, but for
overloaded functions this still gives a random sort order that can
produce annoying diffs in the dump.
Would it be acceptable to introduce a secondary sort ke
(Many thanks to Dimitri for bringing this thread to my attention.)
At 2010-01-11 10:46:10 +0100, mag...@hagander.net wrote:
>
> As for AOX, my understanding is that it is no longer maintained, so
> I'd be worried about choosing such a solution for a complex problem.
I'll keep this short: Oryx, th
Magnus Hagander wrote:
No, the current archiver is a set of MBOX files that are processed
incrementally by mhonarc.
(yes, this is why it doesn't scale)
*search* is in a postgresql database, but it doesn't contain the
entire messages - doesn't have attachments for examples - only the
parts it
On 11/01/2010 14:25, Tom Lane wrote:
Arnaud Betremieux writes:
3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY
channel '#'||OLD.id)
4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads
WHERE ...)
I'm working on a proof of concept patch
On Mon, Nov 9, 2009 at 5:15 AM, Peter Eisentraut wrote:
> On Sun, 2009-11-08 at 21:17 +, Simon Riggs wrote:
>> Not sure I see why this is good. Why is issuing CREATE TYPE so much
>> easier than using CREATE TABLE? Is it worth the extra syntax and code to
>> support it? Can we do anything addit
Dimitri Fontaine writes:
> Magnus Hagander writes:
>> As for AOX, my understanding is that it is no longer maintained, so
>> I'd be worried about choosing such a solution for a complex problem.
>> But it's open for discussion.
>
> Ouch.
It seems that the company baking the development is dead, b
On Mon, Jan 11, 2010 at 8:25 AM, Tom Lane wrote:
>
>> I'm working on a proof of concept patch to use Joachim's new notify
>> function to introduce case 3. I think this means going through the
>> planner and executor, so I might as well do case 4 as well.
>
> It would be a lot less work to introduc
2010/1/11 Dimitri Fontaine :
> Dave Page writes:
>>> I recall having tried AOX a long time ago but I can't remember the reason
>>> why I was not satisfied. I guess I can give another try by setting up a test
>>> ML archive.
>>
>> I tried it too, before I started writing the new prototype archiver
Arnaud Betremieux wrote:
A use case : use NOTIFY in a rule to send the primary key of a row that
has been updated (for instance to manage a cache).
This requires a patch on top of this one, and it really is a separate
concern, but I thought I'd give the use case anyway, since I believe it
is
Dave Page writes:
>> I recall having tried AOX a long time ago but I can't remember the reason
>> why I was not satisfied. I guess I can give another try by setting up a test
>> ML archive.
>
> I tried it too, before I started writing the new prototype archiver
> from scratch. I too forget why I g
Arnaud Betremieux writes:
> 3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY
> channel '#'||OLD.id)
> 4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads
> WHERE ...)
> I'm working on a proof of concept patch to use Joachim's new notify
> function to
Magnus Hagander writes:
> As for AOX, my understanding is that it is no longer maintained, so
> I'd be worried about choosing such a solution for a complex problem.
> But it's open for discussion.
Ouch.
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Il 11/01/2010 12:58, Dave Page ha scritto:
On Mon, Jan 11, 2010 at 5:23 PM, Matteo Beccati wrote:
I recall having tried AOX a long time ago but I can't remember the reason
why I was not satisfied. I guess I can give another try by setting up a test
ML archive.
I tried it too, before I started
On Mon, Jan 11, 2010 at 5:23 PM, Matteo Beccati wrote:
> Hi,
>
> Il 11/01/2010 11:18, Dimitri Fontaine ha scritto:
>>
>> AOX is already a database backed email solution, offering an archive
>> page with searching. I believe the searching is baked by tsearch
>> indexing. That's why I think it'd be
Hello
>
> No longer applies, please rebase.
>
fixed, sorry
Pavel
> Thanks,
>
> ...Robert
>
variable_escaping-fix.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
Hi,
Il 11/01/2010 11:18, Dimitri Fontaine ha scritto:
AOX is already a database backed email solution, offering an archive
page with searching. I believe the searching is baked by tsearch
indexing. That's why I think it'd be suitable.
They already archive and offer search over one of our mailin
Alvaro Herrera writes:
> Absolutely. The month boundary problem boils down to the fact that
> Mhonarc does not scale very well, so we can't have mboxes that are too
> large. This is why most people split their archives per month, and then
> each month is published as an independent Mhonarc outpu
A use case : use NOTIFY in a rule to send the primary key of a row that
has been updated (for instance to manage a cache).
This requires a patch on top of this one, and it really is a separate
concern, but I thought I'd give the use case anyway, since I believe it
is relevant to the issues her
2010/1/11 Alvaro Herrera :
> Dimitri Fontaine wrote:
>> Andrew Dunstan writes:
>> > That is assuming that the MUA gives you the option of specifying the
>> > attachment MIME type. Many (including mine) do not. It would mean an extra
>> > step - I'd have to gzip each patch or something like that. T
On Mon, Jan 11, 2010 at 04:17:42AM -, Greg Sabino Mullane wrote:
> > Because you'd have to build DBD::Pg against the new libpq, as you do
> > psql. That means you need DBD::Pg sources and the build environment for
> > Perl (headers etc) not just a working Perl runtime. Big difference.
>
On 9/01/2010 6:20 AM, Josh Berkus wrote:
On 1/8/10 1:16 PM, Heikki Linnakangas wrote:
* A standby that connects to master, initiates streaming, and then sits
idle without stalls recycling of old WAL files in the master. That will
eventually lead to a full disk in master. Do we need some kind of
90 matches
Mail list logo
