[HACKERS] Index scan troubles

and opclass things, yet. Hints and pointers on where to read on greatly appreciated. A virtual beer for sample code. ;-) Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Index scan troubles

this for you or if you have to do it yourself. Search for other places where SK_ROW_HEADER appears. Ah, so the default for multiple ScanKeys is 'x const AND y const' and not the row comparison. That explains my troubles. Thanks a lot. Regards Markus Wanner -- Sent via pgsql-hackers mailing

Re: [HACKERS] Conflict resolution in Multimaster replication(Postgres-R)

or changesets or such. What kind of replication are you interested in? Regards Markus Wanner [1]: Terms and Definitions for Database Replication: http://www.postgres-r.org/documentation/terms -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Conflict resolution in Multimaster replication(Postgres-R)

nodes as well), it tells TB to abort and continues applying its own changes. I hope that was an understandable explanation. Regards Markus Wanner [1]: In the original Postgres-R paper, these are called writesets. But in my implementation, I've altered its meaning somewhat. Because

Re: [HACKERS] Debugging methods

. Then run the postmaster with '-A1 -d5' Regards Markus Wanner [1]: http://wiki.postgresql.org/wiki/Developer_FAQ -- 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] WIP: Column-level Privileges

as WIP on the wiki page: what needs to be done until you consider it done? Regards Markus Wanner [1]: Comments from Tom: http://archives.postgresql.org/pgsql-patches/2008-05/msg00111.php -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] WIP: Column-level Privileges

, dependency handling, and actually implementing the permission checks all remain. What I'm looking for feedback on are the changes to the grammer, parser, catalog changes, psql output, etc. Aha, good. So I'm going to (try to) check these things and comment. Regards Markus Wanner -- Sent via

Re: [HACKERS] Patch: propose to include 3 new functions into intarray and intagg

and bidx and the grouping/counting thing seem like they might be useful functionality. but I have a feeling others might feel differently. The naming 'bidx' seems a bit weired to me, but otherwise I'm also optimistic about it. Regards Markus Wanner -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Patch: propose to include 3 new functions into intarray and intagg

take care about ordering myself. But still want to maintain the optimization. However, that's probably not within the scope of this patch. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Patch: propose to include 3 new functions into intarray and intagg

://archives.postgresql.org/pgsql-hackers/2007-08/msg00464.php Regards Markus Wanner -- 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] Need more reviewers!

for *patch submitters* helps with that. There must be other ways to convince managers to encourage reviewers. Regards Markus Wanner -- 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] Need more reviewers!

with this argument, sorry. Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

want hooks for. If additional processes get integrated into Postgres, those certainly need to get integrated very much like we integrated other auxiliary processes. I wouldn't call that 'hooking', but YMMV. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] Review Report: propose to include 3 new functions into intarray and intagg

, can you please apply these small corrections and re-submit the patch? Regards Markus Wanner P.S.: I dislike the intagg's use of PGARRAY, but that's nothing to do with this patch. Shouldn't this better use a real composite type as the aggregate's state type? I'd propose to clean up

Re: [HACKERS] Review Report: propose to include 3 new functions into intarray and intagg

. But, what about intarray patch? Does somebody plan to review it? I'd prefer to include it too. If you approve, I'll correct the code style in intarray contrib patch too. I've already volunteered for reviewing it as well. I just felt like splitting things up... Regards Markus Wanner

Re: [HACKERS] Synchronous Log Shipping Replication

, that hasn't been proved, yet. I guess we could invent a new semaphore-like primitive at the same layer as LWLocks using spinlock and PGPROC directly... Sure, but in what way would that differ from what I do with imessages? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Synchronous Log Shipping Replication

be improved WRT efficiency and could theoretically even beat Unix pipes, because it involves less copying of data and less syscalls. It has not been reviewed nor commented much. I'd still appreciate that. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Synchronous Log Shipping Replication

for a working implementation of such a process using select() and signaling. Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

