On 04.03.2013 09:11, Simon Riggs wrote:
Are there objectors?
FWIW, I still think that checksumming belongs in the filesystem, not
PostgreSQL. If you go ahead with this anyway, at the very least I'd like
to see some sort of a comparison with e.g btrfs. How do performance,
error-detection
2013/3/3 Tom Lane t...@sss.pgh.pa.us:
Craig Ringer cr...@2ndquadrant.com writes:
On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
The attached patch adds Daniel's reworks on make_modifytable
invocation, and add a short comment on add_base_rels_to_query(). Rest
of portion has not been changed from
This is an interim report for this patch.
We found that PostgreSQL with this patch unexpctedly becomes
primary when starting up as standby. We'll do further
investigation for the behavior.
Anyway, I've committed this to master and 9.2 now.
This seems to fix the issue. We'll examine this
Hello, Jeff.
You wrote:
JJ Changed subject from Strange Windows problem, lock_timeout test request
JJ On Thu, Jan 24, 2013 at 11:41 AM, Andrew Dunstan and...@dunslane.net
wrote:
JJ On 01/24/2013 01:44 PM, Jeff Janes wrote:
JJ On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan
2013-03-04 08:02 keltezéssel, Simon Riggs írta:
On 4 March 2013 06:39, Boszormenyi Zoltan z...@cybertec.at wrote:
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added this:
src/backend/rewrite/rewriteDefine.c.orig| 945 +...
...
2013-03-04 08:10 keltezéssel, Devrim Gündüz írta:
Hi,
Kevin already removed it with a followup commit:
http://git.postgresql.org/pg/commitdiff/d63977eea3ab18fdec05e370b633d10b9fd20179
404 - Unknown commit object
Regards, Devrim
Boszormenyi Zoltan z...@cybertec.at wrote:
Hi,
Craig Ringer cr...@2ndquadrant.com writes:
There hasn't been visible movement on this work since the 22'nd when you
posted v3 and it was flagged for further review. Nobody's stepped up,
can we get any interest in this?
I hope we can, it's a pretty important development as far as I'm
concerned,
On 2013-03-04 11:51:36 +0100, Dimitri Fontaine wrote:
- Assert() HeapTuple's catalog
In the function extract_ctlversion() I would like to be able to
Assert() that the given tuple is from the right catalog and didn't
see how to do that
-t_tableOid. Haven't read the patch, so I
On Mar 4, 2013 10:55 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
2013-03-04 08:02 keltezéssel, Simon Riggs írta:
On 4 March 2013 06:39, Boszormenyi Zoltan z...@cybertec.at wrote:
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
(Add a materialized view relations.) added this:
2013-03-04 13:01 keltezéssel, Magnus Hagander írta:
The repository is currently broken. There's a thread on www about it, and also see the
email to hackers a few hours ago telling committers to stop pushing until it's fixed.
Thanks for the info, I didn't know about it. I am not
subscribed
Hello,
While doing some tests, I observed that the ps command continues to
display status of the startup process as recovering filename even
though it has finished the redo and is now performing end-of-recovery
checkpoint. This checkpoint can take a while, a few seconds to a few
minutes depending
On 2013-03-04 18:21:50 +0530, Pavan Deolasee wrote:
Hello,
While doing some tests, I observed that the ps command continues to
display status of the startup process as recovering filename even
though it has finished the redo and is now performing end-of-recovery
checkpoint. This checkpoint
On 03-03-2013 21:27, Josh Berkus wrote:
I think it would be worth talking about when someone wants to implement
it. I'd imagine it would require setting a GUC, though, which would be
off by default for obvious reasosn.
-1. Why not adding another storage_parameter, say auto_refresh=on? Also,
AFAICT, there's a bug in tm2timestamp(). You can't do this:
postgres=# select '1999-12-31T24:00:00'::timestamptz;
ERROR: timestamp out of range: 1999-12-31T24:00:00
But that's a perfectly legal date. It works fine for any other year -
and AFAICT this is because of the POSTGRES_EPOCH_JDATE being
On Mon, Mar 4, 2013 at 6:23 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-03-04 18:21:50 +0530, Pavan Deolasee wrote:
If we do that,
what would be the best place to add that code ? I was thinking adding
that to CreateCheckpoint() itself so that the status is displayed at
all
On Sun, Mar 3, 2013 at 9:54 PM, Cliff_Bytes cr...@eclipssolutions.com wrote:
Hello All
First, I am new to this great forum.
I have a challenge on my hand as follows. I am a long time libpq user but
have never used the BYTEA data type nor its related functions until now. I
have am writing
On Monday, March 04, 2013 6:38 AM Greg Smith wrote:
This submission didn't have any listed reviewers in the CF app. I
added
Zoltan and Andres since both of you went through the usual review steps
and have given lots of feedback.
Thank you for review.
There are two main sets of issues that
On Tue, Feb 26, 2013 at 2:56 PM, David E. Wheeler da...@justatheory.comwrote:
Hello ActiveStaters,
The commonly used term is actually Activator. :)
I see that the DBD::Pg build always fails:
http://code.activestate.com/ppm/DBD-Pg/
I'm sure this is because PostgreSQL is not installed
On 03/04/2013 09:07 AM, Greg Smith wrote:
I'm not sure why you are opening the old auto config file with
ParseConfigFp. Can't you just navigate the existing GUCs in memory
and directly write the new one out? If someone is going to manually
edit this file and use SET PERSISTENT, they're going
For the patch: Patch to compute Max LSN of Data Pages
Reviewer has already given his opinion in mail at below link, that this is good
from his side and he has no more further concerns. He has one minor suggestion
which I also fixed in later provided patch.
I'm working on PostgreSQL 9.13 (waiting for admin to push upgrades next week),
in the meanwhile, I was curious if there are any known bugs regarding large
cursor fetches, or if I am to blame.
My cursor has 400 million records, and I'm fetching in blocks of 2^17 (approx.
130K). When I fetch the
Merlin
I will try your suggestion, thanks. I am somewhat surprised to find few
hacks related to my issue. And the BYTEA type and function documentation
leave much to be desired, IMHO, being a newbie on the Type BYTEA front.
--
View this message in context:
On Mon, 2013-03-04 at 10:36 +0200, Heikki Linnakangas wrote:
On 04.03.2013 09:11, Simon Riggs wrote:
Are there objectors?
FWIW, I still think that checksumming belongs in the filesystem, not
PostgreSQL.
Doing checksums in the filesystem has some downsides. One is that you
need to use a
Fields, Zachary J. (MU-Student) zjf...@mail.missouri.edu writes:
I'm working on PostgreSQL 9.13 (waiting for admin to push upgrades next
week), in the meanwhile, I was curious if there are any known bugs regarding
large cursor fetches, or if I am to blame.
My cursor has 400 million records,
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Do we want some more stuff provided by pg_dropped_objects? We now have
classId, objectId, objectSubId, object name, schema name. One further
thing I think we need is the object's type, i.e. a simple untranslated
On Mon, Mar 4, 2013 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fields, Zachary J. (MU-Student) zjf...@mail.missouri.edu writes:
I'm working on PostgreSQL 9.13 (waiting for admin to push upgrades next
week), in the meanwhile, I was curious if there are any known bugs regarding
large
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm very unsure about that idea. In any case the proposed name seems
way too general. Maybe we could have a separate datatype for objects
being dropped, which would be specific to
pg_event_trigger_dropped_objects(), and not try to mix it with
On Thu, Feb 28, 2013 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whichever way we go, the resulting patch is likely to be too large and
invasive for me to feel terribly comfortable about back-patching it into
9.2. AFAICT this issue only arises for indexquals extracted out of
larger OR
On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus j...@agliodbs.com wrote:
I thought it was a useful idea anyway, but I could see his point. This
should probably move to Waiting on Author when it happens, presuming
that the person who wrote something is motivated to see the change
committed. (If
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need
to fire an event trigger for the dropped column? Right now we don't,
ISTM we should. And if we want that, then the above set of three
On Mon, Mar 4, 2013 at 8:34 AM, Magnus Hagander mag...@hagander.net wrote:
Committers,
please hold *all* pushes to the PostgreSQL repository until we have
resolved the issue mentioned in
http://www.postgresql.org/message-id/cabuevezm2f8qaxvds9me-41l5bqeego4duoscqhc0c6v05h...@mail.gmail.com.
On Wed, Feb 27, 2013 at 12:09 PM, Stephen Frost sfr...@snowman.net wrote:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
I don't agree so it works well - you cannot use short type names is
significant issue
This is for psql. In what use-case do you see that being a serious
limitation?
I
On Sun, Mar 3, 2013 at 6:05 PM, Greg Smith g...@2ndquadrant.com wrote:
On 3/3/13 4:31 PM, Josh Berkus wrote:
I'd like to add a new CF status, Pending Discussion. This status
would be used for patches which have long discussions regarding syntax
or difficult functionality on this list which
Where was that discussed, and who objected to the 2nd CF manager?
It was discussed when Craig volunteered. I suggested two CF managers,
two people (and Craig) said no, and nobody supported the idea. So I
dropped it.
It's a bit late now, but we've learned that having only one CF manager
for
On Sun, Mar 03, 2013 at 10:30:11PM -0500, Peter Eisentraut wrote:
On Fri, 2013-03-01 at 14:25 -0500, Noah Misch wrote:
On Mon, Jan 14, 2013 at 06:51:05AM -0500, Peter Eisentraut wrote:
In multi-arch OS installations, using a single foo-config script to
find
libraries is problematic,
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Do we want some more stuff provided by pg_dropped_objects? We now have
classId, objectId, objectSubId, object name, schema name. One further
thing I think we need is the object's type, i.e. a simple untranslated
Josh,
* Josh Kupershmidt (schmi...@gmail.com) wrote:
I still think this patch is an improvement over the status quo, and is
committable as-is. Yes, the patch doesn't address the existing
ugliness with minimal_error_message() and sidestepping PSQLexec(), but
at least it fixes the --echo-hidden
On Mon, Mar 4, 2013 at 11:39 AM, Stephen Frost sfr...@snowman.net wrote:
Josh,
* Josh Kupershmidt (schmi...@gmail.com) wrote:
I still think this patch is an improvement over the status quo, and is
committable as-is. Yes, the patch doesn't address the existing
ugliness with
On Mon, Mar 4, 2013 at 1:32 AM, Pavel Golub pa...@microolap.com wrote:
JJ I've put up a wiki page:
JJ https://wiki.postgresql.org/wiki/Building_With_MinGW
Jeff, I think inromation about installing dependencies should be added
to this Wiki. At least zlib and openssl are must have for libpq,
* Josh Kupershmidt (schmi...@gmail.com) wrote:
Sorry, this second version posted by Pavel:
http://www.postgresql.org/message-id/cafj8prb3-tov5s2dcgshp+vedyk9s97d7hn7rdmmw9ztrj-...@mail.gmail.com
Yeah, no, I don't think we should go in this direction. The whole
TraceQuery thing is entirely
On 3/4/13 2:11 AM, Simon Riggs wrote:
It's crunch time. Do you and Jeff believe this patch should be
committed to Postgres core?
I want to see a GUC to allow turning this off, to avoid the problem I
saw where a non-critical header corruption problem can cause an entire
page to be unreadable.
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus j...@agliodbs.com wrote:
Except that the implication of waiting on author is that, if there's
no updates in a couple weeks, we bounce it. And the author doesn't
necessarily control a bikeshedding discussion
Fields, Zachary J. (MU-Student) zjf...@mail.missouri.edu writes:
Thanks for getting back to me! I had already discovered freeing the
SPI_tuptable each time, and you are correct, it made a big difference.
However, I still was only able to achieve 140+ million before it crashed.
My current
On Mon, Mar 4, 2013 at 11:54 AM, Stephen Frost sfr...@snowman.net wrote:
Yeah, no, I don't think we should go in this direction. The whole
TraceQuery thing is entirely redundant to what's already there and which
should have been used from the beginning. This would be adding on to
that
On Mon, 2013-02-25 at 01:30 -0500, Greg Smith wrote:
Attached is some bit rot updates to the checksums patches. The
replace-tli one still works fine. I fixed a number of conflicts in the
larger patch. The one I've attached here isn't 100% to project
standards--I don't have all the
Magnus Hagander mag...@hagander.net writes:
AFAICT, there's a bug in tm2timestamp(). You can't do this:
postgres=# select '1999-12-31T24:00:00'::timestamptz;
ERROR: timestamp out of range: 1999-12-31T24:00:00
But that's a perfectly legal date. It works fine for any other year -
and AFAICT
Tom Lane wrote:
BTW, it strikes me that it's a bit silly to go to all this effort
here, and then ignore the possibility of overflow in the dt2local
adjustment just below. But we'd have to change the API of that
function, which I don't especially feel like doing right now.
Another point
On 04.03.2013 20:58, Greg Smith wrote:
There
is no such thing as a stable release of btrfs, and no timetable for when
there will be one. I could do some benchmarks of that but I didn't think
they were very relevant. Who cares how fast something might run when it
may not work correctly? btrfs
Alvaro Herrera wrote:
Tom Lane wrote:
BTW, it strikes me that it's a bit silly to go to all this effort
here, and then ignore the possibility of overflow in the dt2local
adjustment just below. But we'd have to change the API of that
function, which I don't especially feel like doing
On Mon, 2013-03-04 at 11:52 +0800, Craig Ringer wrote:
I also suspect that at least in the first release it might be desirable
to have an option that essentially says something's gone horribly wrong
and we no longer want to check or write checksums, we want a
non-checksummed DB that can still
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Alvaro Herrera wrote:
Another point worth considering is that most of this is duplicated by
ecpg's libpgtypes.
Bah, ignore this.
Huh? I think you're quite right that it'd be a good idea to get rid of
the duplicated code, if we could. It's
On Mon, Mar 4, 2013 at 8:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
AFAICT, there's a bug in tm2timestamp(). You can't do this:
postgres=# select '1999-12-31T24:00:00'::timestamptz;
ERROR: timestamp out of range: 1999-12-31T24:00:00
But that's a
On Mon, 2013-03-04 at 22:13 +0200, Heikki Linnakangas wrote:
On 04.03.2013 20:58, Greg Smith wrote:
There
is no such thing as a stable release of btrfs, and no timetable for when
there will be one. I could do some benchmarks of that but I didn't think
they were very relevant. Who cares
On 04.03.2013 18:00, Jeff Davis wrote:
On Mon, 2013-03-04 at 10:36 +0200, Heikki Linnakangas wrote:
On 04.03.2013 09:11, Simon Riggs wrote:
Are there objectors?
FWIW, I still think that checksumming belongs in the filesystem, not
PostgreSQL.
Doing checksums in the filesystem has some
On Sun, 2013-03-03 at 22:18 -0500, Greg Smith wrote:
As for a design of a GUC that might be useful here, the option itself
strikes me as being like archive_mode in its general use. There is an
element of parameters like wal_sync_method or enable_cassert though,
where the options available
On Mon, 2013-03-04 at 13:58 -0500, Greg Smith wrote:
On 3/4/13 2:11 AM, Simon Riggs wrote:
It's crunch time. Do you and Jeff believe this patch should be
committed to Postgres core?
I want to see a GUC to allow turning this off, to avoid the problem I
saw where a non-critical header
On 3/4/13 10:00 AM, Jeff Davis wrote:
On Mon, 2013-03-04 at 10:36 +0200, Heikki Linnakangas wrote:
On 04.03.2013 09:11, Simon Riggs wrote:
Are there objectors?
FWIW, I still think that checksumming belongs in the filesystem, not
PostgreSQL.
Doing checksums in the filesystem has some
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Alvaro Herrera wrote:
Another point worth considering is that most of this is duplicated by
ecpg's libpgtypes.
Bah, ignore this.
Huh? I think you're quite right that it'd be a good idea to get rid of
the duplicated
On 3/4/13 2:48 PM, Jeff Davis wrote:
On Mon, 2013-03-04 at 13:58 -0500, Greg Smith wrote:
On 3/4/13 2:11 AM, Simon Riggs wrote:
It's crunch time. Do you and Jeff believe this patch should be
committed to Postgres core?
I want to see a GUC to allow turning this off, to avoid the problem I
On Mon, 2013-03-04 at 22:27 +0200, Heikki Linnakangas wrote:
Yeah, fragmentation will certainly hurt some workloads. But how badly,
and which workloads, and how does that compare with the work that
PostgreSQL has to do to maintain the checksums? I'd like to see some
data on those things.
I
On 04.03.2013 22:51, Jim Nasby wrote:
The time to
object to the concept of a checksuming feature was a long time ago,
before a ton of development effort went into this... :(
I did. Development went ahead anyway.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 04.03.2013 22:40, Jeff Davis wrote:
Is there any reason why we can't have both postgres and filesystem
checksums?
Of course not. But if we can get away without checksums in Postgres,
that's better, because then we don't need to maintain that feature in
Postgres. If the patch gets
On Thu, Feb 28, 2013 at 1:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/28/2013 11:37 AM, Jeff Janes wrote:
Did you copy libpq.dll from the lib directory to the bin
directory? If not, try that and see if it fixes the problem.
I've now done that, and it did fix the
On Mon, Mar 04, 2013 at 01:00:09PM -0800, Jeff Davis wrote:
On Mon, 2013-03-04 at 22:27 +0200, Heikki Linnakangas wrote:
If you're serious enough about your data that you want checksums, you
should be able to choose your filesystem.
I simply disagree. I am targeting my feature at casual
On 03/04/2013 04:12 PM, Jeff Janes wrote:
If you mean on Windows itself, I did get a warning during the
./configure stage:
./configure --host=x86_64-w64-mingw32 --without-zlib /dev/null
configure: WARNING: If you wanted to set the --build type, don't use
--host.
If a cross compiler is
On 04.03.2013 23:00, Jeff Davis wrote:
On Mon, 2013-03-04 at 22:27 +0200, Heikki Linnakangas wrote:
Yeah, fragmentation will certainly hurt some workloads. But how badly,
and which workloads, and how does that compare with the work that
PostgreSQL has to do to maintain the checksums? I'd like
On 3/4/13 3:00 PM, Heikki Linnakangas wrote:
On 04.03.2013 22:51, Jim Nasby wrote:
The time to
object to the concept of a checksuming feature was a long time ago,
before a ton of development effort went into this... :(
I did. Development went ahead anyway.
Right, because the community felt
On 04.03.2013 22:51, Jim Nasby wrote:
Additionally, no filesystem I'm aware of checksums the data in the
filesystem cache. A PG checksum would.
The patch says:
+ * IMPORTANT NOTE -
+ * The checksum is not valid at all times on a data page. We set it before we
+ * flush page/buffer, and
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Perhaps we should just wait a few years? If we suspect that this
becomes obsolete in a few years, it's probably better to just wait,
than add a feature we'll have to keep maintaining. Assuming it gets
committed today, it's going to take a
Hi,
When I accessed the materialized view in the standby server,
I got the following ERROR message. Looks odd to me. Is this a bug?
ERROR: materialized view hogeview has not been populated
HINT: Use the REFRESH MATERIALIZED VIEW command.
The procedure to reproduce this error message
Alvaro Herrera escribió:
I think this is mostly ready to go in. I'll look at your docs, and
unless there are more objections will commit later or early tomorrow.
Actually it still needs a bit more work: the error messages in
pg_event_trigger_dropped_object need to be reworked. It's a bit
Hello.
I have a database dump file (unfortunately with proprietary information)
which leads to the following error in logs during its restoration (even
after initdb - it is stable reproducible, at the same large table, the same
time):
*LOG: server process (PID 18705) was terminated by signal 7:
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The real difficulty is that there may be more than one storable value
that corresponds to 1.23456 to six decimal digits. To be certain that
we can reproduce the stored value uniquely, we have to err in the other
direction, and
Fujii Masao masao.fu...@gmail.com wrote:
When I accessed the materialized view in the standby server,
I got the following ERROR message. Looks odd to me. Is this a bug?
ERROR: materialized view hogeview has not been populated
HINT: Use the REFRESH MATERIALIZED VIEW command.
The
On Mon, Mar 04, 2013 at 01:59:31PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus j...@agliodbs.com wrote:
Except that the implication of waiting on author is that, if there's
no updates in a couple weeks, we bounce it. And the
On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda m.sakre...@gmail.com wrote:
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The real difficulty is that there may be more than one storable value
that corresponds to 1.23456 to six decimal digits. To be certain that
we can
On 03/05/2013 04:48 AM, Jeff Davis wrote:
We would still calculate the checksum and print the warning; and then
pass it through the rest of the header checks. If the header checks
pass, then it proceeds. If the header checks fail, and if
zero_damaged_pages is off, then it would still generate
On 3/4/13 3:13 PM, Heikki Linnakangas wrote:
This PostgreSQL patch hasn't seen any production use, either. In fact,
I'd consider btrfs to be more mature than this patch. Unless you think
that there will be some major changes to the worse in performance in
btrfs, it's perfectly valid and useful
On 3/4/13 5:20 PM, Craig Ringer wrote:
On 03/05/2013 04:48 AM, Jeff Davis wrote:
We would still calculate the checksum and print the warning; and then
pass it through the rest of the header checks. If the header checks
pass, then it proceeds. If the header checks fail, and if
zero_damaged_pages
On 03/05/2013 08:15 AM, Jim Nasby wrote:
Would it be better to do checksum_logging_level = valid elog levels
? That way someone could set the notification to anything from DEBUG
up to PANIC. ISTM the default should be ERROR.
That seems nice at first brush, but I don't think it holds up.
All
On 3/4/13 6:22 PM, Craig Ringer wrote:
On 03/05/2013 08:15 AM, Jim Nasby wrote:
Would it be better to do checksum_logging_level = valid elog levels
? That way someone could set the notification to anything from DEBUG
up to PANIC. ISTM the default should be ERROR.
That seems nice at first
Heikki,
Perhaps we should just wait a few years? If we suspect that this becomes
obsolete in a few years, it's probably better to just wait, than add a
feature we'll have to keep maintaining. Assuming it gets committed
today, it's going to take a year or two for 9.3 to get released and all
On 03/04/2013 11:57 PM, Cliff_Bytes wrote:
Merlin
I will try your suggestion, thanks. I am somewhat surprised to find few
hacks related to my issue. And the BYTEA type and function documentation
leave much to be desired, IMHO, being a newbie on the Type BYTEA front.
One of the most helpful
On Mon, Mar 4, 2013 at 1:22 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 04.03.2013 23:00, Jeff Davis wrote:
On Mon, 2013-03-04 at 22:27 +0200, Heikki Linnakangas wrote:
Yeah, fragmentation will certainly hurt some workloads. But how badly,
and which workloads, and how does that
On 03/05/2013 12:33 AM, Robert Haas wrote:
On Thu, Feb 28, 2013 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whichever way we go, the resulting patch is likely to be too large and
invasive for me to feel terribly comfortable about back-patching it into
9.2. AFAICT this issue only arises for
On 03/05/2013 02:06 AM, Josh Berkus wrote:
Where was that discussed, and who objected to the 2nd CF manager?
It was discussed when Craig volunteered. I suggested two CF managers,
two people (and Craig) said no, and nobody supported the idea. So I
dropped it.
If I said no I was wrong to do
On Mon, 2013-03-04 at 14:57 -0600, Jim Nasby wrote:
I suggest we paint that GUC along the lines of
checksum_failure_log_level, defaulting to ERROR. That way if someone
wanted completely bury the elogs to like DEBUG they could.
The reason I didn't want to do that is because it's essentially a
On Mon, 2013-03-04 at 23:22 +0200, Heikki Linnakangas wrote:
On 04.03.2013 23:00, Jeff Davis wrote:
On Mon, 2013-03-04 at 22:27 +0200, Heikki Linnakangas wrote:
Yeah, fragmentation will certainly hurt some workloads. But how badly,
and which workloads, and how does that compare with the
On Mon, 2013-03-04 at 23:11 +0200, Heikki Linnakangas wrote:
Of course not. But if we can get away without checksums in Postgres,
that's better, because then we don't need to maintain that feature in
Postgres. If the patch gets committed, it's not mission accomplished.
There will be
On Sun, 2013-03-03 at 18:05 -0500, Greg Smith wrote:
= Test 1 - find worst-case overhead for the checksum calculation on write =
This can hit 25% of runtime when you isolate it out. I'm not sure if
how I'm running this multiple times makes sense yet. This one is so
much slower on my Mac
On Monday, March 4, 2013, Robert Haas wrote:
On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus j...@agliodbs.comjavascript:;
wrote:
I thought it was a useful idea anyway, but I could see his point. This
should probably move to Waiting on Author when it happens, presuming
that the person who
91 matches
Mail list logo
