On Fri, Jan 29, 2010 at 12:09 PM, Jonah H. Harris wrote:
> On Fri, Jan 29, 2010 at 11:57 AM, Tom Lane wrote:
>
>> I find it doubtful that it's actually necessary in Oracle's version
>> of listagg ...
>>
>
> Eh?
>
>
> http://download.oracle.com/doc
imiter_expr'])
*WITHIN GROUP* (order_by_clause) [*OVER* query_partition_clause]
--
Jonah H. Harris
must be a constant.
Query: SELECT listagg(a, ',') WITHIN GROUP (ORDER BY a) FROM foo;
Result: aaa,bbb,ccc
Query: SELECT listagg(a, ';') WITHIN GROUP (ORDER BY a) FROM foo;
Result: aaa;bbb;ccc
Query: SELECT listagg(a, '+') WITHIN GROUP (ORDER BY a) FROM foo;
Result: aaa+bbb+ccc
--
Jonah H. Harris
7;t run into MySQL at all). I know
> others likely compete in the DB2 space.
>
To my knowledge, MySQL, InnoDB, BerkeleyDB, solidDB, Oracle, SQL Server,
Sybase, DB2, eXtremeDB, RDB, and Teradata all checksum pages.
--
Jonah H. Harris, Senior DBA
myYearbook.com
; the future.
>
Perhaps. Though, I only posted because you made it sound somewhat
impossible and because I only know of a few ppl in the PG community that
offer it and/or have done is successfully. Maybe letting people know there
are options, other than being screwed, is wrong... my bad :-)
--
G databases suffering from both hardware and software corruption on
versions 7.0 through 8.3. My rate is $300-600 USD/hour depending on the
database/table size and the extent of the corruption.
If you're just trying to save what's not corrupted, there's quite a few
examples online.
--
Jonah H. Harris
now. Though, Tom may still
maintain his own xlogdump.
--
Jonah H. Harris, Senior DBA
myYearbook.com
Unfortunately, when I reviewed the architecture, I saw that it was too good
to be true. Perhaps it has been rearchitected in private to overcome some
of these issues, but I'm not aware of it. All attempts to talk to Atsushi
about it were met with no response.
--
Jonah H. Harris, Senior DBA
myYearbook.com
Simon's work on hot standby either. As such, it's my opinion
that continuing to criticize him from the sidelines is not only rude, but is
also a bad idea as it relates to his motivation in working on this feature.
--
Jonah H. Harris, Senior DBA
myYearbook.com
line format, I just wanted to say that I preferred
host:port rather than host(port).
--
Jonah H. Harris, Senior DBA
myYearbook.com
to another server.
Not any more malicious than a connection string in and of itself. It's
only used as a hierarchical name-value pair string, nothing is executed from
it.
--
Jonah H. Harris, Senior DBA
myYearbook.com
it were my business, it doesn't
seem like something I would put much effort into :)
Whether or not they actually will fix it, I don't know, but they surely
> won't if no-one complains them about it.
Wouldn't hurt :)
--
Jonah H. Harris, Senior DBA
myYearbook.com
1% of their users
in odd corner cases?
--
Jonah H. Harris, Senior DBA
myYearbook.com
FAIK, there is no way to override that. It's very low-level in their
client stack, is operating-system specific, and has been there forever.
--
Jonah H. Harris, Senior DBA
myYearbook.com
On Mon, Mar 16, 2009 at 2:26 PM, Jonah H. Harris wrote:
> On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera <
> alvhe...@commandprompt.com> wrote:
>
>> We already have one; it's called update_process_title.
>
>
> I have it turned off, and I still see the r
On Mon, Mar 16, 2009 at 2:04 PM, Alvaro Herrera
wrote:
> We already have one; it's called update_process_title.
I have it turned off, and I still see the remote IP/port in the process
list.
--
Jonah H. Harris, Senior DBA
myYearbook.com
On Mon, Mar 16, 2009 at 12:36 PM, Alvaro Herrera wrote:
> Jonah H. Harris escribió:
>
> Wow, that's a really idiotic thing for Oracle to do.
Well, being able to find out what applications are connected to the database
is nice. But, it would also be nice if they stopped parsi
On Mon, Mar 16, 2009 at 12:50 PM, Tomasz Olszak wrote:
> Thank you very much, I tried to solve it for about 2 weeks. I know that few
> people in the net have the same problem too.
No problem :)
--
Jonah H. Harris, Senior DBA
myYearbook.com
a a colon, just as everything else does, but that isn't
backward compatible.
I would expect this to become more of an issue when we start getting SQL/MED
more closely integrated with the server and people can more easily connect
to other databases.
--
Jonah H. Harris, Senior DBA
myYearbook.com
kend/postmaster/postmaster.c:
remote_port[0] == '\0' ? "%s" : "%s(%s)"
TO
remote_port[0] == '\0' ? "%s" : "%s[%s]"
OR
remote_port[0] == '\0' ? "%s" : "%s:%s"
Which I would prefer as a nice change to make overall.
--
Jonah H. Harris, Senior DBA
myYearbook.com
m with the language not parsing things correctly and
doing, in many cases, brain-dead replacements. I don't know of any
developer using OUT parameters that doesn't run into this problem at one
time or another :(
--
Jonah H. Harris, Senior DBA
myYearbook.com
disastrous event, I see myself saying, "no..."
OK, back to reality.
SQL/MED does support foreign tables, which are basically synonyms for remote
tables. Other than that, it has no real similarity to synonym behavior for
other database objects such as views, functions, or local tables.
--
Jonah H. Harris, Senior DBA
myYearbook.com
imized for md over the past 6 years or so. It may even be
easier/preferred to write a hadoop specific access method depending on what
you're looking for from hadoop.
--
Jonah H. Harris, Senior DBA
myYearbook.com
On Thu, Feb 12, 2009 at 11:37 AM, Joshua D. Drake wrote:
> --num-workers or --num-connections would both work.
--num-parallel?
--
Jonah H. Harris, Senior DBA
myYearbook.com
ing a legal commitment, say, with a few tens of million dollars in
> escrow to back it?
Per IRC, this discussion will (and likely should) be taken elsewhere.
--
Jonah H. Harris, Senior DBA
myYearbook.com
aste that link in a public forum.
First of all, it was not an intentional patent search. Secondly, I don't
believe there's any restriction of explicitly what can and cannot be posted
on a public Postgres mailing list.
> Should we have a kick-off policy for this kind of misbehavior?
On Tue, Feb 10, 2009 at 8:41 PM, Tom Lane wrote:
> "Jonah H. Harris" writes:
> > Cripes! I just had an idea and it looks like the buggers beat me to it
> :(
> > http://www.google.com/patents?id=4bqBEBAJ&dq=null+aware+anti-join
>
> I wonder if the USP
On Tue, Feb 10, 2009 at 8:09 PM, Jonah H. Harris wrote:
> On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane wrote:
>
>> I wrote (in response to Kevin Grittner's recent issues):
>> > Reflecting on this further, I suspect there are also some bugs in the
>> > planner&#x
> After doing some math I've concluded this is in fact the case. Anyone
> want to check my work?
FWIW, the logic looks correct to me.
--
Jonah H. Harris, Senior DBA
myYearbook.com
On Wed, Feb 4, 2009 at 10:12 AM, Greg Stark wrote:
> On Wed, Feb 4, 2009 at 3:07 PM, Kevin Grittner
> > It's been about 23 hours and it's still running.
>
> @snide(Gee, it sure would be nice if we continued with that
> explain-in-progress patch I had sent in earlier
d procedure in the WHERE clause as well as dynamically adding
security-related predicates to the WHERE-clause.
--
Jonah H. Harris, Senior DBA
myYearbook.com
rt us to have it.
Just to make it clear, this feature wouldn't make Postgres a "trusted"
database in any certification sense. So, using that term would likely cause
confusion and get people who used it thinking it had an EAL certification
into trouble.
--
Jonah H. Harris, Senior DBA
myYearbook.com
around September/October (having no
> commit
> > fests), that means it will probably be early 2011 for 8.6, which is
> fairly
> > unacceptable for the other patches currently in the queue.
>
> Right, one of the major considerations here is allowing other
> development to get
eans it will probably be early 2011 for 8.6, which is fairly
unacceptable for the other patches currently in the queue.
--
Jonah H. Harris, Senior DBA
myYearbook.com
, and seemingly no one wants to
review them now, how can we expect this to change for 8.5? Can anyone point
out something Simon did wrong in this process?
--
Jonah H. Harris, Senior DBA
myYearbook.com
; Oh, didn't realize that. That's what I get for replying without
> reading the patch...
Yes :)
--
Jonah H. Harris, Senior DBA
myYearbook.com
On Thu, Nov 6, 2008 at 12:03 AM, Jonah H. Harris wrote:
> As I wasn't sure whether anyone agrees with my distaste for
> repurposing tgenabled as mentioned above, I have attached is a patch
> which minimally corrects the function comment for EnableDisableTrigger
> where fires_
On Tue, Jan 6, 2009 at 12:38 PM, Robert Haas wrote:
> - WIP: Hash Join-Filter Pruning using Bloom Filters is in the commitfest
I'm pulling this patch and resubmitting for 8.5.
--
Jonah H. Harris, Senior DBA
myYearbook.com
as part of our hash table
implementation (which I'm quite fond of actually). FWIS, I think we'll look
more into this sometime in the future.
--
Jonah H. Harris, Senior DBA
myYearbook.com
k and I hope we don't switch to it. Though, as I must've
missed it, what's the main complaint with the current build system?
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
are
self-contained and interface with the database through a defined API.
What happens inside them should be irrelevant to PG.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
, but the locking overhead would probably be
fairly high. The problem is, at this point, we don't really know what
the impact would be either way :(
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
ected production performance issues.
It is pretty late in the process to continue with this design-related
discussion, but I really wanted to see it in 8.4.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 15, 2008 at 11:29 AM, Tom Lane wrote:
> "Jonah H. Harris" writes:
>> On Mon, Dec 15, 2008 at 10:13 AM, Bruce Momjian wrote:
>>> Feature freeze is not the time to be looking for new ideas. I suggest
>>> we save this for 8.5.
>
>> Well, w
On Mon, Dec 15, 2008 at 10:13 AM, Bruce Momjian wrote:
> Jonah H. Harris wrote:
>> >> Alvaro, have you given up on the patch or are you just busy on
>> >> something else at the moment?
>> >
>> > I've given up until we find a good way to handle h
he moment?
>
> I've given up until we find a good way to handle hint bits. Various
> schemes have been proposed but they all have more or less fatal flaws.
Agreed. Though, I don't want to see this patch get dropped from 8.4.
ALL, Alvaro has tried a couple different methods, does an
ooked into what needs to be done to fix
it.
Similarly, I ran a pgbench, performed a manual checkpoint, and
corrupted the tellers table myself using hexedit but the system didn't
pick up the corruption at all :(
Alvaro, have you given up on the patch or are you just busy on
something else at the
On Thu, Dec 11, 2008 at 4:43 AM, Dmitry Turin
<[EMAIL PROTECTED]> wrote:
> We would like to obtain your opinion on these two questions:
This is the wrong place to do it.
> 2) We are captivated by price of Indians,
> we listened much about low quality of code, written by Indians,
> we are fearing,
they are already investigating
> either via the lists or via a vendor anyway.
Agreed.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
c for this thread, so I'll postpone the
discussion for 8.5.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> IMHO, the only thing worse than an unstable plan is a stable one.
Your opinion contradicts the majority of the industry then, I'm
afraid. Like query hints, people are sometimes smarter than the
optimizer
store
> them, revert back to old statistics etc.
Yes, plan stability would be a Good Thing(tm) IMO.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be better, but the planner isn't perfect.
Oracle already thought of that a long time ago, which is why the plan
has to come out better for it to take effect. As for bad plans, you
obviously haven't used Postgres in production enough to deal with it
continually changing plans for
, so that option wouldn't be quite that easy to
implement. Though, there are certain things ANALYZE would be able to
determine with a little help, such as knowing to collect more samples
for columns it finds extremely skewed data in.
There are other things that could be done as well... so the ans
nd was just wondering whether
someone is addressing it for 8.4? In a large-scale OLTP environment,
uptime is paramount, and having to restart the database to enable PITR
is a big PITA.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
allocated to
> the join. That is, does the bloom filter consume some of the work_mem
> space or is it treated as additional memory allocated to the join.
Currently it's additional space not accounted for by work_mem.
Additionally, it's a good amount more space than is required.
to companies that do Postgres consulting.
> You can find examples on the website and through google. You could also try
> posting to pgsql-jobs.
I would suggest submitting it to pgsql-jobs.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Sun, Nov 9, 2008 at 7:55 PM, Decibel! <[EMAIL PROTECTED]> wrote:
> On Nov 8, 2008, at 8:35 PM, Jonah H. Harris wrote:
>> That's my question. Why is this needed at all?
>
> I suspect this is to deal with needing to reserve space in a cluster that
> you're plan
On Sat, Nov 8, 2008 at 8:08 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
>> Attached patch allows to setup storage parameter for space
>> reservation.
>
> What is the point of this?
That's my question. Why is this neede
might be reasonable to auto-recreate XLOGDIR/archive_status, though.
Attached.
BTW, I have seen people create both pg_xlog and archive_status as
files, which is why I'm validating that in this function rather than
waiting for it to error-out later in the code.
--
Jonah H. Harris, Senior DBA
, recreates them.
--
Jonah H. Harris, Senior DBA
myYearbook.com
arcstatdir.patch
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
led rather than
the current implementation.
Oh well, it was just a thought.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
trigger-related code in 8.5, and just
thought it would be nice to clean it up if one had the time to do so.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed above, I have attached is a patch
which minimally corrects the function comment for EnableDisableTrigger
where fires_when is concerned.
--
Jonah H. Harris, Senior DBA
myYearbook.com
endisable_trig_fctn_commnt_cleanup.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgs
Well, what is the official deadline on it? It, like several other
patches on the wiki, was a WIP. I'm hopeful that RI-based join
elimination for JOIN_INNER should be ready tonight based on your and
Tom's comments.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers
on.
> What would probably be better is a patch to rename exprno, rfno, etc
> to all be called dno to make this connection more obvious.
Attached. Passed regressions and basic testing.
--
Jonah H. Harris, Senior DBA
myYearbook.com
plpgsql_datumnaming_cleanup.patch
Description: Binary d
While looking to add some functionality to PL/pgSQL, I found that the
rfno member of the PLpgSQL_recfield structure is unused. This patch
is just a cleanup and doesn't seem along the same lines as the patches
in CommitFest... should I add it to the wiki anyway?
--
Jonah H. Harris, Senio
On Sun, Nov 2, 2008 at 5:36 PM, Hannes Eder <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 2, 2008 at 10:49 PM, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
>> Similarly, I
>> created a GUC to enable pruning, named bloom_pruning.
>
> I guess calls to bloom_filte
g and
providing input, I'll commit to having this ready for 8.4.
--
Jonah H. Harris, Senior DBA
myYearbook.com
bloompruning_v1.patch
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
f the page
>> header varies depending on whether you're using CRCs that sounds like it
>> would
>> be quite a pain.
>
> Not mandatory, but the space needs to be set aside. (Otherwise you
> couldn't turn it on after running with it turned off, which would rule
On Thu, Oct 30, 2008 at 11:27 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>> On Thu, Oct 30, 2008 at 11:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Well, yeah, but it has to be able to tell which vers
On Thu, Oct 30, 2008 at 11:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>> On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>>> Please, DO NOT MOVE positio
, did I miss something significant in the in-place
upgrade design?
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
it working, but I'd
> like to see this as part of 8.4, as SQL/MED is just way too ambitious
> given the time frame.
To be more specific, SQL/MED is going to be 8.5. This is an overall
improvement for accessing the predicate.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via
ing :) I'm mostly interested in the connection
> management -- so hopefully I can help there.
That would be awesome!
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On Mon, Oct 27, 2008 at 10:35 AM, Jonah H. Harris
<[EMAIL PROTECTED]> wrote:
> The first wrappers I intend to support are ODBC and
Damn multiple windows :)
The first wrappers I intend to support are ODBC and CSV/fixed-width text.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
rt are ODBC and
This is a large project, and I'm certainly open to assistance :)
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 24, 2008 at 7:59 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-10-24 at 00:52 -0400, Jonah H. Harris wrote:
>> While we could build an
>> abstract prefetch interface and simply use fadvise for it now (rather
>> than OS-specific code), I don&#x
t now (rather
than OS-specific code), I don't see an easy win in any case.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ething wrong, because my tests showed
it quite well. Pull the source to iozone or fio.
> In what way is fadvise a kludge?
non-portable, requires more user-to-system CPU, ... need I go on?
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> True, it is a kludge but if it gives us 95% of the benfit with 10% of
> the code, it is a win.
I'd say, optimistically, maybe 30-45% the benefit over a proper
multi-block read using O_DIRECT.
--
Jonah
still makes us completely
reliant on the OS. For performance reasons, we should be supporting a
multi-block read directly into shared buffers. IIRC, we currently
have support for rings in the buffer pool, which we could read
directly into. Though, an LRU-based buffer manager design would be
mor
es */
Passed regressions and several benchmarks for me.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
vercomplicated to me.
> The problem with that is that skipping the hint bits for the main crc would
> slow it down severely. It would make a lot of sense if the hint bits were
> all in a contiguous block of memory but I can't see how to make that add up.
Agreed.
--
Jonah H. Harris, Senio
te the new CRC).
Interesting idea... let me ponder it for a bit.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nd calculate a valid CRC on the page every n-th non-logged
> change.
I still think we should only calculate checksums on the actual write.
And, this still seems to have an issue with WAL, unless Simon's
original idea somehow included recording hint bit settings/dirtying
the page in WAL.
--
etting doesn't trigger a WAL record.
Hence, no page image is written to WAL for later use in recovery.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s a bit before I respond :)
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gt;
> The torn page is during kernel write to disk, I assume, so it is still
> possible.
Well, we can't really control too much of that. The most common
solution to that I've seen is to double-write the page (which some
OSes already do regardless). Or, are you meaning somet
ing the write, I don't see where we could be
introducing a torn-page, as we'd actually be writing a copied version
of the buffer. Will look into this.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s your "on disk guarentee", not the
> write, and that won't change.
Agreed.
> But I thought you didn't really care about hint-bit updates, even in the
> current strategy... but I'm fully ignorant about the code, sorry...
The current implementation does not take it in
, but I can see it potentially causing a number of
side-problems and it would require a fair amount of testing.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;ve not seen raised is that not checksumming the hint
> bits leaves you open to a single-bit error that incorrectly sets a hint
> bit.
Agreed.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
t isn't it a bit dangerous to have a single flag on the page indicating
> whether the CRC is valid or not? Any corruption that flips that bit would
> make the CRC check to be skipped.
Agreed.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-
)?
It was just an arbitrary value I chose to identify non-checksummed
pages; I believe would have the same collision rate as anything else.
> Would it not be better to add a boolean bit or byte to inidcate the crc
> state?
Ideally, though we don't have any spare bits to play with i
BLCKSZ buffer we could use immediately before write() which we could
copy the block to, perform the checksum on, and write out... is that
what you were thinking Tom?
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Thu, Oct 2, 2008 at 9:36 AM, Brian Hurt <[EMAIL PROTECTED]> wrote:
> Another possibility is to just not checksum the hint bits...
Seems like that would just complicate matters and prevent a viable checksum.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hacker
ld be.
Doesn't the problem still remain? The problem being that the buffer
can be changed as it's written, yes?
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On Thu, Oct 2, 2008 at 1:29 AM, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
> I ran the regressions and several concurrent benchmark tests which
> passed successfully, but I'm sure I'm missing quite a bit due to the
> the fact that it's late, it's just a quick hac
a quick hack, and I haven't gone
through the buffer manager locking code in awhile.
I'll be happy to work on this or let Alvaro take it; just as long as
it gets done for 8.4.
--
Jonah H. Harris, Senior DBA
myYearbook.com
blkcrc_v1.patch
Description: Binary data
--
Sent via pgsql
1 - 100 of 586 matches
Mail list logo
