Re: [HACKERS] 9.5: Memory-bounded HashAgg

2014-08-14 Thread Jeff Davis
HashAgg is just as bad as Sort.) That being said, we can hold out for an array_agg fix if desired. As I pointed out in another email, my proposal is compatible with the idea of dumping groups out of the hash table, and does take some steps in that direction. Regards, Jeff Davis -- Sent

Re: [HACKERS] 9.5: Memory-bounded HashAgg

2014-08-12 Thread Jeff Davis
hash tables for different aggregates, but it seems like it could work. (b) bad estimate of required memory - this is common for aggregates passing 'internal' state (planner uses some quite high defaults) Maybe some planner hooks? Ideas? Regards, Jeff Davis -- Sent via

Re: [HACKERS] 9.5: Memory-bounded HashAgg

2014-08-11 Thread Jeff Davis
On Mon, 2014-08-11 at 01:29 +0200, Tomas Vondra wrote: On 10.8.2014 23:26, Jeff Davis wrote: This patch is requires the Memory Accounting patch, or something similar to track memory usage. I think the patch you sent actually includes the accounting patch. Is that on purpose

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

2014-08-10 Thread Jeff Davis
On Fri, 2014-08-08 at 01:16 -0700, Jeff Davis wrote: Either way, it's better to be conservative. Attached is a version of the patch with opt-in memory usage tracking. Child contexts inherit the setting from their parent. There was a problem with the previous patch: the parent was unlinked

[HACKERS] 9.5: Memory-bounded HashAgg

2014-08-10 Thread Jeff Davis
that it can be competitive with sort+groupagg when the disk is involved, but more testing is required. Feedback welcome. Regards, Jeff Davis *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *** *** 2884,2889 include_dir 'conf.d' --- 2884,2904

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

2014-08-08 Thread Jeff Davis
. Either way, it's better to be conservative. Attached is a version of the patch with opt-in memory usage tracking. Child contexts inherit the setting from their parent. Regards, Jeff Davis *** a/src/backend/utils/mmgr/aset.c --- b/src/backend/utils/mmgr/aset.c *** *** 242,247

[HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

2014-08-02 Thread Jeff Davis
and more accurate. I did some simple pgbench select-only tests, and I didn't see any TPS difference. Regards, Jeff Davis *** a/src/backend/utils/mmgr/aset.c --- b/src/backend/utils/mmgr/aset.c *** *** 242,247 typedef struct AllocChunkData --- 242,249 #define

[HACKERS] numeric and float comparison oddities

2014-08-01 Thread Jeff Davis
represent every float value? That might make the numeric hierarchy a little cleaner and less surprising. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2014-07-21 Thread Jeff Davis
On Thu, 2014-07-10 at 23:43 -0700, Jeff Davis wrote: On Mon, 2014-07-07 at 01:21 -0700, Jeff Davis wrote: On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote: On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote: Thanks for the detailed feedback, I'm sorry it took so long

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2014-07-11 Thread Jeff Davis
On Mon, 2014-07-07 at 01:21 -0700, Jeff Davis wrote: On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote: On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote: Thanks for the detailed feedback, I'm sorry it took so long to incorporate it. I've attached the latest version of the patch

Re: [HACKERS] Allow multi-byte characters as escape in SIMILAR TO and SUBSTRING

2014-07-11 Thread Jeff Davis
better to document what character is allowed as escape in LIKE, SIMILAR TO and SUBSTRING. It should be assumed that multi-byte characters are allowed nearly everywhere, and we should document the places where only single-byte characters are allowed. Regards, Jeff Davis -- Sent via

Re: [HACKERS] Allow multi-byte characters as escape in SIMILAR TO and SUBSTRING

2014-07-11 Thread Jeff Davis
On Fri, 2014-07-11 at 11:51 -0400, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: Attached is a small patch to $SUBJECT. In master, only single-byte characters are allowed as an escape. Of course, with the patch it must still be a single character, but it may be multi-byte. I'm

[HACKERS] Allow multi-byte characters as escape in SIMILAR TO and SUBSTRING

2014-07-10 Thread Jeff Davis
Attached is a small patch to $SUBJECT. In master, only single-byte characters are allowed as an escape. Of course, with the patch it must still be a single character, but it may be multi-byte. Regards, Jeff Davis *** a/src/backend/utils/adt/regexp.c --- b/src/backend/utils/adt/regexp.c

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2014-07-07 Thread Jeff Davis
On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote: On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote: Thanks for the detailed feedback, I'm sorry it took so long to incorporate it. I've attached the latest version of the patch, fixing in particular: Looking a little more

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2014-07-06 Thread Jeff Davis
on this and hopefully get it committable soon. The attached patch is still a WIP; just posting it here in case you see any red flags. Regards, Jeff Davis *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** *** 13164,13169 SELECT xmlagg(x) FROM (SELECT x FROM test

[HACKERS] Re: [COMMITTERS] pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic

2014-06-26 Thread Jeff Davis
for HEAP2_CLEAN, it seemed to be a part of that action. But you're right: now it's more separate. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic

2014-06-23 Thread Jeff Davis
to simplify visibilitymap_set if the logging of the heap page for checksums could be done beforehand with this variant of MarkBufferDirtyHint. Regards, Jeff Davis [1] Not that we didn't make mistakes; at least one of which you heroically diagnosed just in time. -- Sent via pgsql-hackers

[HACKERS] [9.5] possible fast path for pinning a page multiple times

2014-05-25 Thread Jeff Davis
do too much performance testing of this, is it a correct approach? It seems too easy. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] rangetypes spgist questions/refactoring

2014-05-20 Thread Jeff Davis
if there are any non-empty ranges, in which case it has *no* empty ranges Note: I am using allTheSame in the logical sense; perhaps the flag is an internal optimization that we can't rely on. Regards, Jeff Davis *** a/src/backend/utils/adt/rangetypes_spgist.c --- b/src/backend/utils/adt

Re: [HACKERS] rangetypes spgist questions/refactoring

2014-05-20 Thread Jeff Davis
On Tue, 2014-05-20 at 09:52 -0700, Jeff Davis wrote: 2. Why would any tuple have 2 nodes? If there are some non-empty ranges, why not make a centroid and have 4 or 5 nodes? This is slightly more complicated than I thought, because we need to do something about the root node if a bunch of empty

[HACKERS] regression tests fail for different block sizes

2014-05-14 Thread Jeff Davis
consistent enough when the blocksize varies? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Comment patch for index-only scans

2014-05-04 Thread Jeff Davis
If I recall correctly, Tom pointed out a while back that the comment justifying the lockless read of the VM bit was not correct (or at least not complete). I rewrote it, but it was part of a patch that was not accepted. Attached is the comment patch only. Regards, Jeff Davis *** a/src

Re: [HACKERS] PQputCopyData dont signal error

2014-02-04 Thread Jeff Davis
a lot of client-side work and network traffic. Would a change to PQputCopyData be welcome? Regards, Jeff Davis [1] http://www.postgresql.org/docs/9.3/static/protocol-flow.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Extension Templates S03E11

2013-12-15 Thread Jeff Davis
for some of the use cases? What role to external tools play in all of this? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-14 Thread Jeff Davis
On Fri, 2013-12-13 at 13:42 -0500, Stephen Frost wrote: * Jeff Davis (pg...@j-davis.com) wrote: For what it's worth, I think the idea of extension templates has good conceptual integrity. Extensions are external blobs. To make them work more smoothly in several ways, we move them

Re: [HACKERS] Extension Templates S03E11

2013-12-13 Thread Jeff Davis
of that, the inability to handle native code limits the number of extensions that could make use of such a facility, which dampens my enthusiasm. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Extension Templates S03E11

2013-12-09 Thread Jeff Davis
On Mon, 2013-12-09 at 12:17 -0500, Robert Haas wrote: On Sat, Dec 7, 2013 at 3:12 AM, Jeff Davis pg...@j-davis.com wrote: So if we do it this way, then we should pick a new name, like package. That was my first reaction as well, when I looked at this a few years ago, but I've since backed

Re: [HACKERS] Extension Templates S03E11

2013-12-07 Thread Jeff Davis
, like package. And then we'll need to decide whether it still makes sense to use an external tool to transform a PGXN extension into a form that could be loaded as a package. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Extension Templates S03E11

2013-12-07 Thread Jeff Davis
On Sat, 2013-12-07 at 12:27 -0500, Stephen Frost wrote: * Jeff Davis (pg...@j-davis.com) wrote: The behavior of an extension should not depend on how it was installed. The kind of extension being described by Stephen will: * Not be updatable by doing ALTER EXTENSION foo UPDATE TO '2.0

Re: [HACKERS] Extension Templates S03E11

2013-12-04 Thread Jeff Davis
tied to the backend. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-04 Thread Jeff Davis
think you're too quick to rule them out. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-04 Thread Jeff Davis
or because there are multiple equal-length paths starting in the same place, we give up and emit an error. That seems like extreme overkill, and still doesn't give users full control over upgrade paths. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Extension Templates S03E11

2013-12-04 Thread Jeff Davis
solution there (e.g. user names rather than schemas), and per-DB templates are just not a good solution anyway. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Extension Templates S03E11

2013-12-04 Thread Jeff Davis
was to preserve OIDs for types, etc.: http://www.postgresql.org/message-id/20783.1297184...@sss.pgh.pa.us That doesn't seem to apply to ordinary dump/reload. Do you think it's good for other reasons, as well? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-04 Thread Jeff Davis
to the requested version. * If there's a tie, throw an error. That leaves us with plenty of room to improve the situation later, for instance if we support ordered versions. (I'm not sure if ordered versions was rejected outright, or we just didn't have time to do it properly.) Regards, Jeff

Re: [HACKERS] Extension Templates S03E11

2013-12-03 Thread Jeff Davis
) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-03 Thread Jeff Davis
On Tue, 2013-12-03 at 09:20 -0500, Stephen Frost wrote: * Jeff Davis (pg...@j-davis.com) wrote: Stephen mentioned using external tools and/or metadata, but to me that sounds like it would require porting the extension away from what's on PGXN today. Not at all- and that'd be the point

