On Mon, Nov 30, 2009 at 12:14 PM, Greg Smith g...@2ndquadrant.com 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
2009/12/5 Andrew Gierth and...@tao11.riddles.org.uk:
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
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 do
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
Description: GNU Zip compressed data
Hitoshi == Hitoshi Harada umi.tan...@gmail.com 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
On Sat, Dec 5, 2009 at 12:14 AM, Bruce Momjian br...@momjian.us 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
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 review it
On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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
On tor, 2009-12-03 at 10:09 -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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
PostgreSQL 8.3
Tim Bunce tim.bu...@pobox.com 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
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
Andrew Dunstan and...@dunslane.net 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
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, and no
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 it
On Sat, Dec 05, 2009 at 11:41:36AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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
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
marked
Tom Lane escribió:
David E. Wheeler da...@kineticode.com 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
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 easily moved
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
Robert Haas wrote:
On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus j...@agliodbs.com 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
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
it take
Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
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 reported yet
On Sat, 2009-12-05 at 15:43 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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 response.
On Fri, Dec 04, 2009 at 11:35:52AM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis pg...@j-davis.com 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
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 the
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
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
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 that
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 t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
I'm not sure why I said including ctid. We would have to
On Sat, Dec 5, 2009 at 8:13 PM, James Pye li...@jwp.name 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
Robert Haas robertmh...@gmail.com 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
On Sat, Dec 5, 2009 at 10:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
37 matches
Mail list logo