. That sounds like WAL needs to be written to disk, before it can be sent to the standby. Except maybe with some sort of mmap'ing the WAL. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Synchronous Log Shipping Replication

possibly having similar IPC requirements, group commit and log shipping have not much in common and should be considered separate features. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Synchronous Log Shipping Replication

in case the link to the standby comes up again? How about multiple standby servers? Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

on the local node, as we do now. These are two different things to wait for. One is a network socket operation, the other is an fsync(). As these don't work together too well (blocking), you better run that in two different processes. Regards Markus Wanner -- Sent via pgsql-hackers mailing

Re: [HACKERS] Synchronous Log Shipping Replication

Hi, ITAGAKI Takahiro wrote: Signals and locking, borrewed from Postgres-R, are now studied for the purpose in the log shipping, Cool. Let me know if you have any questions WRT this imessages stuff. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Synchronous Log Shipping Replication

servers, i.e. where there is no WAL sender process. Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

? Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

on the active. Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

Hi, Fujii Masao wrote: On Tue, Sep 9, 2008 at 10:55 PM, Markus Wanner [EMAIL PROTECTED] wrote: Hi, ITAGAKI Takahiro wrote: Signals and locking, borrewed from Postgres-R, are now studied for the purpose in the log shipping, Cool. Let me know if you have any questions WRT this imessages stuff

Re: [HACKERS] Synchronous Log Shipping Replication

for the notification *from backends to WAL sender*, I think too. ..and I'd say you better use the same for WAL sender to backend communication, just for the sake of simplicity (and thus maintainability). Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Synchronous Log Shipping Replication

cases within Postgres itself as of now? Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

sent from other backends, it'd be sufficient to put a bitmask field into PGPROC entries, which the sender could OR bits into before sending the one real signal event (either SIGUSR1 or SIGUSR2). That might work for expanding the number of available signals, yes. Regards Markus Wanner -- Sent via

Re: [HACKERS] Synchronous Log Shipping Replication

though? Uh.. no, such as signals *going to* the postmaster. That's where we already have such a multiplexer in place, but not the other way around IIRC. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Better auth errors from libpq

' and are wondering where that 'root' user came from. Regards Markus Wanner -- 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] Synchronous Log Shipping Replication

and still the standby could trigger the base data synchronization itself. Regards Markus Wanner -- 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] Review Report: propose to include 3 new functions into intarray and intagg

with these patches? Do you have time for some cleaning up and writing documentation? Regards Markus Wanner -- 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] Proposal: move column defaults into pg_attribute along with attacl

for the default value and possible another one for a ACLs, but none for the attribute itself? Why don't we just have a unique OID for pg_attribute (i.e. drop the BKI_WITHOUT_OIDS of pg_attribute) and merge in the default values and ACLs? Regards Markus Wanner -- Sent via pgsql-hackers mailing

Re: [HACKERS] Proposal: move column defaults into pg_attribute along with attacl

hand, we want defaults (and possibly ACLs) to be dependent, so that the dependency system cleans them up when dropping the table. It that correct? ISTM that we should at least combine defaults and ACLs then, as proposed by Stephen. Regards Markus Wanner -BEGIN PGP SIGNATURE- Version: GnuPG

Re: [HACKERS] WIP: Column-level Privileges

Hi, Markus Wanner wrote: As mentioned in above, regression tests, documentation updates, dependency handling, and actually implementing the permission checks all remain. What I'm looking for feedback on are the changes to the grammer, parser, catalog changes, psql output, etc. Aha, good. So

Re: [HACKERS] Proposal: move column defaults into pg_attribute along with attacl

(pg_attribute, merge with pg_attrdef or yet another pg_attracl table) So far I understood that merging pg_attrdef into pg_attribute is unwanted due to complexity at DROP TABLE. What does the subobject column for pg_shdepend buy us? Clarification appreciated. Regards Markus Wanner -- Sent

Re: [HACKERS] Proposal: move column defaults into pg_attribute along with attacl

