Re: [HACKERS] standby registration (was: is sync rep stalled?)

On 10/04/2010 11:32 PM, Robert Haas wrote: > I think in the end > this is not much different from standby registration; you still have > registrations, they just represent groups of machines instead of > single machines. Such groups are often easy to represent in CIDR notation, which would reduce

Re: [HACKERS] wip: functions median and percentile

2010/10/5 Dean Rasheed : > On 4 October 2010 18:22, Robert Haas wrote: >> On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed >> wrote: >>> That requires a new sort for each row. I generated this with a minor >>> tweak to Pavel's patch to just restart the tuplesort each time (the >>> "quick-fix" soluti

Re: [HACKERS] Basic JSON support

2010/10/5 Tom Lane : > Robert Haas writes: >> On Mon, Oct 4, 2010 at 2:50 PM, Joseph Adams >> wrote: >>> If he doesn't respond, or outright refuses (which I, for one, doubt >>> will happen), my fallback plan is to rewrite the JSON validation code >>> by drawing from my original code (meaning it

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

On Tue, Oct 5, 2010 at 3:42 AM, Tom Lane wrote: > OTOH, we don't have a similar interlock to prevent renaming users > who have active sessions, so maybe we are being overprotective here. Yep. What is worse is that we can drop users who have active sessions on the standby. Then we can get the foll

Re: [HACKERS] ugly locking corner cases ...

Excerpts from Hans-Jürgen Schönig's message of lun oct 04 07:02:04 -0400 2010: > i tracked down the issue quickly and make the following profile (in 10k locks > or so): > > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total >

Re: [HACKERS] levenshtein_less_equal (was: multibyte charater set in levenshtein function)

I've reworked patch with your suggestion. In this version I found a little slowdown in comparison with previous version: SELECT * FROM words WHERE levenshtein_less_equal(a, 'extensize', 2) <= 2; 48,069 ms => 57,875 ms SELECT * FROM words2 WHERE levenshtein_less_equal(a, 'клубничный', 3) <= 2; 100,

Re: [HACKERS] is sync rep stalled?

Fujii Masao writes: > On Tue, Oct 5, 2010 at 2:06 AM, Aidan Van Dyk wrote: >> I'm happy with the docs saying (maybe some what more politely): >>  Before configuring your master to be completly, >> wait-fully-synchronous, make sure you have a slave capable of being >> synchronous ready.  Because i

Re: [HACKERS] Insertion of geometric type column with column[0], column[1] and etc.

Robert Haas writes: > Yeah, but isn't the current behavior awfully flaky? The reason the particular case acts so oddly is there's no such thing as half a point: you can't have a point with one null and one non-null component. So there's no way to construct the value incrementally, which is what

Re: [HACKERS] Bug / shortcoming in has_*_privilege

(2010/09/07 6:16), Alvaro Herrera wrote: > Excerpts from Jim Nasby's message of jue jun 10 17:54:43 -0400 2010: >> test...@workbook=# select has_table_privilege( 'public', 'test', 'SELECT' ); >> ERROR: role "public" does not exist > > Here's a patch implementing this idea. > I checked this patch

Re: [HACKERS] Insertion of geometric type column with column[0], column[1] and etc.

On Mon, Oct 4, 2010 at 10:50 PM, Tom Lane wrote: > Marcelo Zabani writes: >> While I have emphasized the POINT data type, it would be desirable that all >> types in pgsql could be accessed/updated/inserted with the array-analogy (or >> other analogy), so that we could easily map ANYTHING with ORM

Re: [HACKERS] is sync rep stalled?

On Tue, Oct 5, 2010 at 2:06 AM, Aidan Van Dyk wrote: > On Mon, Oct 4, 2010 at 10:22 AM, Fujii Masao wrote: > >> I have one question for clarity: >> >> If we make all the transactions wait until specified standbys have >> connected to the master, how do we take a base backup from the >> master for

Re: [HACKERS] O_DSYNC broken on MacOS X?

