> We don't need to be in a hurry here. As the reviewer I'm happy to give
> Leonardo some time, obviously no more than the end of the commit fest.
>
> If he doesn't respond at all, I'll do it, but I'd like to give him the
> chance and the experience if possible.
Sorry I couldn't update the pat
I've tried index tuples sorting on penalty function before buffer relocation
on split. But it was without any success. Index quality becomes even worse
than without sorting.
The next thing I've tried is buffer relocation between all neighbor buffers.
Results of first tests is much more promising. N
On Wed, Jun 15, 2011 at 11:21 AM, Alexander Korotkov
wrote:
> I've tried index tuples sorting on penalty function before buffer
> relocation on split. But it was without any success. Index quality becomes
> even worse than without sorting.
> The next thing I've tried is buffer relocation between a
> On Tue, Jun 14, 2011 at 2:31 PM, Simon Riggs wrote:
> Well, we certainly have the option to review and commit the patch any
> time up until feature freeze. However, I don't want the CommitFest
> application to be full of entries for patches that are not actually
> being worked on, because it
On 15 June 2011 07:09, Jaime Casanova wrote:
> On Tue, Jun 14, 2011 at 4:14 PM, Alvaro Herrera
> wrote:
>> Excerpts from Alvaro Herrera's message of lun jun 13 18:08:12 -0400 2011:
>>> Excerpts from Dean Rasheed's message of sáb jun 11 09:32:15 -0400 2011:
>>
>>> > I think that you also need to u
Here's the sort of thing every person who writes a monitoring tool
involving pg_stat_activity goes through:
1) Hurray! I know how to see what the database is doing now! Let me
try counting all the connections so I can finally figure out what to set
[max_connections | work_mem | other] to.
2)
On Jun 14, 2011, at 2:11 PM, Kevin Grittner wrote:
> Robert Creager wrote:
>
>> Stack trace, nothing else.
>
>> 3 postgres 0x00010005cafa
>> multixact_twophase_postcommit + 74 (multixact.c:1367)
>> 4 postgres 0x00010005deab
>> Proces
On 15.06.2011 10:24, Alexander Korotkov wrote:
On Wed, Jun 15, 2011 at 11:21 AM, Alexander Korotkov
wrote:
I've tried index tuples sorting on penalty function before buffer
relocation on split. But it was without any success. Index quality becomes
even worse than without sorting.
The next thing
On 15 June 2011 07:56, Jaime Casanova wrote:
> Hi,
>
> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
I just noticed that too, and was about to raise it as a bug.
If it is intended, then it's not documented.
I noticed it while browsing gram.y, and thought it looks a b
On Wed, Jun 15, 2011 at 12:03 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Is this relocation mechanism something that can be tuned, for different
> tradeoffs between index quality and build time?
>
Yes, it can. I believe that it can be index parameter.
> In any case, it
Following this whole conversation rises the impression the topic is
going to get lost in
nirvana of personal preferences.
Most suggestions on change for itself are likely to not cross the border of
"not justifying a compatibility break".
I wonder, whether the actual point really is towards compati
On Wed, Jun 15, 2011 at 00:01, Andrew Dunstan wrote:
>
> On 06/14/2011 05:45 PM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> On 06/13/2011 08:05 PM, Tom Lane wrote:
I looked into $SUBJECT. There appear to be two distinct issues:
...
>>>
>>> I think we can be a bit more li
On 14.06.2011 17:57, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I did some further changes, refactoring SkipSerialization so that
it's hopefully more readable, and added a comment about the
side-effects. See attached. Let me know if I'm missing something.
I do think the changes improve
> > On Wed, May 25, 2011 at 3:05 PM, Simon Riggs
wrote:
> > Leonardo, can you submit an updated version of this patch today that
> > incorporates Simon's suggestion?
Mmmh, maybe it was simpler than I thought; I must be
missing something... patch attached
How can I test it with "weird" s
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
* Is the SXACT_FLAG_ROLLED_BACK flag necessary? It's only set in
ReleasePredicateLocks() for a fleeting moment while the
function releases all conflicts and locks held by the
transaction, and finally the sxact stru
On Wed, Jun 15, 2011 at 10:53 AM, Ahmed Shinwari
wrote:
> Hi All,
>
> I faced a bug on Windows while connecting via SSPI authentication. I was
> able to find the bug and have attached the patch. Details listed below;
>
> Postgres Installer: Version 9.0.4
> OS: Windows Server 2008 R2/Windows 7
>
>
Hello Heikki,
probably I found a bug in patch:
CREATE FUNCTION fx(i integer) RETURNS integer
LANGUAGE plpgsql
AS $$begin raise notice '>>%<<', i; return i; end;$$;
CREATE FUNCTION fx1(integer) RETURNS text
LANGUAGE sql
AS $_$ select case $1 when 1 then 'A' else 'B' end$_$;
CREAT
Jesper Krogh wrote:
> On 2011-06-15 05:01, Bruce Momjian wrote:
> > You might remember we added a postmaster/postgres -b switch to indicate
> > binary upgrade mode. The attached patch prevents any client without an
> > application_name of 'binary-upgrade' from connecting to the cluster
> > while i
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > You might remember we added a postmaster/postgres -b switch to indicate
> > > binary upgrade mode. The attached patch prevents any client without an
> > > application_name of 'binary-upgrade' from connecting to the cluster
> >
On Wed, Jun 15, 2011 at 8:05 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>> > Bruce Momjian writes:
>> > > You might remember we added a postmaster/postgres -b switch to indicate
>> > > binary upgrade mode. The attached patch prevents any client without an
>> > > applicati
On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith wrote:
> The whole thing is enormously frustrating, and it's an advocacy problem--it
> contributes to people just starting to become serious about using PostgreSQL
> lowering their opinion of its suitability for their business. If this is
> what's inclu
On Tue, Jun 14, 2011 at 9:50 PM, Bruce Momjian wrote:
> Greg Smith wrote:
> > On 06/14/2011 06:00 PM, Tom Lane wrote:
> > > As far as Greg's proposal is concerned, I don't see how a proposed
> > > addition of two columns would justify renaming an existing column.
> > > Additions should not break
On Wed, Jun 15, 2011 at 8:47 AM, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith wrote:
> > The whole thing is enormously frustrating, and it's an advocacy
> problem--it
> > contributes to people just starting to become serious about using
> PostgreSQL
> > lowering their opinion
On Tue, Jun 14, 2011 at 9:08 PM, Josh Kupershmidt wrote:
> On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure wrote:
>> What I do wonder though is if the ; appending should really be
>> happening in printQuery() instead of in each query -- the idea being
>> that formatting for external consumption
On 06/14/2011 11:01 PM, Bruce Momjian wrote:
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This
On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be r
On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be r
On 06/14/2011 08:04 PM, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
For me, the litmus test is whether the change provides enough
improvement that it outweighs the disruption when the user runs into
it.
For the procpid that started all of this, the clear ans
On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh wrote:
> Why not expose this new information as functions instead of a new view, like
> we do for pg_is_in_replication(). People can use whatever alias they want in
> the queries they write.
>
> SELECT get_current_query(pid), is_idle(pid), is_idle_in_
On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 9:44 AM, Gurjeet Singh
> wrote:
> > Why not expose this new information as functions instead of a new view,
> like
> > we do for pg_is_in_replication(). People can use whatever alias they want
> in
> > the queries the
Gurjeet Singh writes:
> On Wed, Jun 15, 2011 at 10:31 AM, Robert Haas wrote:
>> Well, that would probably be a lot slower, and wouldn't necessarily
>> deliver as consistent a snapshot of system activity. It's better to
>> have one set-returning function that dumps out all the data in a
>> single
Dean Rasheed writes:
> On 15 June 2011 07:56, Jaime Casanova wrote:
>> Testing the CHECK NOT VALID patch i found $subject... is this intended?
> Aside from the ugliness of the code, we can't just add a
> ConstraintAttributeSpec to the second block, because that would
> enforce an order to these
Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
> On Wed, Jun 15, 2011 at 3:34 AM, Greg Smith wrote:
> > Putting on my stability hat instead of my "make it right" one, maybe this
> > really makes sense to expose as a view with a whole new name. Make this new
> > one pg_act
Heikki Linnakangas wrote:
>> There may be some places this can be checked which haven't yet
>> been identified and touched.
>
> Yeah - in 9.2.
No argument here. I'm all for stabilizing and getting the thing out
-- I think we've established that performance is good for many
workloads as it st
Due to unfortunate environmental conditions (don't ask) I've been
trying to get postgres 9.0 up and running on a fairly ancient linux --
redhat EL 3 which as kernel 2.4.21. initdb borks on the create
database step with the error message "child process exited with error
code 139". A bit of tracin
Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> 1. pg_upgrade invokes the postmaster with --binary-upgrade=:
>
> 2. postmaster starts up into multi-user mode, but it does not start
> autovacuum and ignores pg_hba.conf, listen_addresses, and port.
> Instead it listens only
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
>> Now, that's a suggestion I could very possibly get behind. Though the
>> fact that it would leave us with pg_activity / pg_stat_replication
>> seems less than ideal. Maybe pg_activity isn't the be
On Wed, Jun 15, 2011 at 11:12 AM, Merlin Moncure wrote:
> Due to unfortunate environmental conditions (don't ask) I've been
> trying to get postgres 9.0 up and running on a fairly ancient linux --
> redhat EL 3 which as kernel 2.4.21. initdb borks on the create
> database step with the error mes
Excerpts from Jaime Casanova's message of mié jun 15 02:09:15 -0400 2011:
> psql \h says (among other things) for ALTER TABLE
> """
>ADD table_constraint
>ADD table_constraint_using_index
>ADD table_constraint [ NOT VALID ]
> """
>
> ADD table_constraint appears twice and isn't true t
On Wed, Jun 15, 2011 at 12:13 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of mié jun 15 08:47:58 -0400 2011:
>>> Now, that's a suggestion I could very possibly get behind. Though the
>>> fact that it would leave us with pg_activity / pg_stat_replication
>>
hello ...
2.4? we know that some versions of 2.4 cause problems due to broken
posix_fadvise. if i remember correctly we built some configure magic into
PostgreSQL to check for this bug. what does this check do?
many thanks,
hans
On Jun 15, 2011, at 6:12 PM, Merlin Mo
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> At any rate, I like "sessions". That's what it is, after all. But I
> will note that we had better be darn sure to make all the changes we
> want to make in one go, because I dowanna have to create pg_sessions2
> (or pg_tessions?) in a year
On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> Seems good, except that passing the password as a command line argument
> is obviously broken from a privacy perspective -- anyone could see the
> process list and get
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
>> As a separate issue, I tend to agree with Tom that using psql as part
>> of the pg_upgrade process is a lousy idea and we need a better
>> solution. But let's fix one thing at a time.
> Agreed on
On 15 June 2011 17:12, Merlin Moncure wrote:
> Due to unfortunate environmental conditions (don't ask) I've been
> trying to get postgres 9.0 up and running on a fairly ancient linux --
> redhat EL 3 which as kernel 2.4.21. initdb borks on the create
> database step with the error message "child
--On 15. Juni 2011 16:47:55 + Greg Sabino Mullane wrote:
Or perhaps pg_connections. Yes, +1 to making things fully backwards
compatible by keeping pg_stat_activity around but making a better
designed and better named table (view/SRF/whatever).
I thought about that too when reading the t
On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
wrote:
> Hmm, I think this means we need to send a sinval message to invalidate
> cached plans when a constraint is validated. I'll see about this.
I feel like that really ought to be happening automatically, as a
result of committing the transact
STRICT functions return NULL if any of their inputs are NULL according
to the manual, so that they need not be executed at all.
Unless it is a Set Returning Function, in which case a NULL input is
not reduced nor does it to appear to be handled as a special case in
the executor function scan code.
Excerpts from Robert Haas's message of mié jun 15 12:53:59 -0400 2011:
> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
> wrote:
> > Hmm, I think this means we need to send a sinval message to invalidate
> > cached plans when a constraint is validated. I'll see about this.
>
> I feel like that
Merlin Moncure writes:
> Due to unfortunate environmental conditions (don't ask) I've been
> trying to get postgres 9.0 up and running on a fairly ancient linux --
> redhat EL 3 which as kernel 2.4.21. initdb borks on the create
> database step with the error message "child process exited with e
Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
> wrote:
> > Agreed on both counts ... but ... does this mean that we need a
> > different program for programmable tasks as opposed to interactive
> > ones? Dealing with sta
Excerpts from Tom Lane's message of mié jun 15 12:52:30 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> >> As a separate issue, I tend to agree with Tom that using psql as part
> >> of the pg_upgrade process is a lousy idea and we n
2011/6/15 PostgreSQL - Hans-Jürgen Schönig :
> hello ...
>
> 2.4? we know that some versions of 2.4 cause problems due to broken
> posix_fadvise. if i remember correctly we built some configure magic into
> PostgreSQL to check for this bug. what does this check do?
It doesn't check anything beyo
On Wed, Jun 15, 2011 at 1:13 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
>> wrote:
>
>> > Agreed on both counts ... but ... does this mean that we need a
>> > different program for programma
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mi?? jun 15 12:52:30 -0400 2011:
> > Alvaro Herrera writes:
> > > Excerpts from Robert Haas's message of mi?? jun 15 08:45:21 -0400 2011:
> > >> As a separate issue, I tend to agree with Tom that using psql as part
> > >> of the pg_upgrad
Robert Haas wrote:
> > Also, a standalone backend does not have libpq either so how do you get
> > values into application variables? ?Parse the text output? ?That seems
> > like a much larger kludge.
>
> Maybe we could do something like this.
>
> 1. pg_upgrade invokes the postmaster with --binar
On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> This requires no new backend code. We could even _require_ the port
> number to be specified in pg_upgrade.
+1... That seems to have lots of nice properties.
--
When confronted by a difficult problem, solve it by reducing it to the
questi
"Kevin Grittner" wrote:
> Unless I'm missing something, the only remaining changes needed
> are for documentation (as mentioned in previous posts).
I just found notes that we also need regression tests for the
SSI/DDL combination and a comment in lazy_truncate_heap.
At any rate, not anything
Christopher Browne writes:
> On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
>> [ just recommend using a different port number during pg_upgrade ]
> +1... That seems to have lots of nice properties.
Yeah, that seems like an appropriate expenditure of effort. It's surely
not bulletproof,
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 12:53:59 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
>> wrote:
>>> Hmm, I think this means we need to send a sinval message to invalidate
>>> cached plans when a constraint is validated. I'll see abou
Simon Riggs writes:
> STRICT functions return NULL if any of their inputs are NULL according
> to the manual, so that they need not be executed at all.
> Unless it is a Set Returning Function, in which case a NULL input is
> not reduced nor does it to appear to be handled as a special case in
> t
On Wed, Jun 15, 2011 at 4:54 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> On 15 June 2011 07:56, Jaime Casanova wrote:
>>> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
>> Aside from the ugliness of the code, we can't just add a
>> ConstraintAttributeSpec to the seco
On 06/12/2011 04:22 AM, Robert Haas wrote:
> One idea is that we could add outBuffer2/outBufSize2 to struct
> pg_conn, or something along those lines with less obviously stupid
> naming. Normally those would be unused, but in the special case where
> SSL indicates that we must retry the call with
Excerpts from Tom Lane's message of mié jun 15 14:49:04 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Robert Haas's message of mié jun 15 12:53:59 -0400 2011:
> >> On Wed, Jun 15, 2011 at 12:24 PM, Alvaro Herrera
> >> wrote:
> >>> Hmm, I think this means we need to send a sinval message
On Wed, Jun 15, 2011 at 8:05 PM, Tom Lane wrote:
> Simon Riggs writes:
>> STRICT functions return NULL if any of their inputs are NULL according
>> to the manual, so that they need not be executed at all.
>
>> Unless it is a Set Returning Function, in which case a NULL input is
>> not reduced nor
On ons, 2011-06-15 at 13:35 -0400, Bruce Momjian wrote:
> I now believe we are overthinking all this. pg_upgrade has always
> supported specification of a port number. Why not just tell users to
> specify an unused port number > 1023, and not to use the default
> value? Both old and new clusters
gcc 4.6 has now arrived as the default compiler on my desktop, and as
previously reported, it throws a bunch of warnings, foiling my life-long
plan of compiling PostgreSQL with -Werror.
So looking more aggressively into fixing some of these, let's look at
this case:
gistutil.c: In function ‘gistM
Excerpts from Tom Lane's message of mié jun 15 11:54:25 -0400 2011:
> Dean Rasheed writes:
> > On 15 June 2011 07:56, Jaime Casanova wrote:
> >> Testing the CHECK NOT VALID patch i found $subject... is this intended?
>
> > Aside from the ugliness of the code, we can't just add a
> > ConstraintAt
On Wed, Jun 15, 2011 at 3:14 PM, Alvaro Herrera
wrote:
>
> So is somebody from 2nd Quadrant going to supply a patch to fix this?
>
well, i was going to give it a try... but in a couple of hours...
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Another set of new gcc 4.6 warnings:
readfuncs.c: In function ‘_readCaseWhen’:
readfuncs.c:875:567: warning: variable ‘token’ set but not used
[-Wunused-but-set-variable]
readfuncs.c: In function ‘_readFromExpr’:
readfuncs.c:1159:568: warning: variable ‘token’ set but not used
[-Wunused-but-set-
The attached patch updates README-SSI. In addition to some minor edits,
changes include:
- add a section at the beginning that more clearly describes the SSI
rule and defines "dangerous structure" with a diagram. It describes
the optimizations we use about the relative commit times, and the
On Wed, Jun 15, 2011 at 9:14 PM, Alvaro Herrera
wrote:
> So is somebody from 2nd Quadrant going to supply a patch to fix this?
My understanding was that your patch had a bug, rather than the
existing code. If I misunderstood, please explain the bug.
In terms of "2ndQuadrant" supplying patches,
Hackers,
The first commitfest for PostgreSQL 9.2 has now started.
As such, if you have a patch for 9.2 which was not yet submitted, you
should add it to CommitFest 2011-9
(https://commitfest.postgresql.org/action/commitfest_view?id=11).
Currently we have 53 open patches. 17 of them need reviewe
On tis, 2011-06-14 at 18:09 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 06/14/2011 05:45 PM, Tom Lane wrote:
> >> I've committed patches that fix these issues on my own OS X machine,
>
> > Well, OSX is just using our usual *nix paraphernalia, so if it's broken
> > won't all such platf
Excerpts from Simon Riggs's message of mié jun 15 16:31:45 -0400 2011:
> On Wed, Jun 15, 2011 at 9:14 PM, Alvaro Herrera
> wrote:
>
> > So is somebody from 2nd Quadrant going to supply a patch to fix this?
>
> My understanding was that your patch had a bug, rather than the
> existing code. If I
Tom Lane wrote:
> Christopher Browne writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort.
Peter Eisentraut wrote:
> On ons, 2011-06-15 at 13:35 -0400, Bruce Momjian wrote:
> > I now believe we are overthinking all this. pg_upgrade has always
> > supported specification of a port number. Why not just tell users to
> > specify an unused port number > 1023, and not to use the default
> >
Alvaro Herrera writes:
> So is somebody from 2nd Quadrant going to supply a patch to fix this?
I'm already on it. The whole patch appears to need some review,
considering this is about the fourth major flaw we've found in it.
regards, tom lane
--
Sent via pgsql-hackers
Peter Eisentraut writes:
> As a secondary point, we have so far used mostly single quotes for
> quoting the installation directories, in case someone wants to try other
> funny characters besides spaces. The most recent patch uses double
> quotes. I'm not sure what degree of support we want to a
On Wed, Jun 15, 2011 at 9:59 PM, Alvaro Herrera
wrote:
> Excerpts from Simon Riggs's message of mié jun 15 16:31:45 -0400 2011:
>> On Wed, Jun 15, 2011 at 9:14 PM, Alvaro Herrera
>> wrote:
>>
>> > So is somebody from 2nd Quadrant going to supply a patch to fix this?
>>
>> My understanding was tha
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> On non-Windows servers you could get this even safer by disabling the
>> TCP/IP socket altogether, and placing the Unix-domain socket in a
>> private temporary directory. The "port" wouldn't actually matter then.
> Yes, it would be nice to just
On Wed, Jun 15, 2011 at 10:42 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> So is somebody from 2nd Quadrant going to supply a patch to fix this?
>
> I'm already on it. The whole patch appears to need some review,
> considering this is about the fourth major flaw we've found in it.
I'll leave
Peter Eisentraut writes:
> Is this a route we want to go down?
> - GISTENTRY vector[1]; /* variable-length array */
> + GISTENTRY vector[FLEXIBLE_ARRAY_MEMBER];
Yes, I was thinking about the same trick after noting these warnings on
Fedora 15, although personally
On Tue, Jun 14, 2011 at 5:28 AM, Noah Misch wrote:
> On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote:
>> On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas wrote:
>> > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote:
>> >> Assuming that conclusion, I do think it's worth starting
>> >> wi
Simon Riggs writes:
> On Wed, Jun 15, 2011 at 8:05 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> So a function that is both STRICT and SET RETURNING will return rows.
>> Really? The case behaves as expected for me.
> Seems that's the wrong question. Let me return to why I raised this:
> Why
Peter Eisentraut writes:
> I couldn't see a way good way of programming around this (perhaps in the
> second case, but it would get uselessly ugly), so perhaps just marking
> the variables as potentially unused would be appropriate? See patch.
Of course this would break not only on non-gcc compi
Alvaro Herrera writes:
> Here's an updated patch fixing all of the above. I stole your first
> test case and added it to regression, after some editorialization.
I've probably created some merge conflicts for you in process of fixing
the FOREIGN KEY NOT VALID patch, but in any case you need to c
On Thu, Jun 16, 2011 at 12:24 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, Jun 15, 2011 at 8:05 PM, Tom Lane wrote:
>>> Simon Riggs writes:
So a function that is both STRICT and SET RETURNING will return rows.
>
>>> Really? The case behaves as expected for me.
>
>> Seems that's th
All,
I've trolled this list, and I think I added in all patches which were
submitted here but not on the commitfest app. Can someone double-check
for me?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Tom Lane wrote:
> Christopher Browne writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort.
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> I have researched this and need feedback.
In general, I like the whole idea of using random/special ports for the
duration of the upgrade. I agree that we need to keep the ability to
check the existing clusters. My gut feeling is this: keep t
On Wed, Jun 15, 2011 at 8:54 PM, Josh Berkus wrote:
> I've trolled this list, and I think I added in all patches which were
> submitted here but not on the commitfest app. Can someone double-check
> for me?
There's a "read and heed" that's appropriate here...
As hard as we may try, if you imag
Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > I have researched this and need feedback.
>
> In general, I like the whole idea of using random/special ports for the
> duration of the upgrade. I agree that we need to keep the abil
* Bruce Momjian (br...@momjian.us) wrote:
> Having long options mean different than short options seems very
> confusing.
Err, that wasn't what I was proposing.. Just having:
--old-port-during-upgrade
and similar would have to be used if they want to specify the ports to
be used during the upgra
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian (br...@momjian.us) wrote:
> > Having long options mean different than short options seems very
> > confusing.
>
> Err, that wasn't what I was proposing.. Just having:
> --old-port-during-upgrade
>
> and similar would have to
I wrote:
> Peter Eisentraut writes:
>> As a secondary point, we have so far used mostly single quotes for
>> quoting the installation directories, in case someone wants to try other
>> funny characters besides spaces. The most recent patch uses double
>> quotes. I'm not sure what degree of suppo
Florian Pflug writes:
> Comments are extremely welcome, especially ones regarding
> the overall approach taken in this patch. If people consider
> that to be acceptable, I'd try to add the missing features
> and add documentation.
Quite honestly, I don't like this one bit and would rather you not
Bruce Momjian writes:
> I have researched this and need feedback. Initially I wanted to use a
> single -p port flag to be used by the old and new clusters. However,
> pg_upgrade allows --check mode while the old server is running, so we
> need to allow you to use the current old postmaster port
Tom Lane wrote:
> Bruce Momjian writes:
> > I have researched this and need feedback. Initially I wanted to use a
> > single -p port flag to be used by the old and new clusters. However,
> > pg_upgrade allows --check mode while the old server is running, so we
> > need to allow you to use the cu
On Wed, Jun 15, 2011 at 09:14:16PM -0400, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > I have researched this and need feedback.
>
> In general, I like the whole idea of using random/special ports for the
> duration of the upgrade. I agree that we need to kee
1 - 100 of 107 matches
Mail list logo
