Re: [HACKERS] unlogged tables

2010-12-14 Thread Heikki Linnakangas
On 14.11.2010 02:16, Robert Haas wrote: 3. The third patch (relax-sync-commit-v1) allows asynchronous commit even when synchronous_commit=on if the transaction has not written WAL. Of course, a read-only transaction won't even have an XID and therefore won't need a commit record, so what this is

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

2010-12-14 Thread Andrew Dunstan
On 12/14/2010 12:42 PM, Tom Lane wrote: Another line of attack is that we know from the response packet that the failure is being reported at guc.c:4794. It would be really useful to know what the call stack is there. Could you change that elog to an elog(PANIC) and get a stack trace from th

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 10:43 PM, Itagaki Takahiro wrote: > On Wed, Dec 15, 2010 at 12:20, Robert Haas wrote: >> It seems like pg_read_binary_file() is good to have regardless of >> whatever else we decide to do here.  Should we pull that part out and >> commit it separately? > > OK, I'll do that

[HACKERS] bug in SignalSomeChildren

2010-12-14 Thread Fujii Masao
Hi, I found a bug which always prevents SignalSomeChildren with BACKEND_TYPE_WALSND from sending a signal to walsender. Though currently SignalSomeChildren with BACKEND_TYPE_WALSND has not been called anywhere, it's not hard to believe that will be called in the future. So we should apply the fol

Re: [HACKERS] Getting "ERROR: no unpinned buffers available" on HEAD, should I investigate?

2010-12-14 Thread Alvaro Herrera
Excerpts from Florian Pflug's message of mar dic 14 21:51:47 -0300 2010: > Hi > > When I run my FK concurrency test suite on an unpatched HEAD, I'm getting > quite a lot of "no unpinned buffers available" errors. > > Increasing shared_buffers from 32MB (the default) to 64MB makes the errors go

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Itagaki Takahiro
On Wed, Dec 15, 2010 at 12:20, Robert Haas wrote: > It seems like pg_read_binary_file() is good to have regardless of > whatever else we decide to do here.  Should we pull that part out and > commit it separately? OK, I'll do that, but I have some questions: #1 Should we add 'whole' versions of

Re: [HACKERS] CommitFest wrap-up

2010-12-14 Thread Robert Haas
On Mon, Dec 13, 2010 at 12:37 PM, Robert Haas wrote: > - fix for seg picksplit function - I don't have confidence this change > is for the best and can't take responsibility for it. It needs review > by a committer who understands this stuff better than me and can > determine whether or not the c

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 9:25 PM, Itagaki Takahiro wrote: > On Wed, Dec 15, 2010 at 03:42, Robert Haas wrote: I think #2 might be a nice thing to have, but I'm not sure what it has to do with extensions. >>> >>> Agreed.  There might be some use for #4 in connection with extensions, >>> b

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Itagaki Takahiro
On Wed, Dec 15, 2010 at 03:42, Robert Haas wrote: >>> I think #2 might be a nice thing to have, but I'm not sure what it has >>> to do with extensions. >> >> Agreed.  There might be some use for #4 in connection with extensions, >> but I don't see that #2 is related. >> >> BTW, it appears to me th

Re: [HACKERS] Per-column collation

2010-12-14 Thread Robert Haas
On Sun, Dec 12, 2010 at 5:15 PM, Peter Eisentraut wrote: > On lör, 2010-12-04 at 18:04 +0200, Peter Eisentraut wrote: >> Here is an updated patch to address the issues discussed during this >> commitfest. > > And another one, that fixes the problems pointed out since. I don't really have a positi

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Josh Berkus
> I have; the above would hold the lock window open while the SELECT runs > and that is explicitly something we are trying to avoid. Not necessarily. You could copy into a temp table first, and then swap. -- -- Josh Berkus

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 5:21 PM, Peter Geoghegan wrote: > Here's the output I see when $SUBJECT occurs, on a pg freshly built > from git master with --enable-debug and --enable-cassert: I am suspicious of the fact that you are invoking initdb as ./initdb. Is it possible you're invoking this from

