There's a couple of items on the TODO page
(https://wiki.postgresql.org/wiki/Hot_Standby_TODO) that haven't been
discussed on-list:
In normal operation, a few commands call ForceSyncCommit() to force non-async
commit. Should ForceSyncCommit force an XLogFlush() during recovery as well?
Regarding this item from the wiki page:
The standby delay is measured as current timestamp - timestamp of last
replayed commit record. If there's little activity in the master, that can
lead to surprising results. For example, imagine that max_standby_delay is
set to 8 hours. The standby is
On Fri, 2009-12-04 at 10:37 +0200, Heikki Linnakangas wrote:
Regarding this item from the wiki page:
The standby delay is measured as current timestamp - timestamp of last
replayed commit record. If there's little activity in the master, that can
lead to surprising results. For example,
Simon Riggs wrote:
On Fri, 2009-12-04 at 10:37 +0200, Heikki Linnakangas wrote:
Regarding this item from the wiki page:
The standby delay is measured as current timestamp - timestamp of last
replayed commit record. If there's little activity in the master, that can
lead to surprising
On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
Here is an update partitioning syntax patch.
A bug reported by Marko is fixed.
I will review and eventually commit this, if appropriate, though it is
3rd in my queue and will probably not be done for at least 2 weeks,
possibly 4
On Sat, 2009-11-21 at 20:20 +0200, Heikki Linnakangas wrote:
VACUUM FULL does a peculiar hack: once it's done moving tuples, and
before it truncates the relation, it calls RecordTransactionCommit to
mark the transaction as committed in clog and WAL, but the transaction
is still kept open in
On Tue, 2009-12-01 at 01:43 -0800, Jeff Davis wrote:
Marking as ready.
You're saying its ready, yet there are 3 additional suggestions patches
attached here. Please can you resolve these and re-submit a single final
patch from author and reviewer?
I will review and eventually commit this, if
Simon Riggs wrote:
I've just reviewed the VACUUM FULL patch to see if it does all we need
it to do, i.e. does the removal of HS code match the new VF patch.
Oh, good!
My answer is it doesn't, we will still have the problem noted above for
catalog tables. So we still have a must-fix issue for
On Fri, 2009-12-04 at 11:22 +0200, Heikki Linnakangas wrote:
Could you just mark the transaction as committed when you see the 1st
commit record, but leave the XID in the known-assigned list and not
release locks? That would emulate pretty closely what happens in the master.
OK, works for me.
On Dec 3, 2009, at 1:53 PM, Jonah H. Harris wrote:
On Tue, Dec 1, 2009 at 1:27 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On Tue, 2009-12-01 at 13:20 -0500, Robert Haas wrote:
Does $COMPETITOR offer this feature?
My understanding is that MSSQL does. I am not sure about Oracle. Those
On Fri, 2009-12-04 at 03:32 -0600, decibel wrote:
So... now that the upgrade discussion seems to have died down... was
any consensus reached on how to do said checksumming?
Possibly. Please can you go through the discussion and pull out a
balanced summary of how to proceed? I lost track a
Kevin,
md5sum of each tuple? As an optional system column (a la oid)?
I am mainly an application programmer working with PostgreSQL. And I
want to point out an additional usefullness of an md5sum of each
tuple: it makes comparing table-contents in replicated / related
databases MUCH more
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Andrew Dunstan and...@dunslane.net writes:
Before we go too far with this, I'd like to know how we will handle the
problems outlined here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00916.php
Tom Hm, I think that's only a
Thanks to suggestion.
I send pathces again by another mailer for the archive.
Sorry to waste resources, below is same content that I send before.
Tsutomu Yamada
SRA OSS, Inc. Japan
#
The following patches support Windows x64.
1) use intptr_t for Datum and pointer macros. (to support
On Fri, 2009-12-04 at 11:22 +0200, Heikki Linnakangas wrote:
My answer is it doesn't, we will still have the problem noted above for
catalog tables. So we still have a must-fix issue for HS, though that is
no barrier to the new VF patch.
I think the VACUUM FULL patch will have to address
On Thu, Dec 03, 2009 at 04:53:47PM -0800, David E. Wheeler wrote:
On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:
- New GUC plperl.on_perl_init='...perl...' for admin use.
- New GUC plperl.on_trusted_init='...perl...' for plperl user use.
- New GUC plperl.on_untrusted_init='...perl...' for
Simon Riggs wrote:
ISTM premature to remove all traces of VF from code. We may yet need it
for some reason, especially if doing so creates complex dependencies on
important features.
Well, it's still in the repository.
So modified proposal looks like this
1. (In normal running) Provide
On Fri, Dec 4, 2009 at 9:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
Possibly. Please can you go through the discussion and pull out a
balanced summary of how to proceed? I lost track a while back and I'm
sure many others did also.
I summarized the three feasible plans I think I saw;
On Fri, 2009-12-04 at 13:31 +0200, Heikki Linnakangas wrote:
b) seems much simpler to me.
OK. Least ugly wins, but she ain't pretty.
2. (In HS recovery) When we see first commit record for the VF xid we
commit the transaction in clog, yet maintain locks and KnownAssigned
xids
3. (In
decibel wrote:
On Dec 3, 2009, at 1:53 PM, Jonah H. Harris wrote:
On Tue, Dec 1, 2009 at 1:27 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On Tue, 2009-12-01 at 13:20 -0500, Robert Haas wrote:
Does $COMPETITOR offer this feature?
My understanding is that MSSQL does. I am
On Fri, 2009-12-04 at 07:12 -0500, Bruce Momjian wrote:
I think the hint bit has to be added to the item pointer, by using the
offset bits that are already zero, according to Greg Stark. That
solution leads to easy programming, no expanding hint bit array, and it
is backward compatible so
BTW with VACUUM FULL removed I assume we're going to get rid of
HEAP_MOVED_IN and HEAP_MOVED_OFF too, right?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing
Simon Riggs wrote:
On Fri, 2009-12-04 at 07:12 -0500, Bruce Momjian wrote:
I think the hint bit has to be added to the item pointer, by using the
offset bits that are already zero, according to Greg Stark. That
solution leads to easy programming, no expanding hint bit array, and it
is
On Fri, 2009-12-04 at 07:54 -0500, Bruce Momjian wrote:
I should also point out that removing 4 bits from the tuple header would
allow us to get rid of t_infomask2, reducing tuple length by a further 2
bytes.
Wow, that is a nice win. Does alignment allow us to actually use that
space?
On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
BTW with VACUUM FULL removed I assume we're going to get rid of
HEAP_MOVED_IN and HEAP_MOVED_OFF too, right?
Much as I would like to see those go, no. VF code should remain for some
time yet, IMHO. We could remove it, but doing so is not
Hi,
On Thu, Nov 26, 2009 at 5:20 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Nov 26, 2009 at 5:17 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah, that needs to be addressed regardless of HS, because you can
otherwise start up (= fail over to) the standby too
Simon Riggs wrote:
On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
BTW with VACUUM FULL removed I assume we're going to get rid of
HEAP_MOVED_IN and HEAP_MOVED_OFF too, right?
Much as I would like to see those go, no. VF code should remain for some
time yet, IMHO.
I don't think
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I don't have a problem with the third explanation ;-). The issue here
is really planner speed relative to execution speed, and that's not so
hardware-sensitive as all that. Yeah, you can plan a 12-join query
On Fri, Dec 4, 2009 at 12:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2009-12-04 at 07:54 -0500, Bruce Momjian wrote:
I should also point out that removing 4 bits from the tuple header would
allow us to get rid of t_infomask2, reducing tuple length by a further 2
bytes.
Wow,
On Fri, Dec 4, 2009 at 1:35 PM, Greg Stark gsst...@mit.edu wrote:
If we lose vacuum full then the table's open for reducing the width of
command id too if we need more bits. If we do that and we moved
everything we could to the line pointers including ctid we might just
be able to squeeze the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Migration is really only half the story, or not even that much. Every
time you move to a new Postgres version you have to do extensive work
Greg Stark escribió:
On Fri, Dec 4, 2009 at 1:35 PM, Greg Stark gsst...@mit.edu wrote:
If we lose vacuum full then the table's open for reducing the width of
command id too if we need more bits. If we do that and we moved
everything we could to the line pointers including ctid we might
Heikki Linnakangas escribió:
Simon Riggs wrote:
On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
BTW with VACUUM FULL removed I assume we're going to get rid of
HEAP_MOVED_IN and HEAP_MOVED_OFF too, right?
Much as I would like to see those go, no. VF code should remain for
On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Heikki Linnakangas escribió:
Simon Riggs wrote:
On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
BTW with VACUUM FULL removed I assume we're going to get rid of
HEAP_MOVED_IN and HEAP_MOVED_OFF too,
On Dec 4, 2009, at 6:18 AM, Tim Bunce wrote:
- generalize the Safe setup code to enable more control.
Is there any possible way to enable use strict; for plperl (trusted)
modules?
I would love to have that feature. Sure does help cut down on bugs and
makes things nicer.
--
Jeff
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Hm, I think that's only a problem if we define it to be a
Tom problem, and I'm not sure it's necessary to do so.
The complaint is that if plpgsql is installed by default, then it will
be owned
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
If the system is completely idle, and no WAL is written, we skip
xlog switches too, even if archive_timeout is set . It would be
pointless to create a stream of WAL files with no content except
for the XLOG_SWITCH records.
It's
Simon Riggs si...@2ndquadrant.com writes:
As I pointed out here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg00056.php
we only need to use 3 bits not 4, but it does limit tuple length to 4096
for all block sizes. (Two different options there for doing that).
Limiting the tuple
Greg Stark gsst...@mit.edu writes:
I'm not sure why I said including ctid. We would have to move
everything transactional to the line pointer, including xmin, xmax,
ctid, all the hint bits, the updated flags, hot flags, etc. The only
things left in the tuple header would be things that have to
Just FYI for all: we are planning to wrap 8.4.2 and other back branch
update releases next week, for release Monday the 14th.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, 2009-12-04 at 10:43 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
As I pointed out here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg00056.php
we only need to use 3 bits not 4, but it does limit tuple length to 4096
for all block sizes. (Two different
Robert Haas robertmh...@gmail.com writes:
Have we thought about what other things have changed between 8.4 and
8.5 that might cause problems for in-place upgrade?
So far, nothing. We even made Andrew Gierth jump through hoops to
keep hstore's on-disk representation upwards compatible.
On Fri, 2009-12-04 at 13:35 +, Greg Stark wrote:
I don't think getting rid of infomask2 wins us 2 bytes so fast. The
rest of those two bytes is natts which of course we still need.
err, yes, OK.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to use the regular syntax though.
regards,
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. I thought the consensus
was to refer to them as just exclusion constraints? I'm not
After a great deal of discussion in the community, the project's core
team have written a policy outlining the support lifecycle for major
PostgreSQL releases, which can be found on the wiki with other project
policies at http://wiki.postgresql.org/wiki/Policies.
We hope this document will help
Hi,
On Friday 04 December 2009 17:36:00 Dave Page wrote:
Version EOL Date
PostgreSQL 7.4July 2010 (extended)
PostgreSQL 8.0July 2010 (extended)
PostgreSQL 8.1November 2010
PostgreSQL 8.2December 2011
PostgreSQL 8.3February 2013
On Fri, 2009-12-04 at 11:35 -0500, Tom Lane wrote:
Unless there's loud squawks I'm going to exercise committer's
prerogative and make all the docs and messages just say exclusion
constraint.
Sounds fine to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote:
The perl code in plperl.on_perl_init gets eval'd as soon as an
interpreter is created. That could be at server startup if
shared_preload_libraries is used. plperl.on_perl_init can only be set by
an admin (PGC_SUSET).
Are multiline GUCs allowed in
On Dec 4, 2009, at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
I'm starting to go through this patch now. I thought the consensus
On Fri, 2009-12-04 at 09:20 +, Simon Riggs wrote:
On Tue, 2009-12-01 at 01:43 -0800, Jeff Davis wrote:
Marking as ready.
You're saying its ready, yet there are 3 additional suggestions patches
attached here. Please can you resolve these and re-submit a single final
patch from author
On Fri, 2009-12-04 at 09:56 -0800, Jeff Davis wrote:
We could put a VACUUM FULL; and a VACUUM (FULL INPLACE); somewhere,
which will cover a lot of the cases you're talking about. However, that
may be a performance consideration especially for people who develop on
laptops.
Let's check it
David E. Wheeler da...@kineticode.com writes:
On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote:
The perl code in plperl.on_perl_init gets eval'd as soon as an
interpreter is created. That could be at server startup if
shared_preload_libraries is used. plperl.on_perl_init can only be set by
an
With CVS HEAD, I'm getting the following error when I try to access a
system column from within trigger (which I'm doing just for debug
purposes):
create table foo (a int);
create or replace function foo_trig_fn() returns trigger as $$
begin
raise notice 'In trigger: added %', new.ctid;
On Dec 4, 2009, at 10:36 AM, Tom Lane wrote:
Are multiline GUCs allowed in the postgresql.conf file?
I don't think so. In any case this seems like an extreme abuse of the
concept of a GUC, as well as being a solution in search of a problem,
as well as being something that should absolutely
Tom Lane wrote:
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to use the regular syntax though.
David E. Wheeler da...@kineticode.com writes:
On Dec 4, 2009, at 10:36 AM, Tom Lane wrote:
I vote a big no on this.
That's fine. It's relatively simple for an admin to create a Perl module that
does everything she wants, call it PGInit or something, and then just make
the GUC:
On Dec 4, 2009, at 1:44 PM, Andrew Dunstan wrote:
As is documented, all you have to do is have:
custom_variable_classes = 'plperl'
plperl.use_strict = 'true'
in your config. You only need to put the documented BEGIN block in
your function body if you want to do use strict mode on a
On Fri, Dec 4, 2009 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Dec 4, 2009, at 10:36 AM, Tom Lane wrote:
I vote a big no on this.
That's fine. It's relatively simple for an admin to create a Perl module
that does everything she wants,
Robert Haas wrote:
On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Heikki Linnakangas escribi?:
Simon Riggs wrote:
On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
BTW with VACUUM FULL removed I assume we're going to get rid of
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
no matter what the API to cause it is. I might hold my nose for
On Dec 4, 2009, at 10:51 AM, Tom Lane wrote:
plperl.on_perl_init = 'use PGInit;'
No, you missed the point: I'm objecting to having any such thing as
plperl.on_perl_init, full stop.
Aside from the points I already made, it's not even well defined.
What is to happen if the admin changes
On Dec 4, 2009, at 11:05 AM, Tom Lane wrote:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
no matter what the API to cause it is. I might hold my
On Fri, Dec 4, 2009 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the
On Fri, Dec 04, 2009 at 11:01:42AM -0500, Tom Lane wrote:
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to
On Thu, Dec 03, 2009 at 03:47:21PM -0800, Josh Berkus wrote:
Tim,
Since there's a commitfest on right now, meaningful feedback on your
patch could be delayed. Just so you know.
Understood. Thanks Josh.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
David E. Wheeler escribió:
If it's a badly designed concept, do you have any ideas that are less bad?
I'm not sure that we want to duplicate this idea today, but in pltcl
there's a pltcl_modules table that is scanned on interpreter init and
loads user-defined code.
--
Alvaro Herrera
On Fri, Dec 4, 2009 at 2:04 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Heikki Linnakangas escribi?:
Simon Riggs wrote:
On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
BTW
Massa, Harald Armin wrote:
I am in the process of adding a user-space myhash column to all my
applications tables, filled by a trigger on insert / update. It really
speeds up table comparison across databases; and it is very helpfull
in debugging replications.
Have you seen pg_comparator?
On Fri, Dec 4, 2009 at 5:27 PM, Andres Freund and...@anarazel.de wrote:
Hi,
On Friday 04 December 2009 17:36:00 Dave Page wrote:
Version EOL Date
PostgreSQL 7.4 July 2010 (extended)
PostgreSQL 8.0 July 2010 (extended)
PostgreSQL 8.1 November 2010
On Fri, Dec 04, 2009 at 02:05:28PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
Robert Haas wrote:
Well, I am not sure how we would turn the _space_ used for CRC on and
off because you would have to rewrite the entire table/database to turn
it on, which seems unfortunate.
Well, presumably you're going to have to do some of that work anyway,
because even if the space
Le 4 déc. 2009 à 20:40, Tim Bunce a écrit :
Robert's comparison with mod_perl is very apt. Preloading code gives
dramatic performance gains in production situations where there's a
significant codebase and connections are frequent.
How far do you go with using a connection pooler such as
Functionally this patch looks excellent; correct format, applies
cleanly, passes regression, and I've been unable to find any issues
with the code itself. But I still have a concern over the interface
change, so I'm setting this back to waiting on author for now even
though it's really a matter
I attached updated patch and doc patch.
Zdenek
Peter Eisentraut píše v so 21. 11. 2009 v 13:19 +0200:
On lör, 2009-11-14 at 14:50 +0100, Zdenek Kotala wrote:
Peter Eisentraut píše v so 14. 11. 2009 v 10:41 +0200:
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
A curiosity question regarding torn pages: How does this work on file systems
that don't write in-place, but instead always do copy-on-write?
My example would be Sun's ZFS file system (In Solaris BSD). Because of its
snapshot rollback functionality, it never writes a page in-place, but
On Fri, 2009-12-04 at 18:36 +, Simon Riggs wrote:
Let's check it works before worrying about performance. We can take
tests out as well as add them once it becomes obvious its working.
Itagaki-san, perhaps you should add a variety of tests, and then Simon
can remove extra tests after he's
On Dec 4, 2009, at 11:40 AM, Tim Bunce wrote:
Robert's comparison with mod_perl is very apt. Preloading code gives
dramatic performance gains in production situations where there's a
significant codebase and connections are frequent.
The docs for plperl.on_perl_init could include a section
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
no matter what the API to cause it
On Wed, Dec 2, 2009 at 4:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ron Mayer rm...@cheapcomplexdevices.com writes:
Tom Lane wrote:
Hmm. So the argument for it is let's make a machine-readable format
more human-readable? I'm not getting the point. People should look
at the regular text
On top of that, if you did want YAML for easier readability, what
aspect of the output is more readable in YAML than it is in text
format? The only answer I can think of is that you like having each
data element on a separate line, so that the plan is much longer but
somewhat narrower. But
On Dec 4, 2009, at 18:07 , Jeff Davis wrote:
On Fri, 2009-12-04 at 18:36 +, Simon Riggs wrote:
Let's check it works before worrying about performance. We can take
tests out as well as add them once it becomes obvious its working.
Itagaki-san, perhaps you should add a variety of tests,
On Fri, 2009-12-04 at 14:47 -0800, Chuck McDevitt wrote:
A curiosity question regarding torn pages: How does this work on file
systems that don't write in-place, but instead always do
copy-on-write?
My example would be Sun's ZFS file system (In Solaris BSD). Because
of its snapshot
I am in the process of adding a user-space myhash column to all my
applications tables, filled by a trigger on insert / update. It really
speeds up table comparison across databases; and it is very helpfull
in debugging replications.
Have you seen pg_comparator?
yes, saw the lightning talk
On Fri, Dec 4, 2009 at 7:42 PM, Josh Berkus j...@agliodbs.com wrote:
On top of that, if you did want YAML for easier readability, what
aspect of the output is more readable in YAML than it is in text
format? The only answer I can think of is that you like having each
data element on a
Since the pg_stat_bgwriter structure was introduced in 8.3, there's
never been any way to reset its statistics back to 0. A week of
analyzing data from that every day drove me crazy enough to finally fix
this with the attached patch. This implements the TODO item Allow the
clearing of
On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus j...@agliodbs.com wrote:
In words of one syllable: I do not care at all whether the NSA would use
Postgres, if they're not willing to come and help us build it.
There's several 2-syllable words there. ;-)
If we
tried to build it without their
Robert Haas wrote:
Actually, we tried that already, in a previous iteration of this
discussion. Someone actually materialized and commented on a few
things. The problem, as I remember it, was that they didn't know much
about PostgreSQL, so we didn't get very far with it. Unfortunately, I
Andrew Gierth and...@tao11.riddles.org.uk writes:
If we're going to change the interface in this way, there should, IMO,
be enough of a change that old code fails to compile; e.g. by renaming
wincontext to partition_context or some equivalent change.
Agreed --- if we have to break things,
David E. Wheeler da...@kineticode.com writes:
Tom, what's your objection to Shlib load time being user-visible?
It's not really designed to be user-visible. Let me give you just
two examples:
* We call a plperl function for the first time in a session, causing
plperl.so to be loaded. Later
90 matches
Mail list logo
