Re: [HACKERS] Final(?) proposal for wal_sync_method changes

x...@thebuild.com (Christophe Pettus) writes: > On Dec 7, 2010, at 2:43 PM, Josh Berkus wrote: >> Because nobody sane uses OSX on the server? > > The XServe running 10.5 server and 9.0.1 at the other end of the > office takes your remark personally. :) I'd heard that Apple had cancelled XServe. [

Re: [HACKERS] unlogged tables

t...@sss.pgh.pa.us (Tom Lane) writes: > "Kevin Grittner" writes: >> Robert Haas wrote: >>> Simon Riggs wrote: Note that DB2 uses the table modifier VOLATILE to indicate a table that has a widely fluctuating table size, for example a queue table. > >>> the fact that DB2 uses that

Re: [HACKERS] would hw acceleration help postgres (databases in general) ?

j...@nasby.net (Jim Nasby) writes: > On Dec 10, 2010, at 6:18 PM, Jeff Janes wrote: >> On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail wrote: >>> >>> Hello hackers, >>> >>> I think i'm at the right place to ask this question. >>> >>> Based on your experience and the fact that you have written

Re: [HACKERS] Anyone for SSDs?

loureir...@gmail.com (Daniel Loureiro) writes: >> You can believe whatever you want, that doesn't make it true. > completely agree. Like yours, Its just my point of view, not the reality. > > I agree with some points here, but I wondering how many good ideas are > killed with the thought: "this wil

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

t...@sss.pgh.pa.us (Tom Lane) writes: > Robert Haas writes: >> ... On the >> other hand, there's clearly also a use case for this behavior. If a >> bulk load of prevalidated data forces an expensive revalidation of >> constraints that are already known to hold, there's a real chance the >> DBA w

Re: [HACKERS] psql expanded auto

pete...@gmx.net (Peter Eisentraut) writes: > I have often found myself wanting that psql automatically switch between > normal and \x mode depending on the width of the output. Would others > find this useful? I haven't tested the patch, but that *does* sound generally useful. It's no fun trying

Re: [HACKERS] C++ keywords in headers

pete...@gmx.net (Peter Eisentraut) writes: > On mån, 2010-12-27 at 12:33 -0500, Andrew Dunstan wrote: >> On a more general point, it would be useful to have some >> infrastructure for running quality checks like this and publishing >> the results. We should be way beyond the point where we rely on

Re: [HACKERS] [COMMITTERS] pgsql: Implement remaining fields of information_schema.sequences view

pete...@gmx.net (Peter Eisentraut) writes: > Implement remaining fields of information_schema.sequences view > > Add new function pg_sequence_parameters that returns a sequence's start, > minimum, maximum, increment, and cycle values, and use that in the view. > (bug #5662; design suggestion by Tom

[HACKERS] Review: compact fsync request queue on overflow

I have been taking a peek at the following commitfest item: https://commitfest.postgresql.org/action/patch_view?id=497 Submission: - I had to trim a little off the end of the patch to apply it, but that's likely the fault of how I cut'n'pasted it. It applied cleanly against HEAD. - I obse

Re: [HACKERS] Review: compact fsync request queue on overflow

robertmh...@gmail.com (Robert Haas) writes: > On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith wrote: >> Quite.  It's taken me 12 days of machine time running pgbench to find the >> spots where this problem occurs on a system with a reasonably sized >> shared_buffers (I'm testing against 256MB).  It's

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

si...@2ndquadrant.com (Simon Riggs) writes: > I just wanted to point out that the patch submitted here does not allow > what is requested here for FKs (nor indexes). That's fine; I was trying to support the thought that there was something useful about this idea. Being able to expressly deactivat

Re: [HACKERS] Confusion over Python drivers