Re: [HACKERS] WIP patch for parallel pg_dump

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 7:06 PM, Koichi Suzuki wrote: > Thank you very much for your advice.   Indeed, I'm considering to > change the license to PostgreSQL's one.   It may take a bit more > though... You wouldn't necessarily need to relicense all of Postgres-XC (although that would be cool, too,

Re: [HACKERS] Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

2010-12-14 Thread Florian Pflug
On Dec14, 2010, at 22:34 , Florian Pflug wrote: > For non-assert-enabled builds, the only effect of the patch is thus to > consistently return InvalidTransactionId if the crosscheck snapshot turns > HeapTupleMayBeUpdated into HeapTupleUpdated. Which certainly seems to be > an improvement over somet

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Josh Berkus
On 12/14/10 11:43 AM, Simon Riggs wrote: > On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote: > >> In order for REPLACE WITH to be really useful, though, we need a >> command cloning at table design with *all* constraints, FKs, keys, and >> indexes. Currently, I still don't think we have that

Re: [HACKERS] [PATCH] V3: Idle in transaction cancellation

2010-12-14 Thread Robert Haas
On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund wrote: >> > Here is a proposed patch which enables cancellation of $subject. Disclaimer: This isn't my area of expertise, so take the below with a grain or seven of salt. It sort of looks to me like the LOG_NO_CLIENT error flag and the silent_error_

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread James William Pye
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: > how do you identify which type OID is really hstore? How about an identification field on pg_type? CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore'; -- Where the "identifier" is an arbitrary string. Type information can be looked up by th

[HACKERS] Getting "ERROR: no unpinned buffers available" on HEAD, should I investigate?

2010-12-14 Thread Florian Pflug
Hi When I run my FK concurrency test suite on an unpatched HEAD, I'm getting quite a lot of "no unpinned buffers available" errors. Increasing shared_buffers from 32MB (the default) to 64MB makes the errors go away, as does setting fsync=off. I'm not sure how many buffers a particular backend

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Simon Riggs
On Tue, 2010-12-14 at 16:19 -0800, Josh Berkus wrote: > Without some means of doing a clone of the table in a single command, > you've eliminated half the scripting work, but not helped at all with > the other half. I'm not trying to eliminate scripting work, I'm trying to minimise the lock windo

Re: [HACKERS] WIP patch for parallel pg_dump

2010-12-14 Thread Koichi Suzuki
Robert; Thank you very much for your advice. Indeed, I'm considering to change the license to PostgreSQL's one. It may take a bit more though... -- Koichi Suzuki 2010/12/15 Robert Haas : > On Tue, Dec 7, 2010 at 3:23 AM, Koichi Suzuki wrote: >> This is what Postgres-XC is doing bet

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Itagaki Takahiro
On Wed, Dec 15, 2010 at 04:39, Dimitri Fontaine wrote: > Well, in fact, the extension's code is using either execute_sql_file() > or read_text_file_with_endoding() then @extschema@ replacement then > execute_sql_string(), all those functions called directly thanks to > #include "utils/genfile.h".

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Jan Urbański
On 14/12/10 17:52, Tom Lane wrote: > Peter Eisentraut writes: >> On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote: >>> It would be cool to be able to transparently use hstores as Python >>> dictionaries and vice versa. It would be easy enough with hstore as a >>> core type, but with hstore as

[HACKERS] Segfault related to pg_authid when running initdb from git master

2010-12-14 Thread Peter Geoghegan
Here's the output I see when $SUBJECT occurs, on a pg freshly built from git master with --enable-debug and --enable-cassert: [postg...@peter bin]$ uname -a Linux peter.laptop 2.6.35.9-64.fc14.x86_64 #1 SMP Fri Dec 3 12:19:41 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux [postg...@peter bin]$ ./initdb -

Re: [HACKERS] unlogged tables vs. GIST

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas >> wrote: >>> Hmm, the first idea that comes to mind is to use a counter like the >>> GetXLogRecPtrForTemp() counter I used for temp tables, but global, in shared >>> mem

