On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
> On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
> > ...
>
> I'm not volunteering here, but having worked with the protocol, I do have a
> suggestion:
Thanks. Looks like good input. With the further clarification that we
use NOTIFY it seems a
On Sat, Dec 5, 2009 at 10:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think this line of thinking is on the right track. The server
>> should certainly not send back an immediate ERROR response, because
>> that will definitely confuse the client. Of course, any subsequent
>> commands will
Robert Haas writes:
> I think this line of thinking is on the right track. The server
> should certainly not send back an immediate ERROR response, because
> that will definitely confuse the client. Of course, any subsequent
> commands will report ERRORs until the client rolls back. But it also
On Sat, Dec 5, 2009 at 8:13 PM, James Pye wrote:
> I think the answer here is that the server should *not* report the
> cancellation.
>
> Rather, it should mark the transaction as failed and let the client
> eventually sync its state on subsequent requests that will result in
> InFailedTransact
It can save space because the line pointers have less alignment
requirements. But I don't see any point in the current state.
--
Greg
On 2009-12-04, at 3:48 PM, Tom Lane wrote:
Greg Stark writes:
I'm not sure why I said "including ctid". We would have to move
everything transactional to t
On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
> ...
I'm not volunteering here, but having worked with the protocol, I do have a
suggestion:
>> This allows locks to be released, but it is complex to report the
>> cancellation back to the client.
I think the answer here is t
Michael Paquier wrote:
> 3) Should consider how :variable interpretation should work in a
\[set]shell call
It is supported now. I implemented this, I made a test with your perl
script, my own tests and it worked, at least no error appeared :)
It looks like how you did this is a little less compl
Ron Mayer escreveu:
> While there's no great way to make this a contrib module today,
> would it make sense to add such hooks for an eventual module system?
>
I don't think so. It's easier to code a converter tool.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hac
On fre, 2009-09-25 at 00:55 +0200, Joachim Wieland wrote:
> the attached patch addresses the performance issues of the
> authorization related views from information_schema (BUG #4596). It
> implements what Tom suggests in
>
> http://archives.postgresql.org/pgsql-bugs/2008-12/msg00144.php
>
> In
On Fri, Dec 04, 2009 at 11:35:52AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis wrote:
> >> On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote:
> >>> I'm starting to go through this patch now. �I thought the
> >>> consensus was to refer to them as jus
On Sat, 2009-12-05 at 15:33 -0500, Tom Lane wrote:
> In any case there's no need for someone to move off a version instantly
> the day after the last release for it. So I really don't see why you
> think there would be "panic updates".
Hmm, well, I wasn't imagining it as a wholly rational respon
On Sat, 2009-12-05 at 15:43 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > I'm planning to read recovery.conf earlier in the startup process, so we
> > can make a few things more "recovery aware". It's a nice-to-have only.
>
> Say what? It's read at the beginning already.
Before the beginning
Simon Riggs wrote:
> On Fri, 2009-12-04 at 10:23 +0200, Heikki Linnakangas wrote:
>>> @Heikki: Why is error checking in KnownAssignedXidsRemove() #ifdef'd
>> out??
>>
>> It's explained in the comment:
>> /* XXX: This can still happen: If a transaction with a subtransaction
>> * that haven't been
Simon Riggs writes:
> I'm planning to read recovery.conf earlier in the startup process, so we
> can make a few things more "recovery aware". It's a nice-to-have only.
Say what? It's read at the beginning already.
regards, tom lane
--
Sent via pgsql-hackers mailing lis
Simon Riggs writes:
> Could I request we change these dates slightly to
The intent of the policy is that the last formal minor release for a
branch will happen no earlier than the specified times. It might well
be later, since we're not going to schedule updates specially for this
--- it'd be wh
Josh Berkus wrote:
>> ... YAML for easier readability ...
>
> "almost as good" ... I agree with Kevin that it's more readable.
>
> Again, if there were a sensible way to do YAML as a contrib module, I'd
> go for that, but there isn't.
Perhaps that's be a direction this could take? What would
i
Robert Haas wrote:
> On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus wrote:
>> Kaigai, you've said that you could get SELinux folks involved in the
>> patch review. I think it's past time that they were; please solicit them.
>
> Actually, we tried that already, in a previous iteration of this
> disc
I'd be very grateful to any hackers out there who are looking for a
project before close of 8.5 to consider working on this. It's dang
useful, both for Hot Standby and normal processing.
(You'll have the added bonus of proving you're smarter than me!)
On Wed, 2009-01-21 at 15:22 -0500, Bruce Momj
On Fri, 2009-12-04 at 19:49 -0500, Michael Glaesemann wrote:
> > I tested a variety of situations during my review, and everything
> > worked
> > as I expected.
>
> Would there be a way for you to package the scenarios you tested into
> a suite?
Except for the simplest tests, they aren't easi
Tom Lane escribió:
> "David E. Wheeler" writes:
> > Tom, what's your objection to Shlib load time being user-visible?
>
> It's not really designed to be user-visible. Let me give you just
> two examples:
>
> * We call a plperl function for the first time in a session, causing
> plperl.so to be
Simon Riggs wrote:
> On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
>
>> - The assumption that b-tree vacuum records don't need conflict
>> resolution because we did that with the additional cleanup-info record
>> works ATM, but it hinges on the fact that we don't delete any tuples
>
On Sat, Dec 05, 2009 at 11:41:36AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I'll modify the patch to disable the SPI functions during
> > initialization (both on_perl_init and on_(un)trusted_init).
>
> Yeah, in the shower this morning I was thinking that not loading
> SPI till after the on
I'm planning to read recovery.conf earlier in the startup process, so we
can make a few things more "recovery aware". It's a nice-to-have only.
This won't be part of the HS patch though.
Proposal is to split out the couple of lines in
readRecoveryCommandFile() that set important state and make i
On Fri, 2009-12-04 at 10:23 +0200, Heikki Linnakangas wrote:
>
> > @Heikki: Why is error checking in KnownAssignedXidsRemove() #ifdef'd
> out??
>
> It's explained in the comment:
> /* XXX: This can still happen: If a transaction with a subtransaction
> * that haven't been reported yet aborts, a
Andrew Dunstan writes:
> If we turn Tim's proposal down, I suspect someone will create a fork of
> plperl that allows it anyway - it's not like it needs anything changed
> elsewhere in the backend - it would be a drop-in replacement, pretty much.
The question is not about whether we think it's
Tim Bunce wrote:
That doesn't even begin to cover the problems with allowing any of
this to happen inside the postmaster. Recall that the postmaster
does not have any database access. Furthermore, it is a very long
established reliability principle around here that the postmaster
process shou
Tim Bunce writes:
> I'll modify the patch to disable the SPI functions during
> initialization (both on_perl_init and on_(un)trusted_init).
Yeah, in the shower this morning I was thinking that not loading
SPI till after the on_init code runs would alleviate the concerns
about transactionality an
On Fri, 2009-12-04 at 16:36 +, Dave Page wrote:
> End Of Life (EOL) dates:
>
> Version EOL Date
> PostgreSQL 7.4July 2010 (extended)
> PostgreSQL 8.0July 2010 (extended)
> PostgreSQL 8.1November 2010
> PostgreSQL 8.2December 2011
> Postgre
On tor, 2009-12-03 at 10:09 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Should we recast the attributes and columns views in information_schema?
> > I notice they still use attnum.
>
> I'd vote against it, at least until we have something better than a
> row_number solution. That would c
On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote:
> "David E. Wheeler" writes:
> > Tom, what's your objection to Shlib load time being user-visible?
>
> It's not really designed to be user-visible. Let me give you just
> two examples:
>
> * We call a plperl function for the first time i
Robert Haas wrote:
> > I offered to review it. ?I was going to mostly review the parts that
> > impacted our existing code, and I wasn't going to be able to do a
> > thorough job of the SE-Linux-specific files.
>
> Review it and commit it, after making whatever modifications are
> necessary? Or r
On Sat, Dec 5, 2009 at 12:14 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> Actually, we tried that already, in a previous iteration of this
>> discussion. Someone actually materialized and commented on a few
>> things. The problem, as I remember it, was that they didn't know much
>> about Pos
> "Hitoshi" == Hitoshi Harada writes:
Hitoshi> One thing for rule test, I checked existing regression test
Hitoshi> cases and concluded DROP VIEW is necessary, or even VIEW
Hitoshi> test for a specific feature is not needed. I remember your
Hitoshi> aggregate ORDER BY patch contains "rule
mber your aggregate ORDER BY patch
contains "rules" test changes. However, since processing order of
regression tests is not predictable and may change AFAIK, I guess it
shouldn't add those changes in rules.out.
Regards.
--
Hitoshi Harada
rows_frame_types.20091205.patch.gz
Descrip
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
> - The assumption that b-tree vacuum records don't need conflict
> resolution because we did that with the additional cleanup-info record
> works ATM, but it hinges on the fact that we don't delete any tuples
> marked as killed while we
2009/12/5 Andrew Gierth :
> 1) Memory context handling for aggregate calls
>
> aggcontext = AggGetMemoryContext(fcinfo->context);
> if (!aggcontext)
> ereport(...);
>
> For completeness, there should be two other functions: one to simply
> return whether we are in fact being called as
On Mon, Nov 30, 2009 at 12:14 PM, Greg Smith wrote:
> Jeff Davis wrote:
>
> COPY target FROM FUNCTION foo() WITH RECORDS;
>
>
> In what format would the records be?
As a not-quite aside, I think I have a better syntax suggestion. I
have recently been digging around in the grammar with the change
37 matches
Mail list logo