kevina...@hotmail.com (Kevin Ar18) writes: > Of course all of this is from the perspective of Python users. Of > course, you have your own features that you want from your end (from > PostgreSQL's perspective). Perhaps this info would help you to know > which avenue to pursue. No, those seem lik

Re: [HACKERS] OpenVMS?

rocr...@gmx.de (Robert Doerfler) writes: > On Tue, 16 Feb 2010, Bruce Momjian wrote: > >> Marc G. Fournier wrote: >>> On Tue, 16 Feb 2010, Bruce Momjian wrote: >>> I hate to pour cold water on this, but why is it worth adding support for a platform that has such marginal usage. >>> >>> Be

Re: [HACKERS] OpenVMS?

scra...@hub.org ("Marc G. Fournier") writes: > On Tue, 16 Feb 2010, Bruce Momjian wrote: > >> I hate to pour cold water on this, but why is it worth adding >> support for a platform that has such marginal usage. > > Because someone feels like dedicating their resources to it ... ? But adding it in

Re: [HACKERS] LISTEN/NOTIFY and notification timing guarantees

t...@sss.pgh.pa.us (Tom Lane) writes: > Merlin Moncure writes: >> On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane wrote: >>> 2. Add an extra lock to serialize writers to the queue, so that messages >>> are guaranteed to be added to the queue in commit order.  As long as > >> fwiw, I think you're defin

Re: [HACKERS] Anyone know if Alvaro is OK?

scrawf...@pinpointresearch.com (Steve Crawford) writes: > Marc G. Fournier wrote: >> >> Is there a higher then normal amount of earthquakes happening >> recently? haiti, japan just had one for 6.9, there was apparently >> one in illinos a few weeks back, one on the Russia/China/N.Korean >> border a

Re: [HACKERS] SQL compatibility reminder: MySQL vs PostgreSQL

francois.pe...@free.fr (François Pérou) writes: > * I am very surprised by the SQL level of Php developers. The example > Drupal developers trying to rewrite SQL queries dynamically adding > DISTINCT clause is just an example. So don't expect them to understand > the difference between MySQL and Po

Re: [HACKERS] An idle thought

si...@2ndquadrant.com (Simon Riggs) writes: > On Tue, 2010-03-16 at 15:29 +, Greg Stark wrote: > >> big batch delete > > Is one of the reasons for partitioning, allowing the use of truncate. Sure, but it would be even nicer if DELETE could be thus made cheaper without needing to interfere with

Re: [HACKERS] Proposal: Add JSON support

joeyadams3.14...@gmail.com (Joseph Adams) writes: > I introduced myself in the thread "Proposal: access control jails (and > introduction as aspiring GSoC student)", and we discussed jails and > session-local variables. But, as Robert Haas suggested, implementing > variable support in the backend

Re: [HACKERS] Proposal: Add JSON support

robertmh...@gmail.com (Robert Haas) writes: > On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus wrote: >>> I'd think that you could get quite a long ways on this, at least doing >>> something like dbslayer without *necessarily* needing to do terribly >>> much work inside the DB engine. >> >> There's ac

Re: [HACKERS] Add column if not exists (CINE)

robertmh...@gmail.com (Robert Haas) writes: > On Wed, Apr 28, 2010 at 1:40 PM, Dimitri Fontaine > wrote: >> Robert Haas writes: >>> Well, how would you define CREATE OR REPLACE TABLE?  I think that >>> doesn't make much sense, which is why I think CREATE IF NOT EXISTS is >>> a reasonable approach

Re: [HACKERS] Caution when removing git branches

and...@dunslane.net (Andrew Dunstan) writes: > On 01/27/2011 11:29 AM, Tom Lane wrote: >> Given that nobody is supposed to push temporary branches to the master >> repo anyway, an intended branch removal should be a pretty darn rare >> event. Now, our committers all seem to be pretty careful peopl

Re: [HACKERS] WIP: RangeTypes

pg...@j-davis.com (Jeff Davis) writes: > On Fri, 2011-01-28 at 09:17 -0800, David Fetter wrote: >> For consistency, and in order not to continue our atrocious naming >> tradition, I'd like to propose that the above be named timestamprange >> (tsrange for short) and timestamptzrange (tstzrange for

Re: [HACKERS] OpenVMS - an effort which needs guidance and support.

peder...@ccsscorp.com ("Bill Pedersen") writes: > I look forward to hearing from people in the PostgreSQL community as well as > from others interested in this effort. To a number of us, it's academically interesting, though, as we don't have VMS systems, it's not likely to be super-easy to assist

Re: [HACKERS] Sync Rep for 2011CF1

dp...@pgadmin.org (Dave Page) writes: > On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote: >> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote: >>> Robert Haas writes: ... Well, the current CommitFest ends in one week, ... >>> >>> Really?  I thought the idea for the last CF of a development

Re: [HACKERS] postponing some large patches to 9.2

sfr...@snowman.net (Stephen Frost) writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> - Range Types. This is a large patch which was submitted for the >> first time to the last CommitFest of the cycle, and the first version >> that had no open TODO items was posted yesterday, three-quarters

Re: [HACKERS] postponing some large patches to 9.2

pg...@j-davis.com (Jeff Davis) writes: > On Tue, 2011-02-08 at 06:57 -0500, Stephen Frost wrote: >> * Robert Haas (robertmh...@gmail.com) wrote: >> > - Range Types. This is a large patch which was submitted for the >> > first time to the last CommitFest of the cycle, and the first version >> > tha

Re: [HACKERS] postponing some large patches to 9.2

pg...@j-davis.com (Jeff Davis) writes: > On Tue, 2011-02-08 at 15:10 -0500, Chris Browne wrote: >> It's more than a bit sad... The RangeType change has the massive merit >> of enabling some substantial development changes, where we can get rid >> of whole classes

[HACKERS] Range Types - efficiency

One of the things I'd particularly like to use range types for is to make it easier to construct range-related queries. Classic example is that of reports that work on date ranges. I create a table that will have transaction data: CREATE TABLE some_data ( id serial, whensit date -- A

Re: [HACKERS] Range Types - efficiency

pg...@j-davis.com (Jeff Davis) writes: > On Wed, 2011-02-09 at 16:20 -0500, Chris Browne wrote: >> rangetest@localhost-> explain analyze select * from some_data where >> '[2010-01-01,2010-02-01)'::daterange @> whensit; >>

Re: [HACKERS] why two dashes in extension load files

t...@sss.pgh.pa.us (Tom Lane) writes: > Peter Eisentraut writes: >> On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote: >>> Peter Eisentraut writes: Why do the extension load files need two dashes, like xml2--1.0.sql? Why isn't one enough? > >>> Because we'd have to forbid dashes in exte

Re: [HACKERS] CommitFest 2011-01 as of 2011-02-04

robertmh...@gmail.com (Robert Haas) writes: > It does, but frankly I don't see much reason to change it, since it's > been working pretty well on the whole. Andrew was on point when he > mentioned that it's not obvious what committers get out of working on > other people's patches. Obviously, the

Re: [HACKERS] Re: Why our counters need to be time-based WAS: WIP: cross column correlation ...

j...@agliodbs.com (Josh Berkus) writes: >> I don't understand what you're talking about at all here. I think >> there are a lot of unsolved problems in monitoring but the one thing >> I think everyone is pretty clear on is that the right way to export >> metrics like these is to export a counter an

Re: [HACKERS] Testing extension upgrade scripts

da...@kineticode.com ("David E. Wheeler") writes: > You should blog this. He just did, using the SMTP protocol... -- select 'cbbrowne' || '@' || 'acm.org'; http://linuxdatabases.info/info/postgresql.html Where do you want to Tell Microsoft To Go Today? -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] Exposing the Xact commit order to the user

d...@csail.mit.edu (Dan Ports) writes: > I'm not clear on why the total rowcount is useful, but perhaps I'm > missing something obvious. It would make it easy to conclude: "This next transaction did 8328194 updates. Maybe we should do some kind of checkpoint (e.g. - commit transaction or s

Re: [HACKERS] Exposing the Xact commit order to the user

heikki.linnakan...@enterprisedb.com (Heikki Linnakangas) writes: > On 24/05/10 19:51, Kevin Grittner wrote: >> The only thing I'm confused about is what benefit anyone expects to >> get from looking at data between commits in some way other than our >> current snapshot mechanism. Can someone expla

Re: [HACKERS] Exposing the Xact commit order to the user

br...@momjian.us (Bruce Momjian) writes: > Jan Wieck wrote: >> The point is not that we don't have that information now. The point is >> having a hint BEFORE wading through possibly gigabytes of WAL or log data. >> >> If getting that information requires to read all the log data twice or >> the

Re: [HACKERS] Exposing the Xact commit order to the user

gsst...@mit.edu (Greg Stark) writes: > On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne wrote: >> It would make it easy to conclude: >> >>   "This next transaction did 8328194 updates.  Maybe we should do >>   some kind of checkpoint (e.g. - commit transaction or

Re: [HACKERS] Check constraints on non-immutable keys

mag...@hagander.net (Magnus Hagander) writes: >> I concur with the thought that the most useful solution might be a way >> to tell pg_restore to remove or disable check constraints. > > Uh, say what? Are you saying pg_restore should actually remove > something from the database schema? And thus no

[HACKERS] Buildfarm + Git tryouts

I'm trying to start preparing buildfarm nodes for the upcoming Git migration, and have run into a few issues. I speculate that -hackers is one of the better places for this to get discussed; if it should be elsewhere, I'm sure Andrew Dunstan won't be shy to redirect this :-). What I was hoping to

Re: [HACKERS] SHOW TABLES

si...@2ndquadrant.com (Simon Riggs) writes: > Just for the record, I've never ever met anyone that said "Oh, this > \d syntax makes so much sense. I'm a real convert to Postgres now > you've shown me this". The reaction is always the opposite one; > always negative. Which detracts from our efforts

Re: [HACKERS] Concurrent MERGE

robertmh...@gmail.com (Robert Haas) writes: > On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs wrote: >> Looks like MERGE is progressing well. >> >> At 2010 Dev Mtg, we put me down to work on making merge work >> concurrently. That was garbled slightly and had me down as working on >> predicate lockin

Re: [HACKERS] Two different methods of sneaking non-immutable data into an index

mmonc...@gmail.com (Merlin Moncure) writes: > On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote: >> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote: >>> *) also, isn't it possible to change text cast influencing GUCs 'n' >>> times per statement considering any query can call a function and a