Re: [HACKERS] Extension Templates S03E11

2013-12-03 Thread Jeff Davis
On Tue, 2013-12-03 at 14:41 -0500, Stephen Frost wrote: * Jeff Davis (pg...@j-davis.com) wrote: The extra catalog tables which store SQL scripts in text columns is one of my main objections to the as-proposed Extension Templates. OK, that's what I thought. This seems like the root of your

Re: [HACKERS] Extension Templates S03E11

2013-12-03 Thread Jeff Davis
easier to get consistent behavior. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-02 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-12-02 Thread Jeff Davis
On Sun, 2013-12-01 at 15:48 +0100, Dimitri Fontaine wrote: Jeff Davis pg...@j-davis.com writes: I don't see why we are trying to accommodate a case where the author doesn't offer enough full SQL scripts and offers broken downgrade scripts; or why that case is different from offering broken

Re: [HACKERS] Extension Templates S03E11

2013-12-02 Thread Jeff Davis
and/or metadata, but to me that sounds like it would require porting the extension away from what's on PGXN today. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Extension Templates S03E11

2013-12-01 Thread Jeff Davis
On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote: Jeff Davis pg...@j-davis.com writes: Either of those solution are fine to me, with or without the automated SET ROLE when a superuser is installing an extension from a template owned by a non-superuser. Tell me your preference, I'll

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
On Sat, 2013-11-30 at 01:05 -0800, Jeff Davis wrote: Unless I'm missing something, I'd be inclined to just get rid of the concept of DEFAULT FULL VERSION just to keep the documentation simpler without losing any real functionality. I found some explanation of the original reasoning

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
templates are not in shared catalogs; was that discussed? (Some of these issues seem underdocumented, as well.) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
live with both file-based and catalog-based templates forever? I guess probably so, because the file-based templates probably are a little better for contrib itself (because the complaints about relying on OS packaging don't apply as strongly, if at all). Regards, Jeff Davis -- Sent via

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-11-30 Thread Jeff Davis
On Sat, 2013-11-30 at 23:03 +0100, Dimitri Fontaine wrote: Jeff Davis pg...@j-davis.com writes: When a superuser CREATE EXTENSION against a template that has been provided by a non-privileged user, automatically SET ROLE to that user before doing so, avoiding escalation privileges

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-11-29 Thread Jeff Davis
On Fri, 2013-11-29 at 16:18 -0500, Bruce Momjian wrote: On Fri, Jul 5, 2013 at 02:36:10PM -0700, Jeff Davis wrote: On Fri, 2013-06-28 at 13:26 -0400, Robert Haas wrote: I haven't really reviewed the windowing-related code in depth; I thought Jeff might jump back in for that part

Re: [HACKERS] Extension Templates S03E11

2013-11-25 Thread Jeff Davis
you think that's a dead end? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] session_preload_libraries not in sample config?

2013-11-24 Thread Jeff Davis
session_preload_libraries is not in the sample config file. Is that just an oversight? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logging WAL when updating hintbit

2013-11-23 Thread Jeff Davis
after any failover or upgrade seems to be a design gap. All that being said, I don't object to this option -- I just want it to lead us somewhere. Not be another option that we keep around forever with conflicting recommendations about how to set it. Regards, Jeff Davis -- Sent via

Re: [HACKERS] local_preload_libraries logspam

2013-11-23 Thread Jeff Davis
objects. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extension Templates S03E11

2013-11-23 Thread Jeff Davis
on? Is the discussion concluding, or does it need another round of review? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Freezing without write I/O

2013-11-23 Thread Jeff Davis
IDs. Can we get some help from the compiler to distinguish the two cases in a less error-prone way? Is it worth thinking about making 64-bit the norm, and 32-bit an optimization in certain places (e.g. the heap and maybe the xip array of a snapshot)? Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] [9.4] Make full_page_writes only settable on server start?