Hi, Stephen Frost wrote: * Markus Wanner ([EMAIL PROTECTED]) wrote: What does the subobject column for pg_shdepend buy us? Tracking column-level ACL dependencies rather than having those dependencies only be at the table-level. This complicates pg_shdepend some, but simplifies

Re: [HACKERS] Proposal: move column defaults into pg_attribute along with attacl

work to another patch? Regards Markus Wanner -- 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] Proposal: move column defaults into pg_attribute along with attacl

that it can or should be done at all. Agreed. Regards Markus Wanner -- 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] Block-level CRC checks

block or vice versa)? Wouldn't that double the amount of seeking required for writes? I'd like to submit this for 8.4, but I want to ensure that -hackers at large approve of this feature before starting serious coding. Very cool! Regards Markus Wanner [1]: Crypto++ benchmarks: http

Re: [HACKERS] problem with compilation on fedora core 10 64 bit

Markus Wanner -- 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] The Axe list

as well, I thought we agreed that a more general functionality is wanted for core. But as long as we don't have that, I'd like intagg to stay in contrib. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Block-level CRC checks

? Regards Markus Wanner -- 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] Postgres-R pacth

Hi, Imre Geczy wrote: What kind of form or method must be used to patch that it can work correctly? I finally got around writing some installation instructions: http://www.postgres-r.org/documentation/installation Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] WIP: Column-level Privileges

Hello Stephen, Stephen Frost wrote: This has been fixed in the attached patch. Cool, thanks. If you could work on the documentation, that'd be great! I'll give it a try. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] WIP: Column-level Privileges

Hello Stephen, Stephen Frost wrote: Attached patch has this fixed and still passes all regression tests, etc. Do you have an up-to-date patch laying around? The current one conflicts with some CVS tip changes. I didn't get around writing some docu, yet. Sorry. Regards Markus Wanner

Re: [HACKERS] Synchronization Primitives

Regards Markus Wanner -- 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] write ahead logging in standby (streaming replication)

, there are the customers who absolutely want synchronous replication for its consistency and then there are the others who absolutely don't want it due to its unusably high latency. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] write ahead logging in standby (streaming replication)

not. In that spirit I have to admit that the term 'eager' that I'm currently using to describe Postgres-R may not be any more helpful. I take it to mean synchrony of 1. and 2., but not 3. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Syntax for partitioning

is used by other databases. That point is well taken, but it would be more compelling if it were the same or at least a compatible syntax. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

[HACKERS] pinging Dano

Hi, who is the main editor named Dano of the wiki page about Parallel Query Execution (http://wiki.postgresql.org/wiki/Parallel_Query_Execution), please speak up. Is there any code or patch available ATM? What discussion with Tom and Simon is that page referring to? Regards Markus Wanner

Re: [HACKERS] determine snapshot after obtaining locks for first statement

acquired after the first lock to a candidate snapshot for the second tuple lock we try. Maybe candidate snapshots is a good short name for such a feature? Another line of thought: isn't this like READ COMMITTED for just the first operation in a SERIALIZABLE transaction? Regards Markus Wanner

Re: [HACKERS] Cancelling idle in transaction state

default to no timeout). Regards Markus Wanner -- 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] Testing with concurrent sessions

processes, issues queries and checks results and ordering constraints (e.g. transaction X must commit and return a result before transaction Y). I'm still under the impression that this testing framework needs cleanup. However, others already showed interest as well... Regards Markus Wanner -- Sent

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: Where would I find this (and any related documentation)? Sorry, if that didn't get clear. I'm trying to put together something I can release real soon now (tm). I'll keep you informed. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Serializable Isolation without blocking

and using dynamic granularity based on the conflict rate and available memory? *duck* As this seems to be an optimization of predicate locking, don't we need to implement that first? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Serializable Isolation without blocking

of development for predicate locking? To me that seems to be the harder problem (due to being more general). Regards Markus Wanner -- 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] Serializable Isolation without blocking

). Is this really a problem? I suppose these more persistent write locks should be kept out of the DEFAULT lock method, too I fail to understand that part. What's the DEFAULT lock method? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Serializable Isolation without blocking