Re: [HACKERS] WIP patch for parallel pg_dump

2010-12-14 Thread Robert Haas
On Tue, Dec 7, 2010 at 3:23 AM, Koichi Suzuki wrote: > This is what Postgres-XC is doing between a coordinator and a > datanode.    Coordinator may correspond to poolers/loadbalancers. > Does anyone think it makes sense to extract XC implementation of > snapshot shipping to PostgreSQL itself? Per

Re: [HACKERS] unlogged tables vs. GIST

2010-12-14 Thread Tom Lane
Robert Haas writes: > On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas > wrote: >> Hmm, the first idea that comes to mind is to use a counter like the >> GetXLogRecPtrForTemp() counter I used for temp tables, but global, in shared >> memory. However, that's a bit problematic because if we stor

Re: [HACKERS] BufFreelistLock

2010-12-14 Thread Jim Nasby
On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote: > On Sun, Dec 12, 2010 at 6:48 PM, Jim Nasby wrote: >> >> BTW, when we moved from 96G to 192G servers I tried increasing shared >> buffers from 8G to 28G and performance went down enough to be noticeable (we >> don't have any good benchmarks, so

Re: [HACKERS] Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

2010-12-14 Thread Florian Pflug
On Dec14, 2010, at 21:52 , Tom Lane wrote: > Florian Pflug writes: >> Could you explain what seems to be wrong with my patch? > > I'm unconvinced that this is the proper response to whatever the problem > is; Well, you didn't comment on the part of my previous e-mail that *did* explain why I beli

Re: [HACKERS] unlogged tables vs. GIST

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas wrote: > Hmm, the first idea that comes to mind is to use a counter like the > GetXLogRecPtrForTemp() counter I used for temp tables, but global, in shared > memory. However, that's a bit problematic because if we store a value from > that counte

Re: [HACKERS] unlogged tables vs. GIST

2010-12-14 Thread Heikki Linnakangas
On 14.12.2010 23:06, Robert Haas wrote: On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas wrote: The fact that it's easy doesn't make it workable. I would point out for starters that AMs might (do) put WAL locations and/or XIDs into indexes. Occasionally copying very old LSNs or XIDs back into acti

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

2010-12-14 Thread Andrew Dunstan
On 12/14/2010 12:42 PM, Tom Lane wrote: This seems quite odd now that I look at it. The packet contents imply that libpq saw PGOPTIONS="-c log_min_messages=warning" and no other environment variables that would cause it to append stuff to the connection request. Which is not at all how pg_reg

[HACKERS] unlogged tables vs. GIST

2010-12-14 Thread Robert Haas
On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas wrote: >> The fact that it's easy doesn't make it workable.  I would point out for >> starters that AMs might (do) put WAL locations and/or XIDs into indexes. >> Occasionally copying very old LSNs or XIDs back into active files seems >> pretty dangerous

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Marko Tiikkaja
On 2010-12-14 7:05 PM +0200, Tom Lane wrote: Marko Tiikkaja writes: On 2010-12-14 4:23 AM +0200, Tom Lane wrote: Uh, I don't think so. It sure looks like you have changed the user lockmethod to be transactional, ie, auto-release on commit/abort. I was under the impression that passing sess

Re: [HACKERS] Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

2010-12-14 Thread Tom Lane
Florian Pflug writes: > Could you explain what seems to be wrong with my patch? I'm unconvinced that this is the proper response to whatever the problem is; and if it is the right response, it seems to still need a good bit more work. You didn't even update the functions' header comments, let al

Re: [HACKERS] Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

2010-12-14 Thread Florian Pflug
On Dec14, 2010, at 21:18 , Tom Lane wrote: > Florian Pflug writes: >> In the process of re-verifying my serializable lock consistency patch, I ran >> the fk_concurrency testsuite against *unpatched* HEAD for comparison. > >> My build of HEAD had asserts enabled, and I promptly triggered >>Ass

Re: [HACKERS] Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

2010-12-14 Thread Tom Lane
Florian Pflug writes: > In the process of re-verifying my serializable lock consistency patch, I ran > the fk_concurrency testsuite against *unpatched* HEAD for comparison. > My build of HEAD had asserts enabled, and I promptly triggered > Assert(!(tp.t_data->t_infomask & HEAP_XMAX_INVALID))

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread David E. Wheeler
On Dec 14, 2010, at 11:52 AM, Jan Urbański wrote: > If the function is declared to return a hstore, it transforms the > dictionary to a hstore. Oh, right. Duh. >> Can you overload the stringification of a dictionary to return the hstore >> string representation? > > Mmm, interesting thought. I

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Jan Urbański
On 14/12/10 18:05, David E. Wheeler wrote: > On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote: > >> A function said to be returning a hstore could return a dictionary and if it >> would have only string keys/values, it would be changed into a hstore (and >> if not, throw an ERROR). > > It doesn

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Simon Riggs
On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote: > As for the utility of this command: there is no question that I would > use it. I'm not sure I like the syntax (I'd prefer REPLACE TABLE > WITH _), but that's painting the bike shed. REPLACE TABLE ying WITH yang is probably easier

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Simon Riggs
On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote: > In order for REPLACE WITH to be really useful, though, we need a > command cloning at table design with *all* constraints, FKs, keys, and > indexes. Currently, I still don't think we have that ... do we? Being able to vary the indexes when

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Simon Riggs
On Tue, 2010-12-14 at 21:35 +0200, Heikki Linnakangas wrote: > On 14.12.2010 20:27, Simon Riggs wrote: > > There are various applications where we want to completely replace the > > contents of a table with new/re-calculated data. > > > > It seems fairly obvious to be able to do this like... > > 1.

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Dimitri Fontaine
Tom Lane writes: > Robert Haas writes: >> So there are really four changes in here, right? > >> 1. Relax pg_read_file() to be able to read any files. >> 2. pg_read_binary_file() >> 3. pg_execute_sql_string()/file() >> 4. ability to read a file in a given encoding (rather than the client >> encod

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 2:34 PM, Josh Berkus wrote: > On 12/14/10 11:07 AM, Robert Haas wrote: >> Because then you have to take an AccessExclusiveLock on the target >> table, of course. > > Well, you have to do that for DROP TABLE as well, and I don't see any > way around doing it for REPLACE WITH

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Heikki Linnakangas
On 14.12.2010 20:27, Simon Riggs wrote: There are various applications where we want to completely replace the contents of a table with new/re-calculated data. It seems fairly obvious to be able to do this like... 1. Prepare new data into "new_table" and build indexes 2. Swap old for new BEGIN;

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Josh Berkus
On 12/14/10 11:07 AM, Robert Haas wrote: > Because then you have to take an AccessExclusiveLock on the target > table, of course. Well, you have to do that for DROP TABLE as well, and I don't see any way around doing it for REPLACE WITH. As for the utility of this command: there is no question th

[HACKERS] Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

2010-12-14 Thread Florian Pflug
Hi In the process of re-verifying my serializable lock consistency patch, I ran the fk_concurrency testsuite against *unpatched* HEAD for comparison. My build of HEAD had asserts enabled, and I promptly triggered Assert(!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)) in heap_delete(). The seem

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread David E. Wheeler
On Dec 14, 2010, at 9:31 AM, Robert Haas wrote: > Three different people developed patches, and I think we don't really > have unanimity on which way to go with it. I've kind of been thinking > we should wait for a broader consensus on which way to go with it... There needs to be a discussion fo

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 1:54 PM, Tom Lane wrote: > BEGIN; > TRUNCATE TABLE; > ... load new data ... > COMMIT; Because then you have to take an AccessExclusiveLock on the target table, of course. If we had some kind of TRUNCATE CONCURRENTLY, I think that'd address a large portion of the use case

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Simon Riggs
On Tue, 2010-12-14 at 13:54 -0500, Tom Lane wrote: > Simon Riggs writes: > > There are various applications where we want to completely replace the > > contents of a table with new/re-calculated data. > > > It seems fairly obvious to be able to do this like... > > 1. Prepare new data into "new_ta

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Tom Lane
Simon Riggs writes: > There are various applications where we want to completely replace the > contents of a table with new/re-calculated data. > It seems fairly obvious to be able to do this like... > 1. Prepare new data into "new_table" and build indexes > 2. Swap old for new > BEGIN; > DROP TA