On Fri, Oct 1, 2010 at 3:50 AM, Peter Eisentraut wrote: > On tor, 2010-09-30 at 15:07 -0700, Greg Stark wrote: >> > It's too bad there is no cross-platform way to ask what level of >> hardware-syncing is available. >> >> Why would the user want to ask this? As far as the user is concerned >> eithe

Re: [HACKERS] host name support in pg_hba.conf

It seems to me this patch has been left for a long time, although it tries to provide a useful functionality. In the previous discussion, several issues were pointed out. * Case handling when an IP-address has multiple hostnames. Steve Atkins noticed getaddrinfo() does not have capability to han

Re: [HACKERS] Insertion of geometric type column with column[0], column[1] and etc.

Marcelo Zabani writes: > While I have emphasized the POINT data type, it would be desirable that all > types in pgsql could be accessed/updated/inserted with the array-analogy (or > other analogy), so that we could easily map ANYTHING with ORM software these > days. Surely it would be better to g

[HACKERS] Insertion of geometric type column with column[0], column[1] and etc.

I've been using postgresql with geometric types and I've been using NHibernate as an ORM solution. The problem is that NHibernate can't map geometric data types to any kind of property of a class (not for insertions). I've (with partial success, as will be explained) mapped the desired column (in m

Re: [HACKERS] Basic JSON support

On Mon, Oct 4, 2010 at 7:45 PM, Tom Lane wrote: > Yeah.  Joseph seems to be confusing copyrights with patents.  The idea > of "parse JSON with bison/flex" is not patentable by any stretch of the > imagination. What I meant is, anyone who sets out to write a JSON parser with bison/flex is probably

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Mon, Oct 4, 2010 at 4:47 PM, Leonardo Francalanci wrote: >> It sounds like the costing model might need a bit more work before  we commit >>this. > > > I tried again the simple sql tests I posted a while ago, and I still get the > same ratios. > I've tested the applied patch on a dual opteron +

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Mon, Oct 4, 2010 at 8:42 AM, Robert Haas wrote: > Did you also adjust random_page_cost? No, my seq_page_cost (1) and random_page_cost (4) are from the defaults. Here are all my non-default settings: test=# SELECT name, unit, setting FROM pg_settings WHERE source != 'default'; nam

Re: [HACKERS] Basic JSON support

On 10/04/2010 08:00 PM, Josh Berkus wrote: All, But having said that, I wonder whether bison/flex are really the best tool for the job in the first place. From what I understand of JSON (which admittedly ain't much) a bison parser seems like overkill: it'd probably be both bloated and slow c

Re: [HACKERS] Basic JSON support

All, > But having said that, I wonder whether bison/flex are really the best > tool for the job in the first place. From what I understand of JSON > (which admittedly ain't much) a bison parser seems like overkill: > it'd probably be both bloated and slow compared to a simple handwritten > recurs

Re: [HACKERS] Basic JSON support

Robert Haas writes: > On Mon, Oct 4, 2010 at 2:50 PM, Joseph Adams > wrote: >> If he doesn't respond, or outright refuses (which I, for one, doubt >> will happen), my fallback plan is to rewrite the JSON validation code >> by drawing from my original code (meaning it won't be in bison/flex) >> a

Re: [HACKERS] patch: SQL/MED(FDW) DDL

On Thu, Sep 30, 2010 at 3:48 AM, Shigeru HANADA wrote: > On Thu, 30 Sep 2010 09:26:54 +0300 > Heikki Linnakangas wrote: >> > FYI, HiRDB, that implements FDW routines, has CREATE FOREIGN INDEX. >> > I think it is a little ugly and won't work in some cases -- for example, >> > index organized table

Re: [HACKERS] patch: SQL/MED(FDW) DDL

On Wed, Sep 29, 2010 at 3:56 AM, Shigeru HANADA wrote: > In current patch, fdwoptions for relations have been separated from > reloptins by introducing pg_foreign_table catalog.  As mentioned in > wiki, integration into rel/attoptions is nothing but an idea, we're > willing to add pg_foreign_attri

Re: [HACKERS] standby registration (was: is sync rep stalled?)

On Mon, Oct 4, 2010 at 3:25 PM, David Christensen wrote: > > On Oct 4, 2010, at 2:02 PM, Robert Haas wrote: > >> On Mon, Oct 4, 2010 at 1:57 PM, Markus Wanner wrote: >>> On 10/04/2010 05:20 PM, Robert Haas wrote: Quorum commit, even with configurable vote weights, can't handle a require

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

On Mon, Oct 4, 2010 at 3:16 PM, Josh Berkus wrote: > On 10/4/10 10:24 AM, Robert Haas wrote: >> I understand that we need to disconnect users if the database is >> dropped (it's kind of hard to access a database that's not there any >> more...) but I'm fuzzy on why we'd need to do that if it is me

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

> It sounds like the costing model might need a bit more work before we commit >this. I tried again the simple sql tests I posted a while ago, and I still get the same ratios. I've tested the applied patch on a dual opteron + disk array Solaris machine. I really don't get how a laptop hard dr

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

Robert Haas wrote: > Don't we already have some mechanism for notifying clients of > parameter changes they might care about? Are you thinking of GUC_REPORT? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgr

Re: [HACKERS] standby registration (was: is sync rep stalled?)

>>> Quorum commit, even with configurable vote weights, can't handle a >>> requirement that a particular commit be replicated to (A || B) && (C >>> || D). >> Good point. If this is the only feature which standby registration is needed for, has anyone written the code for it yet? Is anyone planni

Re: [HACKERS] [PERFORM] MIT benchmarks pgsql multicore (up to 48)performance

On Mon, Oct 4, 2010 at 8:44 AM, Hakan Kocaman wrote: > Hi, > for whom it may concern: > http://pdos.csail.mit.edu/mosbench/ > They tested with 8.3.9, i wonder what results 9.0 would give. > Best regards and keep up the good work They mention that these tests were run on the older 8xxx series opte

Re: [HACKERS] standby registration (was: is sync rep stalled?)

On Mon, Oct 4, 2010 at 3:25 PM, David Christensen wrote: > > On Oct 4, 2010, at 2:02 PM, Robert Haas wrote: > >> On Mon, Oct 4, 2010 at 1:57 PM, Markus Wanner wrote: >>> On 10/04/2010 05:20 PM, Robert Haas wrote: Quorum commit, even with configurable vote weights, can't handle a require

Re: [HACKERS] standby registration (was: is sync rep stalled?)

On Oct 4, 2010, at 2:02 PM, Robert Haas wrote: > On Mon, Oct 4, 2010 at 1:57 PM, Markus Wanner wrote: >> On 10/04/2010 05:20 PM, Robert Haas wrote: >>> Quorum commit, even with configurable vote weights, can't handle a >>> requirement that a particular commit be replicated to (A || B) && (C >>>

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

On Oct 4, 2010, at 11:06, Greg Stark wrote: > I guess by "lock-free in the uncontended case" they mean the buffer > cache manager is lock-free unless you're actually contending on the > same buffer? That refers to being able to acquire non-conflicting row/table locks without needing an exclusiv

Re: [HACKERS] wip: functions median and percentile

On 4 October 2010 18:22, Robert Haas wrote: > On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed wrote: >> That requires a new sort for each row. I generated this with a minor >> tweak to Pavel's patch to just restart the tuplesort each time (the >> "quick-fix" solution). The problem is that performanc

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

--On 4. Oktober 2010 13:24:37 -0400 Robert Haas wrote: I understand that we need to disconnect users if the database is dropped (it's kind of hard to access a database that's not there any more...) but I'm fuzzy on why we'd need to do that if it is merely renamed. Yeah, if there's no real

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

On 10/4/10 10:24 AM, Robert Haas wrote: > I understand that we need to disconnect users if the database is > dropped (it's kind of hard to access a database that's not there any > more...) but I'm fuzzy on why we'd need to do that if it is merely > renamed. This seems like an unexpected benefit, a

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

On Mon, Oct 4, 2010 at 2:42 PM, Tom Lane wrote: > Robert Haas writes: >> I understand that we need to disconnect users if the database is >> dropped (it's kind of hard to access a database that's not there any >> more...) but I'm fuzzy on why we'd need to do that if it is merely >> renamed. > > I

Re: [HACKERS] Basic JSON support

On Mon, Oct 4, 2010 at 2:50 PM, Joseph Adams wrote: > On Mon, Sep 20, 2010 at 12:38 AM, Joseph Adams > wrote: >> Here's one thing I'm worried about: the bison/flex code in your patch >> looks rather similar to the code in >> http://www.jsonlint.com/bin/jsonval.tgz , which is licensed under the >>

Re: [HACKERS] standby registration (was: is sync rep stalled?)

On Mon, Oct 4, 2010 at 1:57 PM, Markus Wanner wrote: > On 10/04/2010 05:20 PM, Robert Haas wrote: >> Quorum commit, even with configurable vote weights, can't handle a >> requirement that a particular commit be replicated to (A || B) && (C >> || D). > > Good point. > > Can the proposed standby reg

Re: [HACKERS] pgadmin3_90 package

Hi, From: Devrim GÜNDÜZ Date: Mon, 04 Oct 2010 20:59:57 +0300 > On Sun, 2010-10-03 at 23:46 +0900, Tomoaki Sato wrote: >> >> I try to install pgAdmin III using Yum on CentOS 5.5 (x86_64), but it >> seems pgadmin3_90 package architecture is i386 in Yum repository. > > There was a build problem

Re: [HACKERS] Basic JSON support

On Mon, Sep 20, 2010 at 12:38 AM, Joseph Adams wrote: > Here's one thing I'm worried about: the bison/flex code in your patch > looks rather similar to the code in > http://www.jsonlint.com/bin/jsonval.tgz , which is licensed under the > GPL.  In particular, the incorrect number regex I discussed

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

Robert Haas writes: > I understand that we need to disconnect users if the database is > dropped (it's kind of hard to access a database that's not there any > more...) but I'm fuzzy on why we'd need to do that if it is merely > renamed. I think that modern backends might survive that okay (thoug

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

On Mon, Oct 04, 2010 at 01:13:36PM -0400, Robert Haas wrote: > I believe the "one of only 16 global mutexes" comment is referring to > NUM_LOCK_PARTITIONS (there's also NUM_BUFFER_PARTITIONS, but that > wouldn't be relevant for row and table-level locks). Yes -- my understanding is that they hit t

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

Here's a video on lock-free hashing for example: http://video.google.com/videoplay?docid=2139967204534450862# I guess by "lock-free in the uncontended case" they mean the buffer cache manager is lock-free unless you're actually contending on the same buffer? -- Sent via pgsql-hackers mailing li

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

I wasn't involved in this work but I do know a bit about it. Sadly, the work on Postgres performance was cut down to under a page, complete with the amazing offhand mention of "rewriting PostgreSQL's lock manager". Here are a few more details... The benchmarks in this paper are all about stressing

Re: [HACKERS] pgadmin3_90 package

On Sun, 2010-10-03 at 23:46 +0900, Tomoaki Sato wrote: > > I try to install pgAdmin III using Yum on CentOS 5.5 (x86_64), but it > seems pgadmin3_90 package architecture is i386 in Yum repository. There was a build problem on 64-bit build on RHEL5, so I pushed 32-bit version. -- Devrim GÜNDÜZ Po

Re: [HACKERS] standby registration (was: is sync rep stalled?)

On 10/04/2010 05:20 PM, Robert Haas wrote: > Quorum commit, even with configurable vote weights, can't handle a > requirement that a particular commit be replicated to (A || B) && (C > || D). Good point. Can the proposed standby registration configuration format cover such a requirement? Regards

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

On Mon, Oct 4, 2010 at 1:38 PM, Michael Glaesemann wrote: > > On Oct 4, 2010, at 13:13 , Robert Haas wrote: > >> On Mon, Oct 4, 2010 at 10:44 AM, Hakan Kocaman wrote: >>> for whom it may concern: >>> http://pdos.csail.mit.edu/mosbench/ >>> They tested with 8.3.9, i wonder what results 9.0 would g

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

On Oct 4, 2010, at 13:13 , Robert Haas wrote: > On Mon, Oct 4, 2010 at 10:44 AM, Hakan Kocaman wrote: >> for whom it may concern: >> http://pdos.csail.mit.edu/mosbench/ >> They tested with 8.3.9, i wonder what results 9.0 would give. >> Best regards and keep up the good work >> Hakan > > Here's

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

On Mon, Oct 4, 2010 at 7:38 AM, Fujii Masao wrote: > On Mon, Oct 4, 2010 at 2:05 AM, Bernd Helmle wrote: >> Our documentation in >> currently >> says the following: >> >> >> Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE

Re: [HACKERS] wip: functions median and percentile

On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed wrote: > That requires a new sort for each row. I generated this with a minor > tweak to Pavel's patch to just restart the tuplesort each time (the > "quick-fix" solution). The problem is that performance really sucks, > because it is an O(n^2 log(n)) a

Re: [HACKERS] pgadmin3_90 package

On Sun, Oct 3, 2010 at 10:46 AM, Tomoaki Sato wrote: > I try to install pgAdmin III using Yum on CentOS 5.5 (x86_64), but it > seems pgadmin3_90 package architecture is i386 in Yum repository. > > # cat /etc/redhat-release > CentOS release 5.5 (Final) > # yum list pgadmin3_90 > (snip) > Available

Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

On Mon, Oct 4, 2010 at 10:44 AM, Hakan Kocaman wrote: > for whom it may concern: > http://pdos.csail.mit.edu/mosbench/ > They tested with 8.3.9, i wonder what results 9.0 would give. > Best regards and keep up the good work > Hakan Here's the most relevant bit to us: -- The “Stock” line in Figur

Re: [HACKERS] is sync rep stalled?

On Mon, Oct 4, 2010 at 10:22 AM, Fujii Masao wrote: > I have one question for clarity: > > If we make all the transactions wait until specified standbys have > connected to the master, how do we take a base backup from the > master for those standbys? We seem to be unable to do that because > pg_

Re: [HACKERS] Adding getrusage profiling data to EXPLAIN output

On Sat, Oct 2, 2010 at 3:14 AM, Greg Stark wrote: > The observed timings are > query only                 100.5ms > explain (analyze)         1234.9ms > explain (analyze,resource) 2210.2ms It's very large overheads, but I think it is still useful if there are no overhead if we disable the reso

[HACKERS] ToDo: enhanced autocomplete for object identified by prefix

Hello I looked so we can enhance autocomple about: autocomplete any datatypes for casting and autocomplete any psql varibles. This need just add support suffix and prefix strings to joining final string. these variables can be filled by specified handlers - like now. Some proposed values: prefix

Re: [HACKERS] Adding getrusage profiling data to EXPLAIN output

On Mon, Oct 4, 2010 at 3:29 AM, Itagaki Takahiro wrote: >  * There are some overlaps between the feature and DTrace hooks. >   If we need such extension even though we have DTrace hooks, >   it might mean DTrace hooks are hard to use for average users >   and maybe also for postgres' hackers... I

Re: [HACKERS] wip: functions median and percentile

On Sun, Oct 3, 2010 at 11:58 PM, Dean Rasheed wrote: > The problem is that performance really sucks, > because it is an O(n^2 log(n)) algorithm. I don't see an easy way > around that without significant new infrastructure, as Greg describes, > or a completely different algorithm. Resorting for ea

Re: [HACKERS] Review: Fix snapshot taking inconsistencies

On 2010-10-04 6:19 AM, Steve Singer wrote: I also noticed that functions.c is now generating a warning that should be easy to clean up. functions.c: In function 'sql_exec_error_callback': functions.c:989: warning: 'es' may be used uninitialized in this function functions.c: In function 'fmgr_sql

Re: [HACKERS] [GENERAL] streaming replication question

On Sun, Oct 3, 2010 at 1:02 AM, Rajesh Kumar Mallah wrote: > As an enduser i setup SR based on > http://wiki.postgresql.org/wiki/Streaming_Replication > The master & standby are both powerful machines and are on same gigabit > switch. > Things worked as expected I updated 1000's of records in sing

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

On Oct 1, 2010, at 8:36 PM, Josh Kupershmidt wrote: > On Fri, Oct 1, 2010 at 4:33 AM, Leonardo Francalanci wrote: >>> I ran a few more performance tests on this patch. Here's what I got >>> for the tests Leonardo posted originally: >>>* 2M rows: 22 seconds for seq. scan, 24 seconds for ind

Re: [HACKERS] ugly locking corner cases ...

On Oct 4, 2010, at 1:23 PM, Heikki Linnakangas wrote: > On 04.10.2010 14:02, Hans-Jürgen Schönig wrote: >> it seems we have found a fairly nasty problem. >> imagine a long transaction which piles up XX.XXX of locks (count on >> pg_locks) inside the same transaction by doing some tasty savepoints,

[HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On 4/10/2010 8:09 PM, Dave Page wrote: Any idea of the performance overhead? A GUC read and string compare when off, and (untested as yet) I expect little more when on. Thinking about it, a possibly better alternative is to ship it as a library as is done with the pl/pgsql debugger, and us

Re: [HACKERS] OUTER keyword

I wrote: > Heikki Linnakangas writes: >> Why is OUTER a type_func_name_keyword? The grammar doesn't require that, >> it could as well be unreserved. > Hm, you sure? All the JOIN-related keywords used to need to be at least > that to avoid conflicts, IIRC. Actually, on reflection, it's possible

Re: [HACKERS] standby registration (was: is sync rep stalled?)

On Mon, Oct 4, 2010 at 3:08 AM, Markus Wanner wrote: > On 10/01/2010 05:06 PM, Dimitri Fontaine wrote: >> Wait forever can be done without standby registration, with quorum commit. > > Yeah, I also think the only reason for standby registration is ease of > configuration (if at all). There's no te

[HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

Hi, for whom it may concern: http://pdos.csail.mit.edu/mosbench/ They tested with 8.3.9, i wonder what results 9.0 would give. Best regards and keep up the good work Hakan

Re: [HACKERS] Proposed Windows-specific change: Enable crash dumps (like core files)

On 4/10/2010 8:06 PM, Andrew Dunstan wrote: On 10/04/2010 07:50 AM, Craig Ringer wrote: - If the crash dump handler is enabled by setting the GUC, all backends register the handler during startup or (if it proves practical) when the GUC is changed. - When the handler is triggered by the OS t

Re: [HACKERS] Proposed Windows-specific change: Enable crash dumps (like core files)

On 10/04/2010 07:50 AM, Craig Ringer wrote: - If the crash dump handler is enabled by setting the GUC, all backends register the handler during startup or (if it proves practical) when the GUC is changed. - When the handler is triggered by the OS trapping an unhandled exception, it load

Re: [HACKERS] Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Oct 4, 2010 at 12:50 PM, Craig Ringer wrote: > - Always compile the crash dump feature in builds, so every build that >  goes to a user is capable of crash dumps. Because a suitable version >  of dbghelp.dll has been included in Windows XP and above, it shouldn't >  be necessary to ship t

[HACKERS] Proposed Windows-specific change: Enable crash dumps (like core files)

Hi all After this recent "fun" trying to get a usable crash dump or stack trace from a crashing autovacuum worker on Windows, I'd like to make a quick proposal - one that'll be followed by a patch if there aren't any loud NACKs. Windows has a couple of built-in facilities to automatically ge

Re: [HACKERS] ToDo: enhanced autocomplete for object identified by prefix

2010/10/4 Pavel Stehule : > Hello > > I looked so we can enhance autocomple about: autocomplete any > datatypes for casting and autocomplete any psql varibles. This need > just add support suffix and prefix strings to joining final string. > these variables can be filled by specified handlers - lik

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

On Mon, Oct 4, 2010 at 2:05 AM, Bernd Helmle wrote: > Our documentation in > currently > says the following: > > > Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER DATABASE > ... RENAME on the primary will generat

Re: [HACKERS] Review: Fix snapshot taking inconsistencies

Marko Tiikkaja writes: > On 2010-10-04 6:19 AM, Steve Singer wrote: >> Is there any third party code in particular that your thinking of? I don't >> see anything that says pg_parse_and_rewrite is part of a stable server >> side API (in contrast to SPI or something an third party index access meth

Re: [HACKERS] ugly locking corner cases ...

On 04.10.2010 14:02, Hans-Jürgen Schönig wrote: it seems we have found a fairly nasty problem. imagine a long transaction which piles up XX.XXX of locks (count on pg_locks) inside the same transaction by doing some tasty savepoints, with hold cursors and so on. in this case we see that a normal

Re: [HACKERS] is sync rep stalled?

On Fri, Oct 1, 2010 at 11:16 PM, David Fetter wrote: > On Fri, Oct 01, 2010 at 07:48:25PM +0900, Fujii Masao wrote: >> I proposed to implement the "return-immediately" at first because it >> doesn't require standby registration. But if many people think that >> the "wait-forever" is the core rathe

Re: [HACKERS] OUTER keyword

Heikki Linnakangas writes: > Why is OUTER a type_func_name_keyword? The grammar doesn't require that, > it could as well be unreserved. Hm, you sure? All the JOIN-related keywords used to need to be at least that to avoid conflicts, IIRC. regards, tom lane -- Sent via

[HACKERS] ugly locking corner cases ...

hello all ... it seems we have found a fairly nasty problem. imagine a long transaction which piles up XX.XXX of locks (count on pg_locks) inside the same transaction by doing some tasty savepoints, with hold cursors and so on. in this case we see that a normal count issued in a second database

Re: [HACKERS] patch: psql variables tabcomplete

Hello 2010/10/4 Itagaki Takahiro : > On Mon, Aug 16, 2010 at 8:32 PM, Pavel Stehule > wrote: >> fixed spelling >> >> 2010/8/16 Pavel Stehule : >>> I found so there are not support for tabcomple of psql variables. > > Contents & Purpose > == > This small patch adds support for tab

Re: [HACKERS] Additional index entries and table sorting

On 26 September 2010 18:07, Thom Brown wrote: > On 26 September 2010 17:49, Thom Brown wrote: >> I attach a patch which adds all functions (or at least the ones I >> found) into the index so that they can be easily located.  Previously >> there were no entries for most of these at all in the inde

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On 4/10/2010 8:27 PM, Heikki Linnakangas wrote: On 04.10.2010 15:21, Craig Ringer wrote: Thinking about it, a possibly better alternative is to ship it as a library as is done with the pl/pgsql debugger, and use (I think) shared_preload_libraries to load it when desired. That way there's zero co

Re: [HACKERS] is sync rep stalled?

On 04.10.2010 10:49, Markus Wanner wrote: On 10/04/2010 09:18 AM, Heikki Linnakangas wrote: With 'replay' and hot standby combination, you'll want to set max_standby_archive_delay to a very low value, or a read-only query can cause master to stop processing commits (or the standby to stop accept

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On 04.10.2010 15:21, Craig Ringer wrote: Thinking about it, a possibly better alternative is to ship it as a library as is done with the pl/pgsql debugger, and use (I think) shared_preload_libraries to load it when desired. That way there's zero cost if disabled, though a somewhat higher cost if

Re: [HACKERS] patch: psql variables tabcomplete

On Mon, Aug 16, 2010 at 8:32 PM, Pavel Stehule wrote: > fixed spelling > > 2010/8/16 Pavel Stehule : >> I found so there are not support for tabcomple of psql variables. Contents & Purpose == This small patch adds support for tab-completion of \set meta command in psql. Variables

Re: [HACKERS] wip: functions median and percentile

On 4 October 2010 07:36, Hitoshi Harada wrote: > 2010/10/4 Greg Stark : >> On Sun, Oct 3, 2010 at 7:06 AM, Hitoshi Harada wrote: >>> And I'm now thinking about how to make median happen in window >>> aggregate. >> >> If you were to do this by extending tuplesort what extra features >> would tuple

Re: [HACKERS] wip: functions median and percentile

2010/10/4 Greg Stark : > On Sun, Oct 3, 2010 at 7:06 AM, Hitoshi Harada wrote: >> And I'm now thinking about how to make median happen in window >> aggregate. > > If you were to do this by extending tuplesort what extra features > would tuplesort need? I don't think we need to extend tuplesort wh

Re: [HACKERS] is sync rep stalled?

On 04.10.2010 10:03, Markus Wanner wrote: On 09/30/2010 04:54 PM, Yeb Havinga wrote: Heikki Linnakangas wrote: You do realize that to be able to guarantee zero data loss, the master will have to stop committing new transactions if the streaming stops for any reason, like a network glitch. Maybe

Re: [HACKERS] is sync rep stalled?

On 09/30/2010 04:54 PM, Yeb Havinga wrote: > Heikki Linnakangas wrote: >> You do realize that to be able to guarantee zero data loss, the master >> will have to stop committing new transactions if the streaming stops >> for any reason, like a network glitch. Maybe that's a tradeoff you >> want, but

[HACKERS] OUTER keyword

Why is OUTER a type_func_name_keyword? The grammar doesn't require that, it could as well be unreserved. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.po

[HACKERS] todo point: plpgsql - scrollable cursors are supported

Hello I am thinking so you can remove a "scrollable cursor support" from ToDo for plpgsql. Scrollable cursors are supported and supported syntax are same as core SQL language. regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] is sync rep stalled?

Hi, On 10/03/2010 05:52 AM, Josh Berkus wrote: > (3) Invite people to comment on the wiki by leaving per-item comments > and suggestions with their own names. Please keep discussions on the mailing list. On Wikis, those are very hard to follow (Date or From missing, no offline capabilities, indir

Re: [HACKERS] is sync rep stalled?

On 10/04/2010 09:18 AM, Heikki Linnakangas wrote: > Note that this assumes that you use the 'replay' synchronization level. > In the weaker levels, read-only queries can always return stale data. I'm not too found of those various synchronization levels, but IIUC all other levels only allow a rath

Re: [HACKERS] is sync rep stalled?

On 10/01/2010 05:06 PM, Dimitri Fontaine wrote: > Wait forever can be done without standby registration, with quorum commit. Yeah, I also think the only reason for standby registration is ease of configuration (if at all). There's no technical requirement for standby registration, AFAICS. Or does

Re: [HACKERS] Review: Patch for Synchronous Replication

On Thu, Sep 30, 2010 at 8:29 AM, Thom Brown wrote: >>> This is a basic review of Fujii Masao's synchronous replication patch Thanks for the review! And sorry for the delay. >>> I configured the primary's standby.conf to provide synchronous >>> replication to a single slave using fsync as it's re

Re: [HACKERS] patch: tsearch - some memory diet

Hello 2010/10/4 Robert Haas : > On Oct 3, 2010, at 7:02 PM, Tom Lane wrote: >> It's not at all apparent that the code is even >> safe as-is, because it's depending on the unstated assumption that that >> static variable will get reset once per dictionary.  The documentation >> is horrible: it doe