On 17/09/10 01:35, Kevin Grittner wrote:
Heikki Linnakangas wrote:
The functions are well commented, but an overview at the top of
the file of all the hash tables and other data structures would be
nice. What is stored in each, when are they updated, etc.
I moved all the structures from pred
On Thu, Sep 16, 2010 at 4:18 AM, Simon Riggs wrote:
> We definitely have the time, so the question is, what are the best
> ideas?
Before advancing the review of each patch, we must determine what
should be committed in 9.1, and what's in this CF.
"Synchronization level on per-transaction" featur
Robert Haas wrote:
On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine
wrote:
I think they call that dynamic scope, in advanced programming
language. I guess that's calling for a quote of Greenspun's Tenth Rule:
Any sufficiently complicated C or Fortran program contains an ad hoc
informally-s
Thank you to the 4 people who replied.
Heikki Linnakangas wrote:
It's a known misfeature, PL/pgSQL isn't very smart about replacing variables
with parameter markers.
The good news is that this has been completely rewritten in 9.0. The above will
work in 9.0.
If you can't upgrade to 9.0, you'
2010/9/14 KaiGai Kohei :
> The attached patch is a revised version, but a bit difference from what
> I introduced yesterday.
I am working through this patch and fixing a variety of things things
that seem to need fixing. Please hang tight and don't send any new
versions for now.
Thanks,
--
Rob
On Fri, Sep 17, 2010 at 6:49 AM, fazool mein wrote:
> I am designing a heartbeat system between replicas to know when a replica
> goes down so that necessary measures can be taken. As I see, there are two
> ways of doing it:
>
> 1) Creating a separate heartbeat process on replicas.
> 2) Creating a
2010/9/15 SAKAMOTO Masahiko :
> This is a proposal patch for SQL/MED for 9.1.
> (1) foreign table DDL support (this proposal):
> - support for foreign table DDL syntax (CREATE/ALTER FOREIGN TABLE)
> - Definition of FDW routine interface and system catalogs for it.
I checked the patch. It
On 09/16/2010 08:50 PM, Tom Lane wrote:
Andrew Dunstan writes:
Looks like we're green on 9.0 for both MinGW and MSVC.
Would you kick brown_bat too so we can check the cygwin case?
Done. Looks fine.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
2010/9/15 Hitoshi Harada :
> 2010/9/15 Tom Lane :
>>
>> Well, I would think that the no-duplication rule applies to each WITH
>> list separately, not both together. If you do something like
>>
>> with t1 as (select * from foo)
>> select * from
>> (with t2 as (select * from foo)
>> select
Andrew Dunstan writes:
> Looks like we're green on 9.0 for both MinGW and MSVC.
Would you kick brown_bat too so we can check the cygwin case?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On 09/16/2010 05:29 PM, Andrew Dunstan wrote:
On 09/16/2010 04:37 PM, Magnus Hagander wrote:
On Thu, Sep 16, 2010 at 19:30, Tom Lane wrote:
Magnus Hagander writes:
So, it's been tested by at leasdt one EDB customer with success.
Do we want to sneak this in before we release 9.0.0?
I thi
2010/9/16 Tomáš Kovářík :
> Thanks Robert for the test on MacOS X. I wanted to be sure that it is
> not only my installation issue, so I tried the same on Windows Server
> 2003 with PostgreSQL 8.3; the same crash. Is there anybody who has
> written a C-function on Windows platform?
Maybe you shoul
On Thu, Sep 16, 2010 at 4:57 PM, Peter Eisentraut wrote:
> On tor, 2010-09-16 at 15:56 -0400, Robert Haas wrote:
>> I reiterate my earlier criticism of this whole approach: it seems to
>> assume that computing query progress is something inexpensive enough
>> that we can afford to do it regardless
Alvaro Herrera wrote:
> Now that I look at your new patch, I noticed that I was actually
> confusing relcache.h with rel.h. The latter includes a big chunk
> of our headers, but relcache.h is pretty thin. Including
> relcache.h in another header is not much of a problem.
OK, thanks for the c
Excerpts from Kevin Grittner's message of mié sep 15 14:52:36 -0400 2010:
> 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
Bruce Momjian writes:
> Tom Lane wrote:
>> This is essentially the same reason why CREATE DATABASE and related
>> commands xlog directory copy operations only after completing them.
>> That potentially wastes much more than a few blocks; but it's still
>> non-dangerous, and far safer than the alte
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 extend the relation a few tim
Heikki Linnakangas wrote:
> The functions are well commented, but an overview at the top of
> the file of all the hash tables and other data structures would be
> nice. What is stored in each, when are they updated, etc.
I moved all the structures from predicate.h and predicate.c to a new
pred
Kevin Grittner wrote:
> 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=contex
On Thu, Sep 16, 2010 at 08:43:37PM +0200, Pavel Stehule wrote:
> 2010/9/16 Peter Eisentraut :
> > On tis, 2010-09-07 at 20:35 +0200, Pavel Stehule wrote:
> >> I don't plan to try to move this module to core. And it's useless
> >> - other languages has not our problems.
> >
> > I don't know the deta
Hello everyone,
I am designing a heartbeat system between replicas to know when a replica
goes down so that necessary measures can be taken. As I see, there are two
ways of doing it:
1) Creating a separate heartbeat process on replicas.
2) Creating a heartbeat message, and sending it over the con
On 09/16/2010 04:37 PM, Magnus Hagander wrote:
On Thu, Sep 16, 2010 at 19:30, Tom Lane wrote:
Magnus Hagander writes:
So, it's been tested by at leasdt one EDB customer with success.
Do we want to sneak this in before we release 9.0.0?
I think we had consensus on applying the simple fix as
On tor, 2010-09-16 at 15:56 -0400, Robert Haas wrote:
> I reiterate my earlier criticism of this whole approach: it seems to
> assume that computing query progress is something inexpensive enough
> that we can afford to do it regardless of whether anyone is looking.
That assumption appears to hold
On Thu, Sep 16, 2010 at 19:30, Tom Lane wrote:
> Magnus Hagander writes:
>> So, it's been tested by at leasdt one EDB customer with success.
>
>> Do we want to sneak this in before we release 9.0.0?
>
> I think we had consensus on applying the simple fix as far back as we
> have the deadman switc
On Thu, Sep 16, 2010 at 2:52 PM, Peter Eisentraut wrote:
>> > a very simple query.
>> SELECT * FROM tbl;
>> can report reasonable progress, but
>> SELECT count(*) FROM tbl;
>> cannot, because planned_tuple_count of the aggregation is 1.
>> I hope better solutions for the grouping case because
On tor, 2010-09-16 at 15:47 +0900, Itagaki Takahiro wrote:
> On Tue, Aug 17, 2010 at 2:19 PM, Peter Eisentraut wrote:
> > VACUUM (lazy) (also autovacuum), table-rewriting ALTER TABLE
> We could also support VACUUM FULL, CLUSTER, CREATE INDEX and REINDEX.
Well, yeah, but those are a lot harder to
2010/9/16 Peter Eisentraut :
> On tis, 2010-09-07 at 20:35 +0200, Pavel Stehule wrote:
>> I don't plan to try to move this module to core. And it's useless -
>> other languages has not our problems.
>
> I don't know the details of what you're struggling with, but it's a bit
> hard to believe that t
Thank you. They did actually help me much. :)
On Thu, Sep 16, 2010 at 7:14 PM, Kevin Grittner wrote:
> Vaibhav Kaushal wrote:
>
> > please show me the way, at least to the terms which you people
> > use when developing.
>
> You should probably start with this page, and follow its links:
>
> htt
On tis, 2010-09-07 at 20:35 +0200, Pavel Stehule wrote:
> I don't plan to try to move this module to core. And it's useless -
> other languages has not our problems.
I don't know the details of what you're struggling with, but it's a bit
hard to believe that there is a problem that is absolutely u
> I think that if we make a habit of rewriting the contributions of
> first-time contributors in toto, we will have fewer second-time
> contributors. I think it would have been a good idea to discuss this
> on the list before you went and did it.
To be fair to Itagaki-san, he DID ask about the s
On Thu, Sep 16, 2010 at 1:20 PM, Markus Wanner wrote:
> On 09/16/2010 04:26 PM, Robert Haas wrote:
>>
>> I agree. I've already said my piece on how I think that stuff would
>> need to be reworked to be acceptable, so we might have to agree to
>> disagree on those, especially if your goal is to ge
Bruce Momjian writes:
> Can we assume all the mutexes will be cleaned up from a 128-exit?
In the deadman-switch case I think we're safe enough. I'm not convinced
at the moment that ignoring the error would be safe without that.
regards, tom lane
--
Sent via pgsql-hacke
Magnus Hagander writes:
> So, it's been tested by at leasdt one EDB customer with success.
> Do we want to sneak this in before we release 9.0.0?
I think we had consensus on applying the simple fix as far back as we
have the deadman switch code. If you can get it done in the next
few hours, go
Dave Page wrote:
> 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:
I assume we are going to summarize this in a C co
Morning,
On 09/16/2010 04:26 PM, Robert Haas wrote:
I agree. I've already said my piece on how I think that stuff would
need to be reworked to be acceptable, so we might have to agree to
disagree on those, especially if your goal is to get something
committed that doesn't involve a major rewrit
Thanks Robert for the test on MacOS X. I wanted to be sure that it is
not only my installation issue, so I tried the same on Windows Server
2003 with PostgreSQL 8.3; the same crash. Is there anybody who has
written a C-function on Windows platform?
Tomas
2010/9/15 Robert Haas :
> 2010/9/15 Tomáš
On Wed, Sep 15, 2010 at 19:25, Robert Haas wrote:
> 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
Excerpts from Darren Duncan's message of jue sep 16 02:33:37 -0400 2010:
> My impression of this is that Pg is treating the "a1" after the "AS" like it
> was
> a variable reference and so substituted it for $1.
Yes.
> Now that just seems wrong to me. I can understand either "a0" or "rv"
> get
Robert Haas writes:
> I plan to reserve judgment on the best way of managing the relevant
> state until such time as someone has gone to the trouble of
> identifying what state that is.
The really fundamental problem here is that you never will be able to
identify all such state. Even assuming t
On Thu, Sep 16, 2010 at 4:47 AM, Markus Wanner wrote:
>
> BTW, that'd be what I call a huge patch:
>
> bgworkers, excluding dynshmem and imessages:
> 34 files changed, 2910 insertions(+), 1421 deletions(-)
>
> from there to Postgres-R:
> 98 files changed, 14856 insertions(+), 230 deletions(-)
>
On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> One thing that strikes me (maybe this is obvious) is that the
>> execution of the main transaction and the autonomous transaction are
>> not interleaved: it's a stack. So in terms of globals and stuff,
>> assuming
On Wed, Sep 15, 2010 at 9:53 PM, Itagaki Takahiro
wrote:
> 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 di
On Wed, Sep 15, 2010 at 10:05:00PM -0400, Tom Lane wrote:
> 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 relati
Vaibhav Kaushal wrote:
> please show me the way, at least to the terms which you people
> use when developing.
You should probably start with this page, and follow its links:
http://www.postgresql.org/developer/
> I think its time I move on to the development section of the 9
> series of t
On Thu, Sep 16, 2010 at 4:49 PM, Abhijit Menon-Sen wrote:
> I looked at the patch and it seems quite reasonable, but two hunks of
> the changes to src/backend/commands/cluster.c don't apply cleanly.
Please read the thread. The patch is intended to be applied after
"sequence scan + sort for CLUSTE
Robert Haas writes:
> One thing that strikes me (maybe this is obvious) is that the
> execution of the main transaction and the autonomous transaction are
> not interleaved: it's a stack. So in terms of globals and stuff,
> assuming you knew which things needed to be updated, you could push
> all
Hi,
On 09/15/2010 07:30 PM, Robert Haas wrote:
One problem with autonomous transactions is that you have to figure
out where to store all the state associated with the autonomous
transaction and its subtransactions. Another is that you have to
avoid an unacceptable slowdown in the tuple-visibil
Hi,
On 09/15/2010 08:54 PM, Robert Haas wrote:
I think that the bar for committing to another in-core replication
solution right now is probably fairly high.
I'm not trying to convince you to accept the Postgres-R patch.. at least
not now.
BTW, that'd be what I call a huge patch:
bgworker
(Sorry for the broken threading. I didn't have a convenient copy of the
original message to reply to.)
I looked at the patch and it seems quite reasonable, but two hunks of
the changes to src/backend/commands/cluster.c don't apply cleanly. I'm
not sure what version the patch was generated against,
Hello all,
May be this is notneeded, but I thought I could just introduce myself to the
list and why am I here.
My name is Vaibhav Kaushal, a good leaner and a really bad student. I bunk
classes, don't attend exams and love to develop. I just completed my
engineering course in Information science
On 09/16/2010 02:33 AM, 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;
51 matches
Mail list logo