2013-09-04 Thread Jeff Davis
images for checksums. I'd like to remedy that. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 9.4 regression

2013-09-04 Thread Jeff Davis
the patch. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [9.4] Make full_page_writes only settable on server start?

2013-09-04 Thread Jeff Davis
On Wed, 2013-09-04 at 11:32 -0400, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: I think code complexity matters quite a lot. If we can eliminate some complex code in a complex area, and all we give up is a feature with essentially no use case, that sounds like we're moving

Re: [HACKERS] [9.4] Make full_page_writes only settable on server start?

2013-09-04 Thread Jeff Davis
On Wed, 2013-09-04 at 17:00 +0200, Andres Freund wrote: On 2013-09-04 07:57:15 -0700, Jeff Davis wrote: XLogSaveBufferForHint() calls XLogCheckBuffer() but doesn't also look at the full page writes setting (like in XLogInsert()). That means, if checksums are enabled and full_page_writes

Re: [HACKERS] Freezing without write I/O

2013-09-02 Thread Jeff Davis
also be cases where we can freeze more eagerly to avoid the case where very old (but unfrozen) and very new tuples mix on the same page. Perhaps Robert has some thoughts here, as well. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] ENABLE/DISABLE CONSTRAINT NAME

2013-09-02 Thread Jeff Davis
a certain order. And people usually like to insert the data but not affected by foreign keys or check. Is there any semantic difference between marking a constraint as DISABLED and simply dropping it? Or does it just make it easier to re-add it later? Regards, Jeff Davis -- Sent

[HACKERS] [9.4] Make full_page_writes only settable on server start?

2013-09-02 Thread Jeff Davis
. Any reason to keep the setting as a PGC_SIGHUP? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-07-21 Thread Jeff Davis
on vacation tomorrow and unfortunately I haven't had a chance to look at this. Pgfoundry CVS is down, so I can't see whether it's already been committed or not. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Re: Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-07-20 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-07-15 Thread Jeff Davis
On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote: I've attached a revised version that fixes the issues above: I'll get to this soon, sorry for the delay. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-15 Thread Jeff Davis
of this 'fest. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] mvcc catalo gsnapshots and TopTransactionContext

2013-07-11 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-07-08 Thread Jeff Davis
On Fri, 2013-07-05 at 22:43 -0700, Jeff Davis wrote: On Sat, 2013-07-06 at 10:30 +0900, Satoshi Nagayasu wrote: Hi, It looks fine, but I have one question here. When I run pg_filedump with -k against a database cluster which does not support checksums, pg_filedump produced checksum

Re: [HACKERS] Run-time posix_fallocate failures

2013-07-06 Thread Jeff Davis
doesn't provide support: Thank you. I think you'd better rejigger that patch so that it falls through to the old implementation if posix_fallocate() fails. Do you mean fails at all or fails with EINVAL? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-07-05 Thread Jeff Davis
for commit. What do you think? Regards, Jeff Davis [1] workstation specs (ubuntu 12.10, ext4): $ uname -a Linux jdavis 3.5.0-34-generic #55-Ubuntu SMP Thu Jun 6 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux #include fcntl.h #include stdio.h #include unistd.h char buf[8192] = {0}; int

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-07-05 Thread Jeff Davis
be included somewhere in the source tree? I don't think that's necessary, the fact that it's in the mailing list archives is enough. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-05 Thread Jeff Davis
On Tue, 2013-07-02 at 10:12 -0700, Jeff Davis wrote: Regardless, this is at least a concrete issue that I can focus on, and I appreciate that. Are scans of small tables the primary objection to this patch, or are there others? If I solve it, will this patch make real progress? I had an idea

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-07-05 Thread Jeff Davis
to be large, and IGNORE NULLS. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-07-05 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-07-05 Thread Jeff Davis
to be a little careful that any other code knows that names can be duplicated in the list though. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-07-05 Thread Jeff Davis
you for taking a look. That is expected, because there is not a good way to determine whether the file was created with checksums or not. So, we rely on the user to supply (or not) the -k flag. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-02 Thread Jeff Davis
appreciate that. Are scans of small tables the primary objection to this patch, or are there others? If I solve it, will this patch make real progress? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-02 Thread Jeff Davis
eliminate the freeze I/O with Heikki's proposal, and eliminate the PD_ALL_VISIBLE I/O with my patch. But, that's easier said than done. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-07-01 Thread Jeff Davis
? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-07-01 Thread Jeff Davis
would be quite surprised if that was the case, however. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-01 Thread Jeff Davis
a data load. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-07-01 Thread Jeff Davis
. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-01 Thread Jeff Davis
point me to that criticism? Why can't you just drop the VM completely if it becomes corrupted? (You might be referring to another idea of mine that was related to Andres's proposal for getting rid of freezing.) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-01 Thread Jeff Davis
is in conflict. (Not that it's necessarily wrong to do so, but I'm sure you can see how that is frustrating.) I'll see if I can help out with Heikki's patch. If it starts to look like it's going to make it, will you drop this particular objection? Regards, Jeff Davis -- Sent via pgsql-hackers

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

