On Thu, Sep 16, 2010 at 3:15 PM, SAKAMOTO Masahiko
wrote:
> This is designed to be used in the executor module.
> The API has some simple interfaces, such as FreeConnection,
> Open, Iterate, Close, ReOpen, and OnError.
Of course they are similar APIs mentioned in the SQL standard, but
I'm not sur
On Tue, Aug 17, 2010 at 2:19 PM, Peter Eisentraut wrote:
> Here is a small prototype for a query progress indicator.
I read and tested the patch. Here are comments to the code itself.
- Oid of pg_stat_get_backend_progress() must be changed because we are using
the id for another function.
- On
On 16/09/10 09:33, Darren Duncan wrote:
I don't know if this is a bug or not, but if not, it looks like a
misfeature ...
When executing the following in Pg 8.4.4:
CREATE OR REPLACE FUNCTION f () RETURNS TABLE(a1 INTEGER) AS
$BODY$
BEGIN
RETURN QUERY SELECT a0 AS a1 FROM rv;
RETURN;
END;
$BODY$
Hello
2010/9/16 Darren Duncan :
> I don't know if this is a bug or not, but if not, it looks like a misfeature
> ...
>
> When executing the following in Pg 8.4.4:
>
> CREATE OR REPLACE FUNCTION f () RETURNS TABLE(a1 INTEGER) AS
> $BODY$
> BEGIN
> RETURN QUERY SELECT a0 AS a1 FROM rv;
> RE
I don't know if this is a bug or not, but if not, it looks like a misfeature ...
When executing the following in Pg 8.4.4:
CREATE OR REPLACE FUNCTION f () RETURNS TABLE(a1 INTEGER) AS
$BODY$
BEGIN
RETURN QUERY SELECT a0 AS a1 FROM rv;
RETURN;
END;
$BODY$
LANGUAGE plpgsql;
..
And this is sample script to play the feature of this patch.
It includes:
- create foreign data wrapper and foreign server(PG at localhost)
- select foreign PostgreSQL table.
*Important*
This script initializes your database cluster(specified by $PGDATA).
Run with care
Regards,
SAKAMOTO
Folks,
If it weren't for the last minute, nothing would ever get done. In
the hallowed tradition of Commitfests, and the Feature Freezes that
preceded them, the past week has been a flurry of activity: 11
actions today, 23 yesterday, 42 actions this week, 29 last...all in
all, it's shaping up to
2010/9/16 Mark Kirkwood :
> On 16/09/10 14:05, Robert Haas wrote:
>>
>> On Wed, Sep 15, 2010 at 9:22 PM, Tom Lane wrote:
>>
>>>
>>> Hitoshi Harada writes:
>>>
2010/9/16 Robert Haas:
>
> Oh, key-value store, I bet. Yeah, that would be cool.
>
>>>
>>>
That's it
On Thu, Sep 16, 2010 at 1:23 PM, Fujii Masao wrote:
>> Fujii-san suggested that we might have a user-defined function for
>> triggering failover as well.
>
> The attached patch introduces such a user-defined function. This is
> useful especially when clusterware like pgpool-II is located in remote
On Wed, Sep 15, 2010 at 10:55 PM, Tom Lane wrote:
> So I'm wondering if we couldn't eliminate the five-second sleep
> requirement here too.
That would make the shutdown time longer since startup process currently
cannot respond to SIGTERM and SIGHUP immediately. To avoid this, I think
that we sho
On Wed, Sep 15, 2010 at 11:14 PM, Heikki Linnakangas
wrote:
>> (One issue is that it's not clear what that'd translate to on Windows.)
>
> pg_ctl failover ? At the moment, the location of the trigger file is
> configurable, but if we accept a constant location like "$PGDATA/failover"
> pg_ctl coul
On Wed, Sep 15, 2010 at 10:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 15, 2010 at 9:16 PM, Tom Lane wrote:
>>> That design is intentional. If the file create fails, and you've
>>> already written a WAL record that says you created it, you are flat
>>> out screwed. You can't ev
Robert Haas writes:
> On Wed, Sep 15, 2010 at 9:16 PM, Tom Lane wrote:
>> That design is intentional. If the file create fails, and you've
>> already written a WAL record that says you created it, you are flat
>> out screwed. You can't even PANIC --- if you do, then the replay of
>> the WAL rec
On 16/09/10 14:05, Robert Haas wrote:
On Wed, Sep 15, 2010 at 9:22 PM, Tom Lane wrote:
Hitoshi Harada writes:
2010/9/16 Robert Haas:
Oh, key-value store, I bet. Yeah, that would be cool.
That's it. Like Redis, Tokyo Cabinet, or something.
What exa
2010/9/15 Heikki Linnakangas :
> The API needs to be simple and version-independent, so that you can
> write simple wrappers like the flat file wrapper easily. At the same
> time, it needs to be very flexible, so that it allows safely pushing
> down all kinds constructs like functions, aggregates a
On Wed, Sep 15, 2010 at 9:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> I notice that RelationCreateStorage() creates the main fork on disk
>> before writing (let alone flushing) WAL. So if PG gets killed at that
>> point, we end up with an orphaned file on disk. I think that we could
>> even
On Wed, Sep 15, 2010 at 9:22 PM, Tom Lane wrote:
> Hitoshi Harada writes:
>> 2010/9/16 Robert Haas :
>>> Oh, key-value store, I bet. Yeah, that would be cool.
>
>> That's it. Like Redis, Tokyo Cabinet, or something.
>
> What exactly do those get you that an ordinary index, or at worst an
> index
Mark Kirkwood writes:
> On 16/09/10 13:22, Tom Lane wrote:
>> What exactly do those get you that an ordinary index, or at worst an
>> index-organized table, doesn't get you?
> It is pretty rare to see key value stores vs relational engines
> discussed without a descent into total foolishiness, b
On Thu, Sep 16, 2010 at 9:44 AM, Robert Haas wrote:
> Did you extract this from his work, or is this completely independent?
> I'm a bit disinclined to say we should just toss overboard all the
> work that's already been done. Why did you write a new patch?
I read his patch and am inspired by t
On 16/09/10 13:22, Tom Lane wrote:
Hitoshi Harada writes:
2010/9/16 Robert Haas:
Oh, key-value store, I bet. Yeah, that would be cool.
That's it. Like Redis, Tokyo Cabinet, or something.
What exactly do those get you that an ordinary index, or at worst an
index-o
Hitoshi Harada writes:
> 2010/9/16 Robert Haas :
>> Oh, key-value store, I bet. Yeah, that would be cool.
> That's it. Like Redis, Tokyo Cabinet, or something.
What exactly do those get you that an ordinary index, or at worst an
index-organized table, doesn't get you?
r
Robert Haas writes:
> I notice that RelationCreateStorage() creates the main fork on disk
> before writing (let alone flushing) WAL. So if PG gets killed at that
> point, we end up with an orphaned file on disk. I think that we could
> even extend the relation a few times before WAL gets written
2010/9/16 Robert Haas :
> On Wed, Sep 15, 2010 at 8:57 PM, Robert Haas wrote:
>> On Wed, Sep 15, 2010 at 8:53 PM, Hitoshi Harada wrote:
>>> 2010/9/16 Robert Haas :
On Wed, Sep 15, 2010 at 3:00 PM, Tom Lane wrote:
> Yet there are other cases that probably *could* work well based on a
>>>
On Wed, Sep 15, 2010 at 8:57 PM, Robert Haas wrote:
> On Wed, Sep 15, 2010 at 8:53 PM, Hitoshi Harada wrote:
>> 2010/9/16 Robert Haas :
>>> On Wed, Sep 15, 2010 at 3:00 PM, Tom Lane wrote:
Yet there are other cases that probably *could* work well based on a
storage-level abstraction bo
2010/9/16 Robert Haas :
> On Wed, Sep 15, 2010 at 3:00 PM, Tom Lane wrote:
>> Yet there are other cases that probably *could* work well based on a
>> storage-level abstraction boundary; index-organized tables for instance.
>> So I think we need to have some realistic idea of what we want to
>> sup
On Wed, Sep 15, 2010 at 8:53 PM, Hitoshi Harada wrote:
> 2010/9/16 Robert Haas :
>> On Wed, Sep 15, 2010 at 3:00 PM, Tom Lane wrote:
>>> Yet there are other cases that probably *could* work well based on a
>>> storage-level abstraction boundary; index-organized tables for instance.
>>> So I think
On Wed, Sep 15, 2010 at 7:23 PM, Itagaki Takahiro
wrote:
> On Thu, Sep 16, 2010 at 1:45 AM, David E. Wheeler
> wrote:
>>> We have "JSON datatype (WIP) 01" item:
>>> https://commitfest.postgresql.org/action/patch_view?id=351
>>> but it seems too complex for me to apply all of the feature
>>> at
On Wed, Sep 15, 2010 at 6:21 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010:
>
>> I guess so, but the devil is in the details. I suspect that we don't
>> actually want to fork a new backend for every autonomous transactions.
>> That would be pre
nevermind... I see standbys.conf is now used.
sorry for the noise...
Erik Rijkers
On Thu, September 16, 2010 01:12, Erik Rijkers wrote:
> On Wed, September 15, 2010 11:58, Fujii Masao wrote:
>> On Wed, Sep 15, 2010 at 6:38 AM, David Fetter wrote:
>>> Now that the latch patch is in, when do yo
On Thu, Sep 16, 2010 at 1:45 AM, David E. Wheeler wrote:
>> We have "JSON datatype (WIP) 01" item:
>> https://commitfest.postgresql.org/action/patch_view?id=351
>> but it seems too complex for me to apply all of the feature
>> at once, especially JSON-Path support. So, I'd like to submit
>> only
On Wed, September 15, 2010 11:58, Fujii Masao wrote:
> On Wed, Sep 15, 2010 at 6:38 AM, David Fetter wrote:
>> Now that the latch patch is in, when do you think you'll be able to use it
>> instead of the poll loop?
>
> Here is the updated version, which uses a latch in communication from
> walsend
I notice that RelationCreateStorage() creates the main fork on disk
before writing (let alone flushing) WAL. So if PG gets killed at that
point, we end up with an orphaned file on disk. I think that we could
even extend the relation a few times before WAL gets written, so I
don't even think it's
Excerpts from Robert Haas's message of mié sep 15 14:57:29 -0400 2010:
> I guess so, but the devil is in the details. I suspect that we don't
> actually want to fork a new backend for every autonomous transactions.
> That would be pretty expensive, and we already have an expensive way
> of emula
On Tue, 2010-09-14 at 18:48 +0100, Simon Riggs wrote:
> I'm working on a patch to implement synchronous replication for
> PostgreSQL, with user-controlled durability specified on the master. The
> design also provides high throughput by allowing concurrent processes to
> handle the WAL stream. The
On Tue, Sep 14, 2010 at 04:06, Andrew Dunstan wrote:
>
>
> On 09/13/2010 09:30 PM, Itagaki Takahiro wrote:
>>
>> Hi,
>>
>> Anyone working on JSON datatype?
>> If no, I'm going to submit simplified version of JSON datatype patch.
>>
>
> What's the state of the GSOC project?
Well, GSoC itself is ov
Folks,
If you've got a patch you want to have as part of this commitfest and
it's not already on the page, you have until 2200 PST8PDT to get it on
there.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: dav
On Wed, Sep 15, 2010 at 3:00 PM, Tom Lane wrote:
> Well, the problem is to not draw the abstraction boundary so high that
> your plugins have to reimplement the world to get anything done.
> mysql got this wrong IMO, and are still paying the price in the form of
> bizarre functional incompatibilit
On Wed, Sep 15, 2010 at 3:18 PM, Simon Riggs wrote:
> Will finishing it help?
Yes, I expect that to help a lot.
> Before, I had no patch. Now mine "isn't finished". At what point will my
> ideas be reviewed without instant dismissal? If we accept your seniority
> argument, then "never" because e
Robert Haas wrote:
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan wrote:
The point being, the answer to how to implement autonomous transactions
could be as simple as, do the same thing as how you manage multiple
concurrent client sessions, more or less. If each client gets its own
Postgres OS
On Wed, 2010-09-15 at 13:58 -0400, Robert Haas wrote:
> > It's not actually a major issue, but at some point I have to ask for
> no
> > more commits, so Fujii and I can finish our patches, compare and
> > contrast, so the best ideas can get into Postgres.
>
> I don't think anyone is prepared to ag
Robert Haas writes:
> 2010/9/15 Heikki Linnakangas :
>> I've been thinking about that for some time. Here's one sketch I made a
>> while ago:
>> http://archives.postgresql.org/pgsql-hackers/2008-07/msg00395.php.
> I wonder if we might not think of the foreign data wrapper problem as
> an instance
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan wrote:
> The point being, the answer to how to implement autonomous transactions
> could be as simple as, do the same thing as how you manage multiple
> concurrent client sessions, more or less. If each client gets its own
> Postgres OS process, then
On Wed, Sep 15, 2010 at 2:28 PM, Markus Wanner wrote:
>> I guess the real issue here is whether it's possible to, and whether
>> you're interested in, extracting a committable subset of this work,
>> and if so what that subset should look like.
>
> Well, as it doesn't currently provide any real be
Alvaro Herrera wrote:
> I think that would also solve a concern that I had, which is that
> we were starting to include relcache.h (and perhaps other headers
> as well, but that's the one that triggered it for me) a bit too
> liberally, so +1 from me.
Unfortunately, what I proposed doesn't sol
On Wed, Sep 15, 2010 at 2:28 PM, Heikki Linnakangas
wrote:
> On 15/09/10 21:21, Robert Haas wrote:
>>
>> I wonder if we might not think of the foreign data wrapper problem as
>> an instance of an even more general problem. Right now, we have
>> semi-pluggable index access methods - it's probably
Robert Haas wrote:
On Wed, Sep 15, 2010 at 3:37 AM, Colin 't Hart wrote:
I note that the implementation of tab completion for SET TRANSACTION in PSQL
could benefit from the implementation of autonomous transactions (also
TODO).
I think it's safe to say that if we ever manage to get autonomous
Excerpts from Kevin Grittner's message of mié sep 15 09:15:53 -0400 2010:
> I'm inclined to move everything except the function prototypes out
> of predicate.h to a new predicate_interal.h, and move the structures
> defined in predicate.c there, too.
I think that would also solve a concern that I
Robert,
On 09/15/2010 07:23 PM, Robert Haas wrote:
I haven't scrutinized your code but it seems like the
minimum-per-database might be complicating things more than necessary.
You might find that you can make the logic simpler without that. I
might be wrong, though.
I still think of that as
On 15/09/10 21:21, Robert Haas wrote:
I wonder if we might not think of the foreign data wrapper problem as
an instance of an even more general problem. Right now, we have
semi-pluggable index access methods - it's probably not quite possible
to implement one as a standalone module because of XL
2010/9/15 Heikki Linnakangas :
> In my mind the key question is: what does the API for writing foreign
> data wrappers look like? I couldn't figure that out by looking at the patch.
>
> The API needs to be simple and version-independent, so that you can
> write simple wrappers like the flat file wr
On 15/09/10 20:58, Robert Haas wrote:
On Wed, Sep 15, 2010 at 1:30 PM, Simon Riggs wrote:
On Wed, 2010-09-15 at 12:45 -0400, Robert Haas wrote:
On Wed, Sep 15, 2010 at 11:24 AM, Simon Riggs wrote:
I agree that asking people to stop work is not OK. However, I haven't
asked for development wor
I just discovered the --patience flag on the git diff command, and
I'd like to suggest that we encourage people to use it when possible
for building patches. I just looked at output with and without it
(and for good measure, before and after filterdiff --format=context
for both), and the results w
On Wed, Sep 15, 2010 at 1:30 PM, Simon Riggs wrote:
> On Wed, 2010-09-15 at 12:45 -0400, Robert Haas wrote:
>> On Wed, Sep 15, 2010 at 11:24 AM, Simon Riggs wrote:
>> > I agree that asking people to stop work is not OK. However, I haven't
>> > asked for development work to stop, only that commits
2010/9/15 Tomáš Kovářík :
> I am trying to create a simple c-language function for "PostgreSQL
> 8.4.4, compiled by Visual C++ build 1400, 32-bit" running on Windows 7
> (32-bit). It works, until I use a SPI.
>
> 1) CRASH: I successfully execute a simple query using SPI_exec(), but
> when getting t
On Wed, 2010-09-15 at 12:45 -0400, Robert Haas wrote:
> On Wed, Sep 15, 2010 at 11:24 AM, Simon Riggs wrote:
> > I agree that asking people to stop work is not OK. However, I haven't
> > asked for development work to stop, only that commits into that area
> > stop until proper debate has taken pla
On Wed, Sep 15, 2010 at 3:37 AM, Colin 't Hart wrote:
> I note that the implementation of tab completion for SET TRANSACTION in PSQL
> could benefit from the implementation of autonomous transactions (also
> TODO).
I think it's safe to say that if we ever manage to get autonomous
transactions wor
On Wed, Sep 15, 2010 at 4:03 AM, Dave Page wrote:
> Therefore I cannot give you specific areas where this will happen. Of
> course when systems are low on resources or they are completely
> depleted (100% CPU) things will stop working
Of course. As we all know, degrading gracefully under load i
On Wed, Sep 15, 2010 at 2:48 AM, Markus Wanner wrote:
>> Hmm. So what happens if you have 1000 databases with a minimum of 1
>> worker per database and an overall limit of 10 workers?
>
> The first 10 databases would get an idle worker. As soon as real jobs
> arrive, the idle workers on databases
On Sep 15, 2010, at 5:23 AM, Simon Riggs wrote:
> Fast, efficient, no extra code.
I love that sentence. Even if it has no verb.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Sep 14, 2010, at 7:32 PM, Itagaki Takahiro wrote:
> Here is a patch for basic JSON support. It adds only those features:
> * Add "json" data type, that is binary-compatible with text.
> * Syntax checking on text to JSON conversion.
> * json_pretty() -- print JSON tree with indentation.
>
>
On Wed, Sep 15, 2010 at 12:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 15, 2010 at 12:14 PM, Tom Lane wrote:
>>> The above scenario is only a risk if you suppose that dropping a
>>> relation that lacks physical storage will nonetheless result in
>>> attempted unlink()s. I think
On Wed, Sep 15, 2010 at 11:24 AM, Simon Riggs wrote:
> I agree that asking people to stop work is not OK. However, I haven't
> asked for development work to stop, only that commits into that area
> stop until proper debate has taken place. Those might be minor commits,
> but they might not. Had I
Robert Haas writes:
> On Wed, Sep 15, 2010 at 12:14 PM, Tom Lane wrote:
>> The above scenario is only a risk if you suppose that dropping a
>> relation that lacks physical storage will nonetheless result in
>> attempted unlink()s. I think that that's probably not the case;
> Why? How would we
On Wed, Sep 15, 2010 at 12:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> After further reflection, I think that the above reasoning is wrong.
>> GetNewRelFileNode() guarantees that the OID doesn't collide with the
>> OID column of pg_class, not the relfilenode column of pg_class; and,
>> per th
Robert Haas writes:
> After further reflection, I think that the above reasoning is wrong.
> GetNewRelFileNode() guarantees that the OID doesn't collide with the
> OID column of pg_class, not the relfilenode column of pg_class; and,
> per the comments to that function, it only guarantees this when
On Wed, 2010-09-15 at 07:59 -0700, David Fetter wrote:
> On Wed, Sep 15, 2010 at 03:35:30PM +0100, Simon Riggs wrote:
> > Please desist while we resolve which are the good ideas and which are
> > not. We won't know that if you keep breaking other people's patches in a
> > stream of commits that pr
On Wed, Sep 15, 2010 at 03:35:30PM +0100, Simon Riggs wrote:
> On Wed, 2010-09-15 at 20:14 +0900, Fujii Masao wrote:
> > On Wed, Sep 15, 2010 at 7:35 PM, Heikki Linnakangas
> > wrote:
> > > Log Message:
> > > ---
> > > Use a latch to make startup process wake up and replay immediately when
On Wed, 2010-09-15 at 20:14 +0900, Fujii Masao wrote:
> On Wed, Sep 15, 2010 at 7:35 PM, Heikki Linnakangas
> wrote:
> > Log Message:
> > ---
> > Use a latch to make startup process wake up and replay immediately when
> > new WAL arrives via streaming replication. This reduces the latency,
On 15/09/10 16:55, Tom Lane wrote:
So I'm wondering if we couldn't eliminate the five-second sleep
requirement here too. It's problematic anyhow, since somebody looking
for energy efficiency will still feel it's too short, while somebody
concerned about fast failover will feel it's too long.
Y
hei...@postgresql.org (Heikki Linnakangas) writes:
> Log Message:
> ---
> Use a latch to make startup process wake up and replay immediately when
> new WAL arrives via streaming replication. This reduces the latency, and
> also allows us to use a longer polling interval, which is good for e
Heikki Linnakangas wrote:
> Now that I understand what the predicate locks are for, I'm now
> trying to get my head around all the data structures in
> predicate.c. The functions are well commented, but an overview at
> the top of the file of all the hash tables and other data
> structures woul
On Wed, 2010-09-15 at 11:54 +0300, Heikki Linnakangas wrote:
> On 14/09/10 20:48, Simon Riggs wrote:
> > When each new messages arrives from master the WALreceiver will write
> > the new data to the WAL file, wake the WALwriter and then reply. Each
> > new message from master receives a reply. If n
On 14/09/10 20:48, Simon Riggs wrote:
When each new messages arrives from master the WALreceiver will write
the new data to the WAL file, wake the WALwriter and then reply. Each
new message from master receives a reply. If no further WAL data has
been received the WALreceiver waits on the latch.
On Fri, Sep 10, 2010 at 1:45 PM, Bruce Momjian wrote:
>
> I am not sure how clear it is on Win32 that 128 is a special return
> code.
I asked Microsoft platform support (roughly) that question. Here's the response:
=
>From NTSTATUS.H
//
// The success status codes 128 - 191 are reserved for
On 15/09/10 00:49, Kevin Grittner wrote:
Heikki Linnakangas wrote:
A short description of how the predicate locks help to implement
serializable mode would be nice too. I haven't read Cahill's
papers, and I'm left wondering what the RW conflicts and
dependencies are, when you're supposed to gr
Hi,
I note that the implementation of tab completion for SET TRANSACTION in PSQL
could benefit from the implementation of autonomous transactions (also
TODO).
Regards,
Colin
Hi,
I'm resending it to here, since I didn't got no response from the
"general" group.
I am trying to create a simple c-language function for "PostgreSQL
8.4.4, compiled by Visual C++ build 1400, 32-bit" running on Windows 7
(32-bit). It works, until I use a SPI.
1) CRASH: I successfully execute
On Wed, 2010-09-15 at 09:40 +0300, Heikki Linnakangas wrote:
> > However, if the following clause is ever invoked, then the loop does
> > have problems and we leave when not caught up.
> >
> > if (!PostmasterIsAlive(true))
> > exit(1);
>
> As the comment above that says, that's just an escape
On 15/09/10 08:46, SAKAMOTO Masahiko wrote:
> This is a proposal patch for SQL/MED for 9.1.
>
> At the prev. CF, this patch had so many features to make it hard
> to review all of them. So I devided it into smaller parts:
> (1) foreign table DDL support (this proposal):
> - support for fo
On 15/09/10 05:47, Tom Lane wrote:
Fujii Masao writes:
In HEAD, OwnLatch can elog during holding the spinlock WalSnd->mutex.
This seems to be unsafe
Even if it were safe, holding a spinlock through non-straight-line code
is a complete violation of the spinlock coding rules re the length of
ti
Hi,
On 09/15/2010 03:44 AM, Robert Haas wrote:
Hmm. So what happens if you have 1000 databases with a minimum of 1
worker per database and an overall limit of 10 workers?
The first 10 databases would get an idle worker. As soon as real jobs
arrive, the idle workers on databases that don't ha
81 matches
Mail list logo