Re: [HACKERS] Instrument checkpoint sync calls

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 11:47 AM, Alvaro Herrera wrote: >> > that I'm >> > uncomfortable with the idea of mdsync filling in the details for >> > CheckpointStats fields directly.  Would it work to pass a struct (say >> > SmgrSyncStats) from CheckPointBuffers to smgrsync and from there to >> > mdsyn

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 1:38 PM, Tom Lane wrote: > Robert Haas writes: >> So there are really four changes in here, right? > >> 1. Relax pg_read_file() to be able to read any files. >> 2. pg_read_binary_file() >> 3. pg_execute_sql_string()/file() >> 4. ability to read a file in a given encoding (

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Tom Lane
Robert Haas writes: > So there are really four changes in here, right? > 1. Relax pg_read_file() to be able to read any files. > 2. pg_read_binary_file() > 3. pg_execute_sql_string()/file() > 4. ability to read a file in a given encoding (rather than the client > encoding) > I think I agree tha

[HACKERS] ALTER TABLE ... REPLACE WITH

2010-12-14 Thread Simon Riggs
There are various applications where we want to completely replace the contents of a table with new/re-calculated data. It seems fairly obvious to be able to do this like... 1. Prepare new data into "new_table" and build indexes 2. Swap old for new BEGIN; DROP TABLE "old_table"; ALTER TABLE "new_

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 11:48 AM, Itagaki Takahiro wrote: > I'm confused which part of the patch is the point of the discussion. >  1. Relax pg_read_file() to be able to read any files. >  2. pg_read_binary_file() >  3. pg_execute_sql_string/file() > > As I pointed out, 1 is reasonable as long as

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Tom Lane
Oleg Bartunov writes: > On Tue, 14 Dec 2010, Robert Haas wrote: >> On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov wrote: >>> Just wondering about JSON, are there anyone who signed already to work on >>> JSON or it's just a theoretical discussions ? >> Three different people developed patches, a

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Tom Lane
Robert Haas writes: > 2010/12/14 Andrew Dunstan : >> On 12/14/2010 12:06 PM, Robert Haas wrote: >>> Not exactly, because in hstore all the element values have to be, >>> specifically, text.  Having hstores of other kinds of objects would, >>> presumably, be useful. >> I love hstore, and I've used

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Oleg Bartunov
On Tue, 14 Dec 2010, Robert Haas wrote: On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov wrote: Just wondering about JSON, are there anyone who signed already to work on JSON or it's just a theoretical discussions ? If so, I agree, having JSON properly implemented and simple wrapper for hstore

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

2010-12-14 Thread Tom Lane
Andrew Dunstan writes: > On 12/13/2010 04:34 PM, Tom Lane wrote: >> Oh really ... are we using src/port/unsetenv.c on that platform? >> I wonder if that little hack is incompatible with latest mingw >> libraries ... > It is using pgwin32_putenv() and pgwin32_unsetenv(). It appears not to > be re

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 12:25 PM, Oleg Bartunov wrote: > Just wondering about JSON, are there anyone who signed already to work on > JSON or it's just a theoretical discussions ? If so, I agree, having JSON > properly implemented and simple wrapper for hstore just for compatibility, > would > be v

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Oleg Bartunov
On Tue, 14 Dec 2010, Andrew Dunstan wrote: On 12/14/2010 12:06 PM, Robert Haas wrote: I haven't actually figured out what the benefit would be, other than buzzword compliance and a chance to invent some random nonstandard syntax. If the element values all have to be the same type, you've bas

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Oleg Bartunov
On Tue, 14 Dec 2010, Robert Haas wrote: On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote: Peter Eisentraut writes: On m?n, 2010-12-13 at 10:55 -0500, Tom Lane wrote: We don't normally invent specialized syntax for a specific datatype. Not even if it's in core. I think the idea would be t

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Robert Haas
2010/12/14 Tom Lane : > Robert Haas writes: >> On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote: >>> If the element values all have to be the same type, you've >>> basically got hstore. > >> Not exactly, because in hstore all the element values have to be, >> specifically, text.  Having hstores o

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Pavel Stehule
2010/12/14 Tom Lane : > Robert Haas writes: >> On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote: >>> If the element values all have to be the same type, you've >>> basically got hstore. > >> Not exactly, because in hstore all the element values have to be, >> specifically, text.  Having hstores o

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Robert Haas
2010/12/14 Andrew Dunstan : > On 12/14/2010 12:06 PM, Robert Haas wrote: >>> >>> I haven't actually figured out what the benefit would be, other than >>> buzzword compliance and a chance to invent some random nonstandard >>> syntax.  If the element values all have to be the same type, you've >>> ba

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

2010-12-14 Thread Andrew Dunstan
On 12/14/2010 12:10 PM, Tom Lane wrote: Andrew Dunstan writes: On 12/13/2010 06:45 PM, I wrote: [ problem on Mingw with 'FATAL: parameter "port" cannot be changed without restarting the server' if client connection options are sent ] Regina Obe has pointed out to me, and I have confirmed, t

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Andrew Dunstan
On 12/14/2010 12:06 PM, Robert Haas wrote: I haven't actually figured out what the benefit would be, other than buzzword compliance and a chance to invent some random nonstandard syntax. If the element values all have to be the same type, you've basically got hstore. Not exactly, because in h

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Tom Lane
Robert Haas writes: > On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote: >> If the element values all have to be the same type, you've >> basically got hstore. > Not exactly, because in hstore all the element values have to be, > specifically, text. Having hstores of other kinds of objects would

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

2010-12-14 Thread Tom Lane
Andrew Dunstan writes: > On 12/13/2010 06:45 PM, I wrote: >>> [ problem on Mingw with 'FATAL: parameter "port" cannot be changed >>> without restarting the server' if client connection options are sent ] > Regina Obe has pointed out to me, and I have confirmed, that this does > not happen with

Re: [HACKERS] BufFreelistLock

2010-12-14 Thread Jeff Janes
On Sun, Dec 12, 2010 at 6:48 PM, Jim Nasby wrote: > On Dec 10, 2010, at 10:49 AM, Tom Lane wrote: >> Alvaro Herrera writes: >>> Excerpts from Jeff Janes's message of vie dic 10 12:24:34 -0300 2010: As far as I can tell, bgwriter never adds things to the freelist. That is only done at st

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Tom Lane
Marko Tiikkaja writes: > On 2010-12-14 4:23 AM +0200, Tom Lane wrote: >> Uh, I don't think so. It sure looks like you have changed the user >> lockmethod to be transactional, ie, auto-release on commit/abort. > I was under the impression that passing sessionLock=true to > LockAcquire(), combine

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 11:51 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On mån, 2010-12-13 at 10:55 -0500, Tom Lane wrote: >>> We don't normally invent specialized syntax for a specific datatype. >>> Not even if it's in core. > >> I think the idea would be to make associative arrays a kin

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread David E. Wheeler
On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote: > A function with a hstore parameter called x would get a Python dictionary as > its input. A function said to be returning a hstore could return a dictionary > and if it would have only string keys/values, it would be changed into a > hstore (a

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

2010-12-14 Thread Tom Lane
Craig Ringer writes: > I've attached an updated patch that fixes a failure when compiling on > gcc/linux. The no-op inline installCrashDumpHandler() for unsupported > platforms was not declared static, so it was not being optimized out of > objects it wasn't used in and was causing symbol colli

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

2010-12-14 Thread Andrew Dunstan
On 12/13/2010 06:45 PM, I wrote: [ problem on Mingw with 'FATAL: parameter "port" cannot be changed without restarting the server' if client connection options are sent ] It appears not to be related to how the environment is set at all, but to how the backend is handling PGOPTIONS.

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

2010-12-14 Thread Chris Browne
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] hstores in pl/python

2010-12-14 Thread Dmitriy Igrishin
2010/12/14 Pavel Stehule > 2010/12/13 Dmitriy Igrishin : > > > > > > 2010/12/14 Pavel Stehule > >> > >> 2010/12/13 Dmitriy Igrishin : > >> > > >> > > >> > 2010/12/13 Pavel Stehule > >> >> > >> >> 2010/12/13 Dmitriy Igrishin : > >> >> > > >> >> > > >> >> > 2010/12/13 Pavel Stehule > >> >> >> >

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Tom Lane
Peter Eisentraut writes: > On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote: >> It would be cool to be able to transparently use hstores as Python >> dictionaries and vice versa. It would be easy enough with hstore as a >> core type, but with hstore as an addon it's not that easy. > I have

Re: [HACKERS] hstores in pl/python

2010-12-14 Thread Tom Lane
Peter Eisentraut writes: > On mån, 2010-12-13 at 10:55 -0500, Tom Lane wrote: >> We don't normally invent specialized syntax for a specific datatype. >> Not even if it's in core. > I think the idea would be to make associative arrays a kind of > second-order object like arrays, instead of a data

Re: [HACKERS] pg_execute_from_file, patch v10

2010-12-14 Thread Itagaki Takahiro
On Tue, Dec 14, 2010 at 18:01, Dimitri Fontaine wrote: >> In any case, I concur with what I gather Robert is thinking, which is >> that there is no good reason to be exposing any of this at the SQL level. > > That used to be done this way, you know, in versions between 0 and 6 of > the patch. Star

Re: [HACKERS] Instrument checkpoint sync calls

2010-12-14 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar dic 14 11:34:55 -0300 2010: > On Tue, Dec 14, 2010 at 9:29 AM, Alvaro Herrera > wrote: > > I gave this patch a look and it seems pretty good to me, except > > Err, woops. I just committed this as-is. Sorry. I noticed :-) > > that I'm > > uncomfortabl

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 10:48 AM, Itagaki Takahiro wrote: > On Tue, Dec 14, 2010 at 23:45, Robert Haas wrote: >>> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables. >> >> We do?  Why can't the support for updating foreign tables be built-in >> rather than trigger-based? > >

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread David Fetter
On Wed, Dec 15, 2010 at 12:48:59AM +0900, Itagaki Takahiro wrote: > On Tue, Dec 14, 2010 at 23:45, Robert Haas wrote: > >> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign > >> tables. > > > > We do?  Why can't the support for updating foreign tables be > > built-in rather than tr

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Itagaki Takahiro
On Tue, Dec 14, 2010 at 23:45, Robert Haas wrote: >> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables. > > We do?  Why can't the support for updating foreign tables be built-in > rather than trigger-based? Do we have any concrete idea for the built-in update feature? There