2013-07-01 Thread Jeff Davis
? Preferably in a form that could be tested on a 64-core box; but at least some kind of analysis involving numbers. More page accesses is scary, but completely meaningless without saying how *many* more and in which situations. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-06-30 Thread Jeff Davis
-a Linux jdavis 3.5.0-34-generic #55-Ubuntu SMP Thu Jun 6 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Regards, Jeff Davis #include fcntl.h char buf[8192] = {0}; int main() { int i; int fda = open(/tmp/afile, O_CREAT | O_EXCL | O_WRONLY, 0600); int fdb = open(/tmp/bfile, O_CREAT

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-06-30 Thread Jeff Davis
://www.postgresql.org/message-id/1372615313.19747.13.camel@jdavis Unless something surprising comes up, or someone thinks and objection has been missed, I am going to commit this soon. (Of course, to avoid your wrath, I'll get rid of the GUC which was added for testing.) Regards, Jeff Davis

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-06-30 Thread Jeff Davis
On Sun, 2013-06-30 at 11:11 -0700, Jeff Davis wrote: Unless something surprising comes up, or someone thinks and objection has been missed, I am going to commit this soon. Quick question to anyone who happens to know: What is the standard procedure for changes to pg_config.h.win32? I looked

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-06-29 Thread Jeff Davis
orthogonal I was going to submit it as a separate patch. Sounds good. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-06-28 Thread Jeff Davis
pg_basebackup extension... +1 Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-06-26 Thread Jeff Davis
one? Regards, Jeff Davis Only in pg_filedump.checksums/: .deps Only in pg_filedump.checksums/: pg_filedump diff -rc pg_filedump/pg_filedump.c pg_filedump.checksums/pg_filedump.c *** pg_filedump/pg_filedump.c 2013-06-06 11:33:17.0 -0700 --- pg_filedump.checksums/pg_filedump.c 2013

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-06-25 Thread Jeff Davis
-9.2.0.tar.gz release), and conflicts in several places with cvs tip. Oh, thank you. After browsing the CVS repo failed, I just made the diff against 9.2.0. I'll rebase it. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-06-21 Thread Jeff Davis
would have to be constant (or, if not, it would be quite strange). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

2013-06-20 Thread Jeff Davis
on those tests? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-06-20 Thread Jeff Davis
about first_value() and last_value()? Shouldn't we do those at the same time? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

2013-06-18 Thread Jeff Davis
change. I'm not sure what the resolution of Alvaro's concern was, so I left the flag reporting the same as the previous patch. Regards, Jeff Davis Common subdirectories: pg_filedump-9.2.0/.deps and pg_filedump-9.3.0j/.deps diff -Nc pg_filedump-9.2.0/Makefile pg_filedump-9.3.0j/Makefile

Re: [HACKERS] Patch for fail-back without fresh backup

2013-06-15 Thread Jeff Davis
there. Done. Btw, if you touch that code, I'd vote for renaming XLOG_HINT to XLOG_FPI or something like that. I find the former name confusing... Also done. Patch attached. Also, since we branched, I think this should be back-patched to 9.3 as well. Regards, Jeff Davis *** a/src/backend

Re: [HACKERS] Request for Patch Feedback: Lag Lead Window Functions Can Ignore Nulls

2013-06-15 Thread Jeff Davis
works with const_offset=true... so the previous idea might be better. I'll leave it to someone else to review the grammar changes. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

<    1   2   3   4   5   6   7   8   9   10   >