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
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
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
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
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
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
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
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
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
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
> 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
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
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,
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
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
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_
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
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
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
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
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".
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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))
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
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
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
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
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.
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
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
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;
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
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
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
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
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
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
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
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 (
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
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_
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
> >> >> >>
>
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
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
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
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
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?
>
>
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
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
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!
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
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
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
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
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
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_
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
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
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
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
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
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
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
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
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 - 100 of 111 matches
Mail list logo