Re: [HACKERS] Tab completion for view triggers in psql

2010-12-14 Thread David Fetter
On Mon, Dec 13, 2010 at 10:48:54PM -0500, Robert Haas wrote: > On Tue, Nov 30, 2010 at 9:15 AM, David Fetter wrote: > >> Patch attached. If you think my changes are ok, > >> please change the patch status to "Ready for Committer". > > > > Done :) > > I have committed part of this patch. Great!

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Merlin Moncure
On Tue, Dec 14, 2010 at 9:51 AM, Tom Lane wrote: > Merlin Moncure writes: >> Not that I'm necessarily against the proposal, but what does this do >> that can't already be done by locking a table or a table's row? > > I agree with Andres' point about this: sometimes it'd be more convenient > for a

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Tom Lane
Robert Haas writes: > On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro > wrote: >> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables. > We do? Why can't the support for updating foreign tables be built-in > rather than trigger-based? It *has* to be built in. What exact

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Andrew Dunstan
On 12/14/2010 09:51 AM, Tom Lane wrote: Merlin Moncure writes: Not that I'm necessarily against the proposal, but what does this do that can't already be done by locking a table or a table's row? I agree with Andres' point about this: sometimes it'd be more convenient for an advisory lock to

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Tom Lane
Merlin Moncure writes: > Not that I'm necessarily against the proposal, but what does this do > that can't already be done by locking a table or a table's row? I agree with Andres' point about this: sometimes it'd be more convenient for an advisory lock to be released automatically at transaction

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro wrote: > On Tue, Dec 14, 2010 at 23:38, Robert Haas wrote: >> On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule >> wrote: On the other hand, I don't really see any advantage to allowing rules on foreign tables - ever.  Unless there's some

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 9:06 AM, Shigeru HANADA wrote: > I'll simplify the patch and post patches 1-4 of below first. > > > 1) Basic syntax for FOREIGN TABLE and FDW HANDLER > 2) FDW API and ForeignScan execution > # These patches are split just to make review easy. > > > 3) pgsql_fdw > 4) file_

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Itagaki Takahiro
On Tue, Dec 14, 2010 at 23:38, Robert Haas wrote: > On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule > wrote: >>> On the other hand, I don't really see any advantage to allowing rules >>> on foreign tables - ever.  Unless there's some reason we really need >>> that, my gut feeling would be to rip

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 1:16 AM, Pavel Stehule wrote: >> On the other hand, I don't really see any advantage to allowing rules >> on foreign tables - ever.  Unless there's some reason we really need >> that, my gut feeling would be to rip it out and forget about it. > > views, updateable views? W