of that trivial implementation. My point is that due to that dependency, the conceptual design of a solution for predicate locking (with acceptable performance) should at least be considered before going into details with true serializability. Regards Markus Wanner -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Serializable Isolation without blocking

about implementing SIREAD atop table level or row level locking structures. With (non-existent) predicate locking, I'm still unsure. It might help to implement SIREAD atop such a predicate as well. Predicate tagging? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Serializable Isolation without blocking

. However, unlike others, it scales with the number of concurrently held locks. And with the current trend towards multi-multi-core platforms, that might get worse and worse (as concurrency must increase to efficiently use these cores). Regards Markus Wanner -- Sent via pgsql-hackers mailing list

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

up and running. Make it accessible via web to promote extensibility of Postgres and availability of extensions. Whether the first incarnation of the PGAN client works on Windows or Linux doesn't matter for now. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Serializable Isolation without blocking

to the tuple header on disk is not an option. Regards Markus Wanner -- 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] Serializable Isolation without blocking

Markus Wanner -- 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] Serializable Isolation without blocking

Hi, Kevin Grittner wrote: I had this flagged as needing a response, but it fell through the cracks yesterday. Apologies for the delayed response. No problem. Markus Wanner mar...@bluegap.ch wrote: When the Cahill paper talks about predicate locking, it *is* talking about what to lock

Re: [HACKERS] Serializable Isolation without blocking

is not something that's ever supposed to happen in Postgres, IIRC. Regards Markus Wanner -- 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] synchronized snapshots

Hi Joachim Wieland wrote: Since nobody objected to the idea in general, I have implemented it. Great! I hope to get some spare cycles within the next few days to review it. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Testing with concurrent sessions

Hi, Markus Wanner wrote: Sorry, if that didn't get clear. I'm trying to put together something I can release real soon now (tm). I'll keep you informed. Okay, here we go: dtester version 0.0. This emerged out of Postgres-R, where I don't just need to test multiple client connections

Re: [HACKERS] Testing with concurrent sessions

). Second: at the very end of pg_dtester.py, you find the line: reporter = StreamReporter() Try a CursesReporter() instead, it gives much nicer output! Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Testing with concurrent sessions

Hi, Quoting Kevin Grittner kevin.gritt...@wicourts.gov: I haven't quite gotten it to work yet; I'll start over with 3.0 and see how it goes. Let's stick to 2.x versions, first... I'll also attach the results of the 2.6 attempt. Thanks, that looks already pretty promising. ;-) A few

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: Not sure what's relevant there. Entire file tarball attached. Due to reasons mentioned in this thread as well, I've decided to use psql to connect to the database. dtester is parsing its output and checks that against expectations. Hawever, that has its own

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: You are trying to save a python file as non ASCII, without specifiying a correct source encoding line for encoding utf-8 I wasn't aware I had non-ascii characters in there. Inserting an encoding line seems fine. I'll fix that for the upcoming version 0.1. Regards

Re: [HACKERS] Testing with concurrent sessions

] and [psql2]. Dtester simply logs all and any output of all 3rd party processes started. Alternatively, you may want to filter out all lines that start with [postmaster0], that might already reduce what we can consider noise in this case. Regards Markus Wanner -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: My pager is less; could that cause it? Could the twisted environment look like one where the pager should kick in? Yes, that could be it. At least it fails here, too, if I set PAGER=less. Try: PAGER=more make dcheck So, the solution probably lies in adjusting

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: I'm a little unclear about the differences between uses, depends, and onlyAfter. Here's what they *sound* like they mean, to me; although I don't think the code isn't entirely consistent with this interpretation. Wow, you are way ahead of me. I intended to write

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: Based on Andrew's suggestion, I changed line 276 to: args=['psql', '-A', '--pset=pager=off', That looks like a correct fix for psql, yes. Thanks for pointing that out Andrew. Other processes might be confused by (or at least act differently with) a

Re: [HACKERS] Testing with concurrent sessions

