On 05/01/11 04:43, Devrim GÜNDÜZ wrote:
On Fri, 2010-12-31 at 11:11 +1300, Mark Kirkwood wrote:
I note that this uninitialized pages with standbys has cropped up from
time to time - I wonder if in most/all the cases folk were using
Pitrtools?
I deployed Pitrtools a lot when I was working for
product
being excluded from contrib by the choice of license - would they be
receptive to the idea that it would be free marketing to have it in the
main tarball/rpm/deb (etc) with merely a decision to change it GPL->BSD?
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 19/01/11 05:51, Robert Haas wrote:
I'm not sure why they'd care, but it certainly doesn't seem worth
spending the amount of time arguing about it that we are. David and
Mark are, of course, free to spend their time petitioning Red Hat for
relicensing if they are so inclined,
On 21/01/11 15:24, Robert Haas wrote:
On Thu, Jan 20, 2011 at 9:17 PM, Kevin Grittner
wrote:
Right -- God only knows the number of things were filtered out to
leave me with filtered water. What's "filtered" in this case is what
was passed through, not what was removed.
Hmm, I guess I see you
wly supplied perhaps)
recovery.conf and start to apply changes from there (with suitable
safeguards). We have failover pretty painless now... but reconstruction
of the original primary as a new standby is still too
fiddly/resource/time consuming etc.
Regards
Mark
--
Sent via pgsql-hackers ma
n and replacing the couple of XXX
comments. I'll add it to the next commitfest.
Regards,
Mark
add_spigettypmod-20130209.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
hing the other day - it would be very nice
to have the information visible. I may take a look at doing it (I've
done some hacking on the stats system previously). However don't let
that put anyone else off - as I'll have to find the time to start :-)
Regards
Mark
--
Sent via
options?
Cheers
Mark
On 27/02/13 11:16, Greg Smith wrote:
Here's a happy initdb on 9.1 providing help:
$ psql --version
psql (PostgreSQL) 9.1.8
$ /usr/pgsql-9.1/bin/initdb --help
initdb initializes a PostgreSQL database cluster.
Usage:
initdb [OPTION]... [DATADIR] ...
Here's what I
On 27/02/13 12:41, Greg Smith wrote:
On 2/26/13 5:51 PM, Mark Kirkwood wrote:
So looks like something odd you are doing - are you using any unusual
build options?
The unusual part looks to be the build environment or libraries of this
Mac I'm trying to use. The build options are the n
about where in the code
base it properly belongs (which obviously depends on whether it should
cover manual vacuum as well)? And does the string need to distinguish
between an autovac and an autoanalyze?
Cheers,
Jeff
Knowing whether it is vacuuming or analyzing seems like a nice idea +1
Cheers
I used the following patch to add lock support aarch64. It is just a
copy of the arm support based on gcc builtins. Postgresql built with
this patch passes the various tests.
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index d4a783f..624a73b 100644
--- a/src/include/st
On Mon, 2013-05-13 at 16:15 +0300, Heikki Linnakangas wrote:
> On 13.05.2013 15:39, Mark Salter wrote:
> > I used the following patch to add lock support aarch64. It is just a
> > copy of the arm support based on gcc builtins. Postgresql built with
> > this patch passes the
On 24/02/13 10:51, Mark Kirkwood wrote:
On 24/02/13 10:12, Stefan Andreatta wrote:
On 02/23/2013 09:30 PM, Jeff Janes wrote:
Moved discussion from General To Hackers.
On Sat, Feb 23, 2013 at 10:41 AM, Stefan Andreatta
mailto:s.andrea...@synedra.com>> wrote:
On 02/23/2013 05:10 PM
longer match). It looks to me like the downstream guys all need
to be rebuilt - or am I missing something?
Regards
mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14/08/12 12:32, Josh Berkus wrote:
Mark,
Looking at the docs (section 25.2.6 paragraph 6) leads one to believe
that downstream standbys can continue to receive and process wal merely
by reconnecting after the cascading standby is promoted - but this does
not seem to be the case (indeed the
dead tuples in the estimates)...
Regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
oing parameter checking and passing in code
using either '' quoting or \' quoting can be exploited if the server
happens to be configured the opposite way. To me, this ambiguity can
only be addressed by everybody agreeing on the right way to do it, and
'' quoting seem
have no comment. I just don't want to see "never" be
the time, and if "never" is not the time, than "now" does not seem
impratical. That said, if you say we'll tell people to prepare for a
change in 9.0, and enforce the change in a later release, that is
ill
> alive :-(
We still have a T2000 system with solaris on it. It was not in the
buildfarm because it was felt this configuration was already covered.
Let me know if we want to set it up for the buildfarm.
Regards,
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
ld be awesome, but in terms of what
would help me *today* - being able to convert prepared plans into just a
means to use place holders would help me today on certain real
applications in production use right now.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgs
tioned:
1) What will you do for hostnames that have multiple IP addresses? Will
you accept all IP addresses as being valid?
2) What will you do if they specify a hostname and a netmask? This seems
like a convenient way of saying "everybody on the same subnet as NAME."
Cheers,
mark
--
Mark Mielke
On 02/11/2010 04:54 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 16:36, Mark Mielke <mailto:m...@mark.mielke.cc>> wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask combination. I
would suggest allowing lists of hostnames in the entries
On 02/11/2010 05:12 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 23:01, Mark Mielke <mailto:m...@mark.mielke.cc>> wrote:
On 02/11/2010 04:54 PM, Bart Samwel wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask combination.
On 02/11/2010 09:38 PM, Euler Taveira de Oliveira wrote:
Mark Mielke escreveu:
Of course, then I'll ask for the ability to simplify specifying multiple
databases:
We already support multiple users and/or databases for a single pg_hba.conf
line ...
Is there a reason you tr
correctly, but in practice, I don't see this sort of problem happening.
If you are concerned, enable dirsync.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/14/2010 03:49 PM, Andres Freund wrote:
On Sunday 14 February 2010 21:41:02 Mark Mielke wrote:
The widely reported problems, though, did not tend to be a problem with
directory changes written too late - but directory changes being written
too early. That is, the directory change is
a
query. IOW, we're going to need, well, a connection pool in core.
*ducks, runs for cover*
One thing that might work quite well is slicing up by partition
(properly implemented partitioning would go along with this nicely too...)
regards
Mark
--
Sent via pgsql-hackers mailing lis
on.
After writing this, I'm pretty sure that implementation of the above
into PostgreSQL would be difficult, and it could be a valid concern that
the investment is not worth the benefit at this time. It's a tough problem.
My $0.01 CDN. :-)
Cheers,
mark
--
Sent via pgsql-hackers mai
On 02/26/2010 05:20 AM, Jeroen Vermeulen wrote:
Mark Mielke wrote:
All the points about ms seem invalid to me. There are many reason why
ms could increase, and many of them have nothing to do with plan
efficiency. Again, re-planning due to a high ms, or a high ratio of
ms, does not indicate
around the problem
that the idea of a generic plan is just wrong. The only time a generic
plan is right, is when the specific plan would result in the same.
Cheers,
mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d I
can't make you do it. If you say "too hard", there isn't anything I can
do about it. :-)
Cheers,
mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/26/2010 01:59 PM, Tom Lane wrote:
Mark Mielke writes:
Just to point out that I agree, and as per my original post, I think the
only time prepared statements should be re-planned for the statistics
case, is after 'analyze' has run. That sounds like a quicker solution,
On 02/26/2010 02:57 PM, Tom Lane wrote:
Mark Mielke writes:
There must be some way to lift the cost of planning out of the plan
enumeration and selection phase, such that only plan enumeration and
selection is run at execute time. In most cases, plan enumeration and
selection, provided
ns - is that it implies the
other aspect I have been suggesting: In order to have a custom cached
plan, the primary model must be to use custom plans. If PREPARE/EXECUTE
uses generic plans normally, than the only cached plans available will
be generic plans.
Cheers,
mark
--
Sent via pgsql-hacke
n, will meet the cases that
really annoyed me, and would make a lot of us very happy... Thanks.
Cheers,
mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that I needed to enter
it into the various commitfests... then I was faced with comments to the
effect that it was not ready for commit so should not have been entered
into a commifest at all... sigh, a bit of an enthusiasm killer I'm afraid...
regards
Mark
--
Sent via pgsql-hackers ma
Greg Smith wrote:
Mark Kirkwood wrote:
Greg Smith wrote:
Returned with feedback in October after receiving a lot of review,
no updated version submitted since then:
https://commitfest.postgresql.org/action/patch_view?id=98
Hmm - I would say a bit of review rather than a lot :-)
It looks
se you will
be asked for one before any further review can proceed..."
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a
newish process for me to get my head around, so no apology needed at all
as it is/was clear that there was no intent on your part to make things
hard! (that is why I said nothing at the time). But thank you for your
kind words, much appreciated.
Best wishes
Mark
best wishes
--
Sent via p
ally faster in a specific case, which is the exact opposite of what
people expect.
Cheers,
mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
+ Postgresql passes most of the
regression tests.
Maybe you could consider helping out making Drupal 7 + Postgresql pass
the remaining ones?
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
d by HP in
the lab hosted by Command Prompt with the intent of getting something
automated for testing 9.0. The (unsorted and unorganized) results are
available here:
http://207.173.203.223/~markwkm/community6/dbt5/tuning/
I hope this will be helpful.
Regards,
Mark
--
Sent via pgsql-hackers ma
like perl :-)
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
y the standby (I had to leave the master
idle whilst running the standby case, as they shared the machine). Hope
this info is useful.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"show debug_assertions"
Or even:
pg_config --configure
on both systems might be worth checking.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
test.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
and most of the limitations of pg_migrator are gone when migrating to
9.0, even from Postgres 8.3. This could help beta testers move their
data to 9.0 as well.
Wouldn't this help even for beta1?
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-ha
l us whether you are using 32 or 64 bit Ubuntu!
Cheers
Mark
'0001' from 5 for -2);
ERROR:invalid memory alloc request size 4244635647
Please log into postgres do:
SELECT version();
(and Robert suggested) and show us the output - as we need to know the
3rd number e.g 8.3.x in the postgres version to help you any more.
regards
Mark
On 05/05/10 13:15, Mark Kirkwood wrote:
Please log into postgres do:
SELECT version();
(and Robert suggested)
Should read *as* Robert suggested - sorry.
Also you could do this from the os:
$ aptitude show postgresql-8.3*
*which will display more detail for the version.
Cheers
Mark
*
*
On 05/05/10 22:13, Srinivas Naik wrote:
Hi Mark,
I took the output of the Postgresql. Please find the output:
Package: postgresql-8.3
State: installed
Automatically installed: no
Version: 8.3.9-0ubuntu8.10
Ok - your bug is fixed in 8.3.10. This should make its way to your
Ubuntu apt
On 06/05/10 09:48, Mark Kirkwood wrote:
Ok - your bug is fixed in 8.3.10. This should make its way to your
Ubuntu apt repository soon (provided 8.10 is still getting updates
that is...).
Unfortunately it looks like you may not get this version - see:
http://ubuntuguide.org/wiki
help.
regards
Mark
P.s: Judging from the date of this thread the above advice may be too
late, sorry. Next time always backup!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This is a patch against src/backend/storage/file/fd.c
taken from 9.2beta1.
This patch is submitted for review and comments, not
for application to the code base. *WIP*
This patch addresses a performance problem stemming
from the use of FindFirstFile() and FindNextFile() to
iterate over a direct
fix overly specific? Clearly we
could also take a Suffix argument, but if we go too far down
this road we just reinvent regular expressions....
mark
From: Tom Lane
To: Mark Dilger
Cc: "pgsql-hackers@postgresql.org"
Sent: Tuesday, May 29, 2012
ch v2.
From: Tom Lane
To: Mark Dilger
Cc: "pgsql-hackers@postgresql.org"
Sent: Tuesday, May 29, 2012 3:42 PM
Subject: Re: [HACKERS] Performance patch for Win32
Mark Dilger writes:
> I am hesitant to write a function like AllocateDirWithFilePattern
> if the pattern is
otherwise fine
functionality. Also it would be really nice to have a single function
that gave the current receive or active wal offset so things like Nagios
didn't have to know the if db is a standby or not to work out said offset...
Regards
Mark
using a float type which meant you couldn't get nice units
displayed (MB, GB etc).
I'll take a proper look later.
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 20/07/12 09:58, Mark Kirkwood wrote:
On 20/07/12 09:08, Joshua D. Drake wrote:
On 07/19/2012 01:48 PM, Christopher Browne wrote:
On Thu, Jul 19, 2012 at 4:29 PM, Joshua D. Drake
wrote:
On 07/19/2012 01:04 PM, Pavel Stehule wrote:
I did a backport of temp_file_limit feature to 9.1
On 20/07/12 12:02, Tom Lane wrote:
Pavel Stehule writes:
I did a backport of temp_file_limit feature to 9.1, but when we tested
this patch, we found very restristrictive limit to 2GB.
2GB is nonsense, because this is session limit of temp files, and
these files should be longer than 2GB.
This
On 16/09/10 13:22, Tom Lane wrote:
Hitoshi Harada writes:
2010/9/16 Robert Haas:
Oh, key-value store, I bet. Yeah, that would be cool.
That's it. Like Redis, Tokyo Cabinet, or something.
What exactly do those get you that an ordinary index, or at worst an
index-o
database crashes and comes back up again, everyone has to log in
again, but that's a rare event and not a disaster if it happens.
Or perhaps even a "sessions" type table where the rows are overwritten
in place in some manner, to avoid bloat.
regards
Mark
--
Sent via pgsql-
ble on demand implementation is the
way to go.
Cheers
Mark
On 17/08/10 17:19, Peter Eisentraut wrote:
Here is a small prototype for a query progress indicator.
Past discussions seemed to indicate that the best place to report this
would be in pg_stat_activity. So that's what this d
d tests. I am just telling you what people told
> me.
I've been slowly trying to rebuild something that was in use at the
OSDL to test patches. I just proofed something that I think works
with the git repository:
http://207.173.203.223:5000/patch/show/48
If you click on the PASS
On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan wrote:
>
>
> On 09/20/2010 12:24 PM, Mark Wong wrote:
>>
>> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian wrote:
>>>
>>> Well, I can run tests for folks before they apply a patch and "red" the
t;un-move" script to move them back just in case).
Regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21/09/10 16:14, Mark Kirkwood wrote:
I've been having a look at this guy, trying to get a handle on how
much down time it will save.
As a quick check, I tried upgrading a cluster with a 1 non default db
containing a scale 100 pgbench schema:
- pg_upgrade : 57 s
- p
you run into any other evidence suggesting a problem with 2.6.32?
Not Greg (sorry), but this might be worth a look:
http://www.spinics.net/lists/linux-ext4/msg20299.html
regards
Mark
On 28/09/10 16:59, Robert Haas wrote:
On Mon, Sep 27, 2010 at 11:37 PM, Mark Kirkwood
wrote:
Greg, have you run into any other evidence suggesting a problem with 2.6.32?
Not Greg (sorry), but this might be worth a look:
http://www.spinics.net/lists/linux-ext4/msg20299.html
Oh
are hugetlbpage aware, so it seems it should 'just
work'. However, I have not checked...
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 20/10/10 16:05, Mark Kirkwood wrote:
shmget and friends are hugetlbpage aware, so it seems it should 'just
work'.
Heh - provided you specify
SHM_HUGETLB
in the relevant call that is :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
will correct me if I'm wrong, but when I looked at
this a couple years ago I believe a side effect of using hugetlbs is
that these segments are never swapped out.
I made a weak attempt to patch postgres to use hugetlbs when
allocating shared memory. If I can find that patch I'll send it out..
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 19, 2010 at 8:30 PM, daveg wrote:
> On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
>> On 20/10/10 16:05, Mark Kirkwood wrote:
>> >
>> >
>> >shmget and friends are hugetlbpage aware, so it seems it should 'just
>>
On 19/10/10 13:16, Josh Berkus wrote:
Robert asked me to write this up, so here it is.
It is critical that we make replication easier to set up, administrate
and monitor than it currently is. In my conversations with people,
this is more important to our users and the adoption of PostgreSQL
shared-nothing architecture as opposed to a shared-disk one. I guess the
advantage of the former is that specialized (i.e expensive) hardware is
not required to attempt to overcome the point of failure with
shared-disk systems - the disk they share.
Cheers
Mark
xample had 6 all the same. Setting them all different (even after
adjusting the data so the there *was* a number of matching rows to find)
resulted in significantly less memory consumed (I can dig up some
examples if it might be interesting).
Cheers
Mark
didn't think to use EXPLAIN +
buffers... not sure why they would disagree. Have a go with
log_temp_files set and see what you find!
I like yhour suggesting for the name. Given that 'work_mem' is per
backend, I'm leaning towards the idea of 'work_disk' being sufficient
On 01/06/11 12:27, Mark Kirkwood wrote:
Re the code comments - I agree with most of them. However with respect
to the Guc units, I copied the setup for work_mem as that seemed the
most related.
Also - forget to mention - I *thought* you could specify the temp files
size GUC as KB, MB, GB
On 01/06/11 12:32, Mark Kirkwood wrote:
On 01/06/11 12:27, Mark Kirkwood wrote:
Re the code comments - I agree with most of them. However with
respect to the Guc units, I copied the setup for work_mem as that
seemed the most related.
Also - forget to mention - I *thought* you could specify
ropose to rename the current GUC to something like backend_work_disk.
Done - 'work_disk' it is to match 'work_mem'.
Patch is not large and easy to read.
I like the idea and it sounds useful.
Great! Cheers
Mark
temp-files-v3.patch.gz
Description: GNU Zip compressed data
On 02/06/11 11:35, Mark Kirkwood wrote:
On 01/06/11 09:24, Cédric Villemain wrote: Simple Feature test
==
either explain buffers is wrong or the patch is wrong:
cedric=# explain (analyze,buffers) select * from foo order by 1 desc
On 02/06/11 18:34, Jaime Casanova wrote:
On Wed, Jun 1, 2011 at 6:35 PM, Mark Kirkwood
wrote:
I've created a new patch (attached)
Hi Mark,
A few comments:
- why only superusers can set this? if this is a per-backend setting,
i don't see the problem in allowing normal users t
guc.h) but looks like we don't have
a GUC_UNIT_MB, not sure if adding it would be an issue (suggests on a
suitable mask if people think it is a great idea).
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/06/11 18:34, Jaime Casanova wrote:
- the patch adds this to serial_schedule but no test has been added...
diff --git a/src/test/regress/serial_schedule b/src/test/regress/serial_schedule
index bb654f9..325cb3d 100644
--- a/src/test/regress/serial_schedule
+++ b/src/test/regress/serial_sc
On 03/06/11 12:33, Cédric Villemain wrote:
2011/6/2 Mark Kirkwood:
On 01/06/11 09:24, Cédric Villemain wrote:
* I am not sure it is better to add a fileSize like you did or use
relationgetnumberofblock() when file is about to be truncated or
unlinked, this way the seekPos should be enough to
On 09/06/11 06:58, Alex Hunsaker wrote:
Yeah :-). However ill note it looks like its the default compiler for
fedora 15, ubuntu natty and debian sid.
FWIW Ubuntu natty uses gcc 4.5.2, probably just as as well in the light
of your findings :-)
Cheers
Mark
--
Sent via pgsql-hackers mailing
On 15/06/11 02:52, Cédric Villemain wrote:
2011/6/3 Mark Kirkwood:
Corrected v4 patch with the test files, for completeness. Note that
discussion has moved on and there will be a v5 :-)
Mark, can you submit your updated patch ?
Thanks for the reminder! Here is v5. The changes are:
- guc
/test/regress/sql/resource.sql
Any idea?
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 17/06/11 13:08, Mark Kirkwood wrote:
On 17/06/11 09:49, Cédric Villemain wrote:
I have issues applying it.
Please can you remove trailing space?
Also, you can generate a cool patch like this :
get git-external-diff from postgres/src/tools to /usr/lib/git-core/
chmod +x it
export
write in chunks bigger than blocksz.
Maybe a few days - I'm home sick ATM, plus looking after these
http://www.maftet.co.nz/kittens.html
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
On 22/06/11 11:13, Mark Kirkwood wrote:
On 21/06/11 02:39, Cédric Villemain wrote:
2011/6/20 Robert Haas:
On Mon, Jun 20, 2011 at 9:15 AM, Cédric Villemain
wrote:
The feature does not work exactly as expected because the write limit
is rounded per 8kB because we write before checking. I
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
e...).
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
confirm that libedit multi-byte input is busted in
the version shipped with Ubuntu 10.10.
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16/02/11 14:54, Tom Lane wrote:
It's pretty hard to see how those two things would be related. I think
more likely libedit is providing a function named setproctitle, which
seems like a rather stupid thing for them to have done.
You are correct - it defines setproctitle, good grief.
--
Se
On 16/02/11 15:05, Mark Kirkwood wrote:
On 16/02/11 14:54, Tom Lane wrote:
It's pretty hard to see how those two things would be related. I think
more likely libedit is providing a function named setproctitle, which
seems like a rather stupid thing for them to have done.
You are co
On 16/02/11 15:59, Greg Stark wrote:
On Wed, Feb 16, 2011 at 2:43 AM, Mark Kirkwood
wrote:
What's this libbsd then eh? Sure enough it is this guy that defines these
symbols. So it is the way it is being built on the Ubuntu (or Debian)
platform.
Oh, for what it's worth there a
ks for int
regards
Mark
temp-files-v1.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with KB units means the
largest temp size is approx 2047GB - I know that seems like a lot now...
but maybe someone out there wants (say) their temp files limited to
4096GB :-)
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
ystem (i.e such a
system should not *have* queries that want to use that much resource).
To answer the other question, what happens when the limit is exceeded is
modeled on statement timeout, i.e query is canceled and a message says
why (exceeded temp files size).
Cheers
Mark
--
Sent via p
501 - 600 of 1810 matches
Mail list logo