Re: [HACKERS] Instrument checkpoint sync calls

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 9:29 AM, Alvaro Herrera wrote: > I gave this patch a look and it seems pretty good to me, except Err, woops. I just committed this as-is. Sorry. > that I'm > uncomfortable with the idea of mdsync filling in the details for > CheckpointStats fields directly.  Would it wo

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Andres Freund
On Tuesday 14 December 2010 15:19:32 Merlin Moncure wrote: > On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund wrote: > > On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote: > >> The lock space is the same though, but I don't feel strongly about it. > > > > I feel strongly that it needs the s

Re: [HACKERS] Instrument checkpoint sync calls

2010-12-14 Thread Alvaro Herrera
I gave this patch a look and it seems pretty good to me, except that I'm uncomfortable with the idea of mdsync filling in the details for CheckpointStats fields directly. Would it work to pass a struct (say SmgrSyncStats) from CheckPointBuffers to smgrsync and from there to mdsync, have this func

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Marko Tiikkaja
On 2010-12-14 4:19 PM +0200, Merlin Moncure wrote: On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund wrote: On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote: The lock space is the same though, but I don't feel strongly about it. I feel strongly that it needs the same locking space. I pr

Re: [HACKERS] Transaction-scope advisory locks

2010-12-14 Thread Merlin Moncure
On Tue, Dec 14, 2010 at 7:07 AM, Andres Freund wrote: > On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote: >> The lock space is the same though, but I don't feel strongly about it. > I feel strongly that it needs the same locking space. I pretty frequently have > the need for multiple clie

Re: [HACKERS] SQL/MED - core functionality

2010-12-14 Thread Shigeru HANADA
On Mon, 13 Dec 2010 21:51:40 -0500 Robert Haas wrote: > This actually doesn't apply cleanly. There's a hunk in pg_class.h > that is failing. I might have missed recent changes about pg_class.relistemp. I've fixed in local repo. > I think attgenoptions is a poor choice of name for the concept it

Re: [HACKERS] CommitFest wrap-up

2010-12-14 Thread Robert Haas
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote: >> - serializable lock consistency - I am fairly certain this needs >> rebasing.  I don't have time to deal with it right away.  That sucks, >> because I think this is a really important change. > I can try to find some time to update the patch

  1   2   >