Re: [HACKERS] Two different methods of sneaking non-immutable data into an index

mmonc...@gmail.com (Merlin Moncure) writes: > On Thu, Aug 5, 2010 at 12:59 PM, Chris Browne wrote: >> mmonc...@gmail.com (Merlin Moncure) writes: >>> On Wed, Aug 4, 2010 at 9:31 PM, Robert Haas wrote: >>>> On Wed, Aug 4, 2010 at 6:43 PM, Merlin Moncure wrote: >&

[HACKERS] TOASTing smaller things

In some of our applications, we have cases where it would be very nice if we could activate TOAST at some sort of lower threshold than the usual 2K that is true now. Let me note the current code that controls the threshold: /* * These symbols control toaster activation. If a tuple is larger tha

Re: [HACKERS] TOASTing smaller things

[EMAIL PROTECTED] (Tom Lane) writes: > Chris Browne <[EMAIL PROTECTED]> writes: >> #define TOAST_DENOMINATOR 17 >>/* Use this as the divisor; current default behaviour falls from >> TOAST_DENOMINATOR = 4 */ > >> #define TOAST_TUPLE_THRESHOLD^I\ >&g

Re: [HACKERS] TOASTing smaller things

[EMAIL PROTECTED] ("Luke Lonergan") writes: > Andreas, > > On 3/22/07 9:40 AM, "Andreas Pflug" <[EMAIL PROTECTED]> wrote: > >> Wouldn't it be enough to enable having the toast table on a different >> table space? > > Yes, but the ultimate goal would allow the allocation of a storage mechanism > tha