Hi, Quoting Kevin Grittner kevin.gritt...@wicourts.gov: I strongly encourage you to set that up on git.postgresql.org. I'm about to provide git repositories for Postgres-R anyway, so I've setup two projects on git.postgres-r.org: dtester: that's the driver/harness code postgres-dtests: a

Re: [HACKERS] Mammoth in Core?

(in one way or another)... Regards Markus Wanner [1]: dtester http://www.bluegap.ch/projects/dtester -- 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] Testing with concurrent sessions

Hi, Jan Urbański wrote: sorry to butt in to the conversation, but I have spent some time wrapping/refining the concepts in dtester, and the results are here: http://git.wulczer.org/?p=twisted-psql.git;a=summary That seems to cover the concurrent psql part of dtester. But I don't see how

Re: [HACKERS] synchronized snapshots

. The timeout is nice, but is it really required? Isn't the normal query cancellation infrastructure sufficient? Hope that helps. Thanks for working on this issue. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Hot standby documentation

be configured to not loose data on master failure. Do we want to call the feature hot standby? Is a read-only standby a standby or a slave? I think hot standby is pretty much the term, now. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] synchronized snapshots

but we might want to have a more general snapshot cloning procedure instead. Not having a delay for other activities at all and not requiring superuser privileges would be a big advantage over what I have proposed. Agreed. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Testing with concurrent sessions

to support you with that. If you keep your code in a git repository, I could even provide patches, in case I need (or want) to change the dtester interface. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] ProcSignalSlot vs. PGPROC

per backend (plus NUM_AUXILIARY_PROCS). What am I missing? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] dtester-0.1 released

://www.bluegap.ch/projects/dtester/ A git repository for dtester as well as some integration code for testing Postgres based projects is available at: http://git.postgres-r.org/ Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] dtester-0.1 released

(especially if http continues to pose problems). Kind Regards Markus Wanner -- 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] [RFC] nodeToString format and exporting the SQL parser

.2F_Parser_as_an_independent_module Is this what you (or David) have in mind? Regards Markus Wanner -- 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] Hot standby?

Robert Haas wrote: I have also long argued that Synchronous Replication should really be called Streaming Replication. +1 Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] postgres-r

. Please feel free to ask more specific questions. Regards Markus Wanner P.S.: Sanu, did you note the addition of the link to the Postgres-R mailing list, which you pointed out was hard to find? URGENT == * Implement parsing of the replication_gcs GUC for spread and ensemble. * check for places

[HACKERS] setting up scan keys

on with simple index_beginscan(), index_rescan() and index_getnext(). My goal is to support any kind of UNIQUE INDEX, always with all attributes of the index. Any enlightening comments on this duplicate use of ScanKeyData? Help is greatly appreciated. Regards Markus Wanner -- Sent via

Re: [HACKERS] setting up scan keys

), values[attnum - 1]); } Thank you very much for your help, that quickly got me on track again. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] StringInfo Macros

) Is there any compelling reason these don't exist (and shouldn't get added)? IF not, I'd be happy to create a patch to add and make use of such macros. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] StringInfo Macros

a good prefix. PQFORMAT_ might be an option, but it's even less descriptive... Thank you for commenting. Regards Markus Wanner -- 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] combined indexes with Gist - planner issues?

such an intermediate lookup-table in advance. Not sure how much that's the case for you. Regards Markus Wanner -- 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] PGCluster-II Progress

Mitani-San, thank you for this heads up on PGCluster-II. The partial data idea sounds very interesting and I'm looking forward to an inspiring meeting in Tokyo. Kind Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Concurrency testing

well suited for performance testing of clustered solutions, as you very likely have to cluster the testing agents as well to put a decent load on the SUT. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Concurrency testing

, before testing. While the buildfarm already does that (partly, testing single patches would be a nice to have, too). Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Is FOR UPDATE an optimization fence?

it might change behavior compared to previous versions, it doesn't force people into writing kludges like OFFSET 0. BTW: how do other databases deal with this? Anything of relevance in the SQL standards? Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

  1   2   3   4   5   >