Re: [HACKERS] Modifying TOAST thresholds

[EMAIL PROTECTED] (Tom Lane) writes: > "Simon Riggs" <[EMAIL PROTECTED]> writes: >> Well it certainly seems worth separating them. It does seem possible >> that recursive toasting effected some of the earlier results we looked >> at. > >> Would you like me to do this, or will you? > > I'm willing t

Re: [HACKERS] Modifying TOAST thresholds

[EMAIL PROTECTED] (Tom Lane) writes: > Chris Browne <[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] (Tom Lane) writes: >>> ... tuning the TOAST parameters seems like >>> something we understand well enough already, we just need to put some >>> cycles int

Re: [HACKERS] Modifying TOAST thresholds

[EMAIL PROTECTED] (Tom Lane) writes: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> The big question is whether this is for 8.3 or 8.4. > > What I would definitely like to see for 8.3 is some performance testing > done to determine whether we ought to change the current defaults. > (Both TOAST_TUPL

Re: [HACKERS] What X86/X64 OS's do we need coverage for?

ler@lerctr.org ("Larry Rosenman") writes: > I might use that as the base then, since the hardware finishes getting here > tomorrow. > > My question still stands on what OS's we need coverage for. I've got Debian testing/unstable covered. I'm not sure we have Novell/SuSE covered... -- output = ("

Re: [HACKERS] Hacking on PostgreSQL via GIT

[EMAIL PROTECTED] ("Florian G. Pflug") writes: > Martin Langhoff wrote: >> Hi Florian, >> I am right now running an rsync of the Pg CVS repo to my work >> machine to >> get a git import underway. I'm rather keen on seeing your cool PITR Pg >> project go well and I have some git+cvs fu I can apply h

Re: [HACKERS] Hacking on PostgreSQL via GIT

[EMAIL PROTECTED] (Aidan Van Dyk) writes: > I've "diffed" a CVS checkout and a git checkout, and the are *almost* > identical. Almost, because it seems like my git repository currently has 3 > files that a cvs checkout doesn't: > backend/parser/gram.c |12088 ++

Re: [HACKERS] Modifying TOAST thresholds

[EMAIL PROTECTED] (Bruce Momjian) writes: > I have seen no one do peroformance testing of this, so it seems it > will have to wait for 8.4. I didn't have time... I'll see if I can find a decent place to document how to tweak the threshold, as that seems like it could be worth doing in cases where

Re: [HACKERS] Modifying TOAST thresholds

[EMAIL PROTECTED] (Tom Lane) writes: > Chris Browne <[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] (Bruce Momjian) writes: >>> I have seen no one do peroformance testing of this, so it seems it >>> will have to wait for 8.4. > >> I didn't have time.

Re: [HACKERS] Feature freeze progress report

[EMAIL PROTECTED] (Marc Munro) writes: > On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote: >> Date: Mon, 30 Apr 2007 09:18:36 +0100 >> From: Heikki Linnakangas <[EMAIL PROTECTED]> >> To: Tom Lane <[EMAIL PROTECTED]> >> Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs >> <[EMAIL PROTEC

Re: [HACKERS] Feature freeze progress report

[EMAIL PROTECTED] (Andrew Dunstan) writes: > Tom Lane wrote: >> So in a roundabout way we come back >> to the idea that we need a bug tracker (NOT a patch tracker), plus >> people putting in the effort to make sure it stays a valid source >> of up-to-date info. Without the latter it won't really b

Re: [HACKERS] Not ready for 8.3

[EMAIL PROTECTED] (Josh Berkus) writes: > Bruce, > > Realistically I just don't see getting everything in the ToDo patch > list in; my vote is that we start deferring stuff for 8.4 if it > doesn't have a reviewer, except for items which were submitted early > in the cycle (and to whom it would be u

Re: [HACKERS] Not ready for 8.3

[EMAIL PROTECTED] (Aidan Van Dyk) writes: > * Tatsuo Ishii <[EMAIL PROTECTED]> [070516 07:23]: > >> Maybe. However I think "subject-sequence" has some advantages over >> Message-Id: >> >> - Easy to identify. Message-Id may not appear on some MUA with default >> setting >> >> - More handy than

Re: [HACKERS] TOAST usage setting

[EMAIL PROTECTED] (Bruce Momjian) writes: > The results are here: > > http://momjian.us/expire/TOAST/ I'll take a look and see if there's anything further it makes sense for me to try testing. Thanks for following up so quickly; what with the cold I have had, I haven't yet gotten back to th

[HACKERS] PG-MQ?

I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." The "granddaddy" of message queuing systems is IBM's MQ-Series, and I don't see particular value in replicating its fu

Re: [HACKERS] PG-MQ?

[EMAIL PROTECTED] (Steve Atkins) writes: >> Is there any existing work out there on this? Or should I maybe be >> looking at prototyping something? > > The skype tools have some sort of decent-looking publish/subscribe > thing, PgQ, then they layer their replication on top of. It's multi > consume

Re: [HACKERS] PG-MQ?

[EMAIL PROTECTED] ("Marko Kreen") writes: > To Chris: you should like PgQ, its just stored procs in database, > plus it's basically just generalized Slony-I, with some optimizations, > so should be familiar territory ;) Looks interesting... Random ideas - insert_event in C (way to ge

Re: [HACKERS] 2PC-induced lockup

[EMAIL PROTECTED] writes: > On Wed, Jul 11, 2007 at 12:38:09AM -0400, Tom Lane wrote: >> [EMAIL PROTECTED] writes: > [...] >> > It might make sense then to clear the pg_twophase directory on DB >> > startup. >> >> I fear you have 100% misunderstood the point. The *only* >> reason for that featu

Re: [HACKERS] compiler warnings on the buildfarm

[EMAIL PROTECTED] (Stefan Kaltenbrunner) writes: > Tom Lane wrote: > [...] >>> animal: clownfish warnings: 12 >>> "dynloader.c", line 4: warning: empty translation unit >>> "postgres.c", line 3758: warning: loop not entered at top >> >> The first of these is not a bug, the second seems

Re: [HACKERS] Future of krb5 authentication

[EMAIL PROTECTED] (Peter Eisentraut) writes: > Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander: >> The main reasons would be to have less code to maintain, > > I don't think the krb5 support has needed all that much maintenance in the > last few years. > >> and to make life >> easier for

[HACKERS] Index Tuple Compression Approach?

I recently had a chat with someone who was pretty intimate with Adabas for a number of years who's in the process of figuring things out about PostgreSQL. We poked at bits of the respective implementations, seeing some similarities and differences. He pointed out one aspect of index handling that

Re: [HACKERS] Index Tuple Compression Approach?

[EMAIL PROTECTED] ("Dawid Kuroczko") writes: > On 8/14/07, Chris Browne <[EMAIL PROTECTED]> wrote: >> I recently had a chat with someone who was pretty intimate with Adabas >> for a number of years who's in the process of figuring things out >> about Postg

Re: [HACKERS] Index Tuple Compression Approach?

[EMAIL PROTECTED] (Gregory Stark) writes: > "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > >> Gregory Stark wrote: >>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: >>> That general approach of storing a common part leading part just once is called prefix compression. Yeah, it he

[HACKERS] TOAST Threshold? Re: Status of 8.3 patches

[EMAIL PROTECTED] ("Joshua D. Drake") writes: > Alvaro Herrera wrote: >> Joshua D. Drake wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Heikki Linnakangas wrote: Joshua D. Drake wrote: > >>> I guess my point is, if the patch looks good and does not appear >>> to hurt anyt

Re: [HACKERS] tsearch2 patch status report

[EMAIL PROTECTED] (Tom Lane) writes: > The main thing that is lacking at the moment is documentation. The > stuff Bruce has been working on will be good introductory material, > but we've got basically zip in reference material. I'll do some work > on that over the next couple of days, but there'

Re: [HACKERS] terms for database replication: synchronous vs eager

[EMAIL PROTECTED] (Jan Wieck) writes: > On 9/7/2007 11:01 AM, Markus Schiltknecht wrote: >> None the less, Postgres-R is eager (or pessimistic?) in the sense >> that it replicates *before* committing, so as to avoid >> divergence. In [1] I've tried to make that distinction clear, and >> I'm current

Re: [HACKERS] Getting to 8.3 beta1

[EMAIL PROTECTED] (Teodor Sigaev) writes: >> * Draft release notes --- can't really ship a beta without these, >> else beta testers won't know what to test. Traditionally this has >> taken a fair amount of time, but I wonder whether we couldn't use >> http://developer.postgresql.org/index.php/What

Re: [HACKERS] 8.3 beta timing

[EMAIL PROTECTED] (Bruce Momjian) writes: > I think we need another week to get things ready for beta. I will have > the release notes done mid-week and hopefully we can close out all open > items by the end of the week. It's worth noting that Greg Smith has collected release note information int

Re: [HACKERS] some points for FAQ

[EMAIL PROTECTED] (Alvaro Herrera) writes: > Pavel Stehule escribió: > >> p.s. can we create some general F.A.Q XML format and store FAQ there? >> >> WIP Proposal: >> >> >> >> >> >> ... >> we need some tags from html: > > There is a DocBook spec for FAQ lists. Actually a friend

Re: [HACKERS] Feature Freeze date for 8.4

[EMAIL PROTECTED] (Josh Berkus) writes: > Simon, > >> We can issue a provisional date. We could also say "at least 6 months >> after release date of 8.3". I'm sure there's other options too. > > I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short* > release so that we could m

Re: [HACKERS] Feature Freeze date for 8.4

[EMAIL PROTECTED] (Tom Lane) writes: > Simon Riggs <[EMAIL PROTECTED]> writes: >> I'd suggest we have multiple checkpoints during the cycle. Checkpoint is >> a "patch queue blitz" where we stop developing and reduce the queue to >> nothing. Perhaps a two-week period where everybody helps reduce the

Re: [HACKERS] psql show dbsize?

[EMAIL PROTECTED] (Tom Lane) writes: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Perhaps both these considerations dictate providing another command or a >> special flavor of \l instead of just modifying it? > > I've seen no argument made why \l should print this info at all. Its interesting

Re: [HACKERS] proposal, plpgsql, 8.4, for record in cursor

[EMAIL PROTECTED] (Peter Eisentraut) writes: > Am Montag, 26. November 2007 schrieb Tom Lane: >> "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> > I propose new kind of FOR statement .. iteration over cursor, >> >> This seems useless and probably syntactically ambiguous. > > I think that is isomorph

Re: [HACKERS] Dynamic Partitioning using Segment Visibility Maps

[EMAIL PROTECTED] (Simon Riggs) writes: > I think we have an opportunity to bypass the legacy-of-thought that > Oracle has left us and implement something more usable. This seems like a *very* good thing to me, from a couple of perspectives. 1. I think you're right on in terms of the issue of th

Re: [HACKERS] Named vs Unnamed Partitions

[EMAIL PROTECTED] (Markus Schiltknecht) writes: > Simon Riggs wrote: >> With that in mind, can I clarify what you're thinking, please? > > Sure, I can try to clarify: > >> 2) the things you've been discussing are essential requirements of >> partitioning and we could never consider it complete unti

Re: [HACKERS] Dynamic Partitioning using Segment Visibility Maps

Ron Mayer <[EMAIL PROTECTED]> writes: > Chris Browne wrote: >> _On The Other Hand_, there will be attributes that are *NOT* set in a >> more-or-less chronological order, and Segment Exclusion will be pretty >> useless for these attributes. > > Really?I was h

Re: [HACKERS] Transaction Snapshot Cloning

[EMAIL PROTECTED] (Simon Riggs) writes: > On Fri, 2008-01-11 at 20:39 +, Simon Riggs wrote: >> On Fri, 2008-01-11 at 15:05 -0500, Tom Lane wrote: >> Simon Riggs <[EMAIL PROTECTED]> writes: >> > > If we had a function >> > > replace_serializable_snapshot(master_xid, txid_snapshot) >> > > this

Re: [HACKERS] New PostgreSQL Committers

dp...@pgadmin.org (Dave Page) writes: > Congratulations! +1 Congratulations, indeed, to this worthy set of developers! -- output = reverse("moc.liamg" "@" "enworbbc") http://linuxfinances.info/info/multiplexor.html "Power tends to corrupt and absolute power corrupts absolutely." -- First Bar

Re: [HACKERS] Adding support for SE-Linux security

t...@sss.pgh.pa.us (Tom Lane) writes: > Robert Haas writes: >> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian wrote: >>> I wonder if we should rephrase this as, "How hard will this feature be >>> to add, and how hard will it be to remove in a few years if we decide we >>> don't want it?" > >> Yes,

[HACKERS] Has anyone used CLANG yet?

This is a C front end for the LLVM compiler... I noticed that it entered Debian/Unstable today: http://packages.debian.org/sid/main/clang I thought it would be interesting to see if PostgreSQL compiles with this, as an alternative compiler that should presumably become more and more available

Re: [HACKERS] Has anyone used CLANG yet?

age...@themactionfaction.com ("A.M.") writes: [Much of interest elided... Cool to see that clang clearly *can* compile PostgreSQL...] > You are probably running configure with gcc, no? I was *attempting* to run configure using clang: CC=/usr/bin/clang ./configure --prefix=/home/chris/dbs/pos

Re: [HACKERS] Thoughts on statistics for continuously advancing columns

j...@commandprompt.com ("Joshua D. Drake") writes: > On the other hand ANALYZE also: > > 1. Uses lots of memory > 2. Lots of processor > 3. Can take a long time > > We normally don't notice because most sets won't incur a penalty. We got a > customer who > has a single table that is over 1TB in siz

Re: [HACKERS] RFC: PostgreSQL Add-On Network

robertmh...@gmail.com (Robert Haas) writes: > On Fri, Jan 8, 2010 at 10:12 AM, Dave Page wrote: >>> I have long spoken against making Windows a second class citizen. But I >>> don't think David is going to do that (and I'll hound him if he does). But >>> that doesn't mean it has to be fully suppor

Re: [HACKERS] Add .gitignore files to CVS?

bada...@gmail.com (Alex Hunsaker) writes: > On Fri, Jan 8, 2010 at 02:03, Magnus Hagander wrote: >> You can always create your own branch with just the .gitignore files >> and merge that into whatever you're working on :) > > The only thing annoying about that is if you generate diffs ala git > di

[HACKERS] Fast REVERSE() function?

I've got a case where I need to reverse strings, and find that, oddly enough, there isn't a C-based reverse() function. A search turns up pl/pgsql and SQL implementations: create or replace function reverse_string(text) returns text as $$ DECLARE reversed_string text; incoming alias for $1; BEGIN

Re: [HACKERS] Fast REVERSE() function?

[EMAIL PROTECTED] (hubert depesz lubaczewski) writes: > On Mon, Sep 08, 2008 at 11:20:18AM -0400, Chris Browne wrote: >> I've got a case where I need to reverse strings, and find that, oddly >> enough, there isn't a C-based reverse() function. >> A search turns up p

Re: [HACKERS] Transaction Snapshots and Hot Standby

[EMAIL PROTECTED] (Heikki Linnakangas) writes: > Simon Riggs wrote: >> Taking snapshots from primary has a few disadvantages >> >> ... >> * snapshots on primary prevent row removal (but this was also an >> advantage of this technique!) > > That makes it an awful solution for high ava

Re: [HACKERS] PostgreSQL future ideas

[EMAIL PROTECTED] ("Gevik Babakhani") writes: > It might look like an impossible goal to achieve.. But if there is > any serious plan/idea/ammo for this, I believe it would be very > beneficial to the continuity of PG. Actually, I imagine that such a rewrite would run a very considerable risk of i

Re: [HACKERS] pgsql: Make LC_COLLATE and LC_CTYPE database-level settings.

[EMAIL PROTECTED] (Heikki Linnakangas) writes: > Log Message: > --- > Make LC_COLLATE and LC_CTYPE database-level settings. Collation and > ctype are now more like encoding, stored in new datcollate and datctype > columns in pg_database. > > This is a stripped-down version of Radek Strnad'

Re: [HACKERS] PostgreSQL future ideas

[EMAIL PROTECTED] ("Gevik Babakhani") writes: >> Advantage of C++ is that it reduce lot of OO code written in >> C in PostgreSQL, but it is so big effort to do that without >> small gain. It will increase number of bugs. Do not forget >> also that C++ compiler is not so common (so good) on >> d

Re: [HACKERS] PostgreSQL future ideas

[EMAIL PROTECTED] (Andrew Dunstan) writes: > A.M. wrote: >> Speaking of language choice, no one said that _all_ the source code >> would need to be rewritten. It would be nice, for example, if >> PostgreSQL rewrote the current GUC system with a glue language like >> Lua (which is also very C-like).

Re: [HACKERS] PostgreSQL future ideas

[EMAIL PROTECTED] ("Jonah H. Harris") writes: > On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: >>> Speaking of language choice, no one said that _all_ the source code would >>> need to be rewritten. It would be nice, for example, if PostgreSQL rewrote >>> the current GU

Re: [HACKERS] SQL/MED compatible connection manager

[EMAIL PROTECTED] (Martin Pihlak) writes: > Tons of details have been omitted, but should be enough to start discussion. > What do you think, does this sound usable? Suggestions, objections? Slony-I does some vaguely similar stuff in its handling of "connection paths"; here's the schema: create

Re: [HACKERS] SQL5 budget

[EMAIL PROTECTED] ("Jonah H. Harris") writes: > On Sun, Nov 9, 2008 at 7:41 PM, Decibel! <[EMAIL PROTECTED]> wrote: >> I think you're barking up the wrong tree here; the community can't really do >> hacking for hire. If you want to pay for something to be implemented (which >> is great!), you'll ne

  1   2   3   >