At the risk of excluding people...
I know that 2ndQuadrant and Command Prompt will develop features for
hire. I'm not sure if EnterpriseDB will or not.
And yes, post is pgsql-jobs.
On Jan 23, 2009, at 3:10 AM, Carlos Gonzalez-Cadenas wrote:
Yes it's an option, but you cannot rely on the typ
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple change.
Will be possible to set more locales and run tests without recompilation
on al
Simon Riggs wrote:
On Thu, 2009-01-22 at 22:35 +, Simon Riggs wrote:
* Bug fix v9 over next few days
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
master:
=# create database test
> Uh well, i'd be happier if such review comments would have been made earlier
> in the CommitFest.
Well, as one of original reviewers of this patch, I feel a little bad
that I didn't consider these issues - the rules looked messy to me,
but I didn't consider that the whole approach might be wrong
Jaime Casanova writes:
> On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane wrote:
>> Perhaps the right answer is to invent some new rule syntax to "redirect"
>> inserts/updates/deletes, say something like
>> on update to foo do instead redirect to bar
> and what about default values?
I don't see the is
--On 23. Januar 2009 18:07:38 -0500 Jaime Casanova
wrote:
and what about default values? if we redirect we will have to use the
table's default (something i like) and AFAIU we won't have the ability
to change it for the view at least not without manually create a new
DO INSTEAD rule (someth
--On 23. Januar 2009 18:02:55 -0500 Jaime Casanova
wrote:
to be honest, i feel like that was commented in the last (or the last
before the last) release cycle well this patch originally appears.
I know that i've changed something in the operator lookup code regarding
some discussions las
On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane wrote:
>
> Perhaps the right answer is to invent some new rule syntax to "redirect"
> inserts/updates/deletes, say something like
>
>on update to foo do instead redirect to bar
>
> and then put some logic that's not so much different from what you'
--On 23. Januar 2009 17:32:55 -0500 Tom Lane wrote:
Bernd Helmle writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane wrote:
In short, I don't feel that this was ready to be applied.
Uh well, i'd be happier if such review comments would have been made
earlier in the CommitFest.
[ shr
On Fri, Jan 23, 2009 at 5:52 PM, Josh Berkus wrote:
> Bernd,
>
> If it makes you feel any better, I certainly didn't think of the operator
> issue, and neither did Robert.
>
to be honest, i feel like that was commented in the last (or the last
before the last) release cycle well this patch origin
Oleg Bartunov writes:
> yesterday, testing GIN fast update with CVS HEAD I was able to crash backend
> (Teodor already fixed the problem in 0.25 version of the patch)
> and after restarting backend I found duplicated tables.
> How this can be possible and is this what somebody can see after cras
Euler Taveira de Oliveira wrote:
Bryce Nesbitt escreveu:
Here's a revision (thanks Robert Treat for the spelling corrextion).
If there are no other objections, how do I nominate it for consideration?
Added to next commit fest [1].
Um, not necessary. We're still accepting new doc patches, an
Bernd,
To be honest: I'm disappointed. If it tooks only a few steps to identify
those (obviously important) issues, i get the opinion that there's very
few motivating interest in this functionality (And yes, i'm annoyed
about myself to not consider those operator issues).
Well, that *is* the
On Fri, 2009-01-23 at 17:32 -0500, Tom Lane wrote:
> Bernd Helmle writes:
> > --On 23. Januar 2009 13:28:27 -0500 Tom Lane wrote:
> >> In short, I don't feel that this was ready to be applied.
>
> > Uh well, i'd be happier if such review comments would have been made
> > earlier in the CommitFe
Bernd Helmle writes:
> --On 23. Januar 2009 13:28:27 -0500 Tom Lane wrote:
>> In short, I don't feel that this was ready to be applied.
> Uh well, i'd be happier if such review comments would have been made
> earlier in the CommitFest.
[ shrug... ] I've been busting my butt since 1 November t
Bryce Nesbitt escreveu:
> Here's a revision (thanks Robert Treat for the spelling corrextion).
> If there are no other objections, how do I nominate it for consideration?
>
Added to next commit fest [1].
[1] http://wiki.postgresql.org/wiki/CommitFest_2009-First
--
Euler Taveira de Oliveira
On Fri, 2009-01-23 at 20:13 +, Greg Stark wrote:
> > If you have a serializable transaction with subtransactions that
> > suffers
> > a serializability error it only cancels the current subtransaction.
>
> This is a complete tangent to your work, but I wonder if this is
> really right. I m
Simon Riggs writes:
> On Fri, 2009-01-23 at 10:33 -0500, Tom Lane wrote:
>> Right, the WAL-record-processing API is not really at issue, since it's
>> been proven internally to the core code. My concern is with the other
>> part, namely exactly how are we going to identify and install additional
Bryce Nesbitt wrote:
Here's a revision (thanks Robert Treat for the spelling corrextion).
If there are no other objections, how do I nominate it for consideration?
-Bryce
You already have.
Mind you, in the future when you're not continuing a discussion from a
code patch, you
Hello
I tested patch v2.0, and I thing, so this patch should be used as bug
fix. It has same or little bit better speed than current and solve
some problems with numeric's implicit casting in plpgsql. But this is
only an half solution.
The core of problem is in lazy casting of plpgsql. We need to
Bernd Helmle wrote:
> If i understand you correctly we have the choice between
>
> a) revert this patch, fix all remaining issues which will likely postpone
> this for 8.5
> b) don't revert, but try to fix the issues currently existing in HEAD.
c) revert and expect an updated patch to apply very
Bruce Momjian wrote:
Well, this helps explain why were are getting these problems reports
only now. How many hacks do you have that we don't support, aside from
the threading one for HPUX?
We submit them as we find them. We've submitted for windows, hpux,
solaris and aix. Still have not t
Here's a revision (thanks Robert Treat for the spelling corrextion).
If there are no other objections, how do I nominate it for consideration?
-Bryce
Index: pg_dump.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/
--On 23. Januar 2009 13:28:27 -0500 Tom Lane wrote:
In short, I don't feel that this was ready to be applied. It's probably
fixable with a week or so's work, but do we want to be expending that
kind of effort on it at this stage of the release cycle?
Uh well, i'd be happier if such revie
Hi there,
yesterday, testing GIN fast update with CVS HEAD I was able to crash backend
(Teodor already fixed the problem in 0.25 version of the patch)
and after restarting backend I found duplicated tables.
How this can be possible and is this what somebody can see after crash ?
List
Merlin Moncure wrote:
> On 1/23/09, Tom Lane wrote:
> > Right at the moment I'm wondering why we are going to change the code
> > now to support a ten-year-old OS version that evidently no one has tried
> > to use Postgres on before.
>
> I'd like to address this observation. You may have noti
If you have a serializable transaction with subtransactions that
suffers
a serializability error it only cancels the current subtransaction.
This is a complete tangent to your work, but I wonder if this is
really right. I mean it's not as if we could have srrialized the
transaction a
On Fri, 2009-01-23 at 10:33 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-01-22 at 18:45 -0500, Tom Lane wrote:
> >> There are other recent examples of proposed hooks that in fact
> >> failed to be useful because of some oversight or other, and it was
> >> not until we insisted on
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
> >> Correct me if I'm wrong, but I thought the idea of this new conflict
> >> resolution was that the startup process doesn't need to wait for the
> >> target backend to die. Instead, the target backend knows to commit
> >> suicide
Andrew Chernow writes:
> Tom Lane wrote:
>> Were you hoping this would get back-patched, and if so how far?
> No, we don't need a back-patch. We need way too many features in 8.4
> ... like the really amazing libpq-events feature :)
OK, applied to HEAD with some tiny editorialization.
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> If you have a serializable transaction with subtransactions that suffers
>> a serializability error it only cancels the current subtransaction. That
>> means it's snapshot is still valid and can be used again. By analogy, as
>> long as a transaction
Tom Lane wrote:
Andrew Chernow writes:
Tom Lane wrote:
Hmm ... so actually we could get *rid* of that special case if we added
this one. Okay, I withdraw the complaint.
Done.
Were you hoping this would get back-patched, and if so how far?
No, we don't need a back-patch. We need way
Andrew Chernow writes:
> Tom Lane wrote:
>> Hmm ... so actually we could get *rid* of that special case if we added
>> this one. Okay, I withdraw the complaint.
> Done.
Were you hoping this would get back-patched, and if so how far?
regards, tom lane
--
Sent via pgsql
Simon Riggs wrote:
On Fri, 2009-01-23 at 17:51 +0200, Heikki Linnakangas wrote:
ISTM that if ReadBuffer read the value directly from the PGPROC entry,
there would be no need for the signaling (in the ERROR mode).
That is possible and I considered it. If we did it that way we would
need to read
Merlin Moncure wrote:
On 1/23/09, Tom Lane wrote:
Right at the moment I'm wondering why we are going to change the code
now to support a ten-year-old OS version that evidently no one has tried
to use Postgres on before.
I'd like to address this observation. You may have noticed that eSilo
Tom Lane wrote:
Andrew Chernow writes:
Tom Lane wrote:
BTW, what about the comments in ip.c to the effect that some versions of
AIX fail when getaddrinfo's second argument *is* null?
For starters, it indicates that sin_port is not zero'd properly. That
wouldn't matter here since the plan i
Simon Riggs wrote:
If you have a serializable transaction with subtransactions that suffers
a serializability error it only cancels the current subtransaction. That
means it's snapshot is still valid and can be used again. By analogy, as
long as a transaction does not see any data that is inconsi
On Fri, 2009-01-23 at 12:17 -0600, Kevin Grittner wrote:
> >>> Simon Riggs wrote:
> > There are considerable benefits to having it turned on during PITR
> >
> > Please read this to see why
> >
> http://wiki.postgresql.org/wiki/Hot_Standby#Dynamic_Control_of_Recovery
>
> Am I reading this righ
On Fri, 2009-01-23 at 18:22 +0200, Heikki Linnakangas wrote:
> > @@ -1601,6 +1602,24 @@ BufferProcessRecoveryConflictsIfAny(volatile
> > BufferDesc *bufHdr)
> > {
> > XLogRecPtr bufLSN = BufferGetLSN(bufHdr);
> >
> > + /*
> > +* If the
On Fri, 2009-01-23 at 17:51 +0200, Heikki Linnakangas wrote:
> In ERROR mode, you don't really want to interrupt the target backend. In
> ReadBuffer, you're checking a global variable,
> BufferRecoveryConflictPending on each call, and if it's set, you check
> the buffer's LSN against the LSN o
Andrew Chernow writes:
> Tom Lane wrote:
>> BTW, what about the comments in ip.c to the effect that some versions of
>> AIX fail when getaddrinfo's second argument *is* null?
> For starters, it indicates that sin_port is not zero'd properly. That
> wouldn't matter here since the plan is to manu
pet...@postgresql.org (Peter Eisentraut) writes:
> Automatic view update rules
This patch is still a few bricks shy of a load ... within a few moments
of starting to look at it I'd noticed two different failure conditions
regression=# \d box_tbl
Table "public.box_tbl"
Column | Type | Modifier
>>> Simon Riggs wrote:
> There are considerable benefits to having it turned on during PITR
>
> Please read this to see why
>
http://wiki.postgresql.org/wiki/Hot_Standby#Dynamic_Control_of_Recovery
Am I reading this right? What I get out of it is that users can
connect to the database during
Alvaro Herrera escribió:
> Here's my proposed patch. There is a bug in the handling of TOAST
> tables; I'm sending this as a WIP to add it to the commitfest status
> page for this patch.
Sorry, that was a really stupid bug.
--
Alvaro Herrerahttp://www.CommandPro
On Fri, 2009-01-23 at 10:35 -0600, Kevin Grittner wrote:
> >>> Alvaro Herrera wrote:
> > Simon Riggs wrote:
> >>
> >> It is on by default. Why would you want it "off" by default?
> >
> > Would it slow down the normal recovery after a crash if I don't have
> > any slaves?
>
> And how about d
On 1/23/09, Tom Lane wrote:
> Right at the moment I'm wondering why we are going to change the code
> now to support a ten-year-old OS version that evidently no one has tried
> to use Postgres on before.
I'd like to address this observation. You may have noticed that eSilo
has been contributi
On Fri, 2009-01-23 at 13:28 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Fri, 2009-01-23 at 11:28 -0300, Alvaro Herrera wrote:
>
> > > Depends on the setting :-) It is "hot_standby=off" by default, right?
> > > I think having a double negative "disable_hot_standby=off" would be
Tom Lane wrote:
BTW, what about the comments in ip.c to the effect that some versions of
AIX fail when getaddrinfo's second argument *is* null?
For starters, it indicates that sin_port is not zero'd properly. That
wouldn't matter here since the plan is to manually set the port in this
case,
BTW, what about the comments in ip.c to the effect that some versions of
AIX fail when getaddrinfo's second argument *is* null?
Right at the moment I'm wondering why we are going to change the code
now to support a ten-year-old OS version that evidently no one has tried
to use Postgres on before.
> Could also be something like "allow_connections_during_recovery".
+1 (should we say "continuous recovery?")
> I'd keep the word "replication" out of this..
+1.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Andrew Chernow writes:
> Tom Lane wrote:
>> The portability risk is in the "manually set the port" part.
> Right. If this method is limited to _AIX and only when the failure case
> occurs, there are no portability issues.
That seems like unnecessary complexity (which carries its own risks).
I
>>> Alvaro Herrera wrote:
> Simon Riggs wrote:
>>
>> It is on by default. Why would you want it "off" by default?
>
> Would it slow down the normal recovery after a crash if I don't have
> any slaves?
And how about during "traditional" PITR recovery?
-Kevin
--
Sent via pgsql-hackers mail
Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-01-23 at 11:28 -0300, Alvaro Herrera wrote:
Depends on the setting :-) It is "hot_standby=off" by default, right?
I think having a double negative "disable_hot_standby=off" would be
awkward.
It is on by default. Why would you want it "off
Simon Riggs wrote:
>
> On Fri, 2009-01-23 at 11:28 -0300, Alvaro Herrera wrote:
> > Depends on the setting :-) It is "hot_standby=off" by default, right?
> > I think having a double negative "disable_hot_standby=off" would be
> > awkward.
>
> It is on by default. Why would you want it "off" by
On Fri, 2009-01-23 at 17:07 +0200, Heikki Linnakangas wrote:
> Merlin Moncure wrote:
> > Is 'hot standby' going to be the official moniker for the feature?
> > (not 'standby replication', or something else?). I wonder if we
> > should pick something more descriptive.
>
> Could also be something l
@@ -1601,6 +1602,24 @@ BufferProcessRecoveryConflictsIfAny(volatile BufferDesc
*bufHdr)
{
XLogRecPtr bufLSN = BufferGetLSN(bufHdr);
+ /*
+* If the buffer is recent we may need to cancel ourselves
+* rather than risk ret
Simon Riggs wrote:
On Fri, 2009-01-23 at 16:14 +0200, Heikki Linnakangas wrote:
I made a couple of minor changes after importing your
patches.
I've applied them both to v9g, attached here.
If you wouldn't mind redoing the initial step, I will promise not to do
anything else to the code, exc
The FATAL and ERROR cancellation modes are quite different. In FATAL
mode, you just want to kill the backend. The target connection doesn't
need to know the LSN.
In ERROR mode, you don't really want to interrupt the target backend. In
ReadBuffer, you're checking a global variable,
BufferRecov
Tom Lane wrote:
Andrew Chernow writes:
Bruce Momjian wrote:
Why would we risk breaking other platforms to avoid an AIX bug? At best
we can put a code comment in that section of the code.
IMO, there is no risk. getaddrinfo allows a NULL second argument on
every platform I have worked with.
"Albe Laurenz" writes:
> Heikki Linnakangas wrote:
>> Well, the documentation states the reason to do that:
>>
>> This is an important safety feature to preserve the
>> integrity of your archive in case of administrator error
>> (such as sending the output of two different servers to the
>> sa
Simon Riggs writes:
> On Thu, 2009-01-22 at 18:45 -0500, Tom Lane wrote:
>> There are other recent examples of proposed hooks that in fact
>> failed to be useful because of some oversight or other, and it was
>> not until we insisted on seeing a live use of the hooks that this
>> became apparent.
On Fri, 2009-01-23 at 11:28 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Fri, 2009-01-23 at 12:58 +0200, Devrim GÜNDÜZ wrote:
> > > On Fri, 2009-01-23 at 10:05 +, Simon Riggs wrote:
> > > > I'll add it now, default = on.
> > >
> > > Did you mean "off"?
> >
> > No, do you?
>
Zdenek Kotala writes:
> Alvaro Herrera pÃÅ¡e v pá 23. 01. 2009 v 11:04 -0300:
>> Do you have an example use case for this?
> I use it in my space reservation patch. I going to send it soon.
Haven't we been over that ground already? A user-settable reloption
is not a reasonable solution to a s
Hi Emmanuel,
Please find my comments in-lined:
On 1/23/09, Emmanuel Cecchet wrote:
>
> Amit,
>
> You might want to put this on the
> http://wiki.postgresql.org/wiki/Table_partitioning wiki page.
Sure.
How does your timeline look like for this implementation?
The implementation is planned a
Andrew Chernow writes:
> Bruce Momjian wrote:
>> Why would we risk breaking other platforms to avoid an AIX bug? At best
>> we can put a code comment in that section of the code.
> IMO, there is no risk. getaddrinfo allows a NULL second argument on
> every platform I have worked with.
The por
Heikki Linnakangas writes:
> Merlin Moncure wrote:
>> Is 'hot standby' going to be the official moniker for the feature?
>> (not 'standby replication', or something else?). I wonder if we
>> should pick something more descriptive.
>
> Could also be something like "allow_connections_during_recove
On Fri, 2009-01-23 at 08:20 +0100, Albe Laurenz wrote:
> > Perhaps it should suggest
> > something like:
> >
> > test ! -f .../%f && cp %p .../%f.tmp && mv .../%f.tmp .../%f
> >
> > ie. copy under a different filename first, and rename the file in place
> > after it's completely written, assu
Bruce Momjian wrote:
If you really want this platform to work, I would submit a patch that
tests for a C compiler symbol or #define that is only defined for that
platform and make service = null in that case.
I am not aware of such an animal. I looked at the output of " touch x.c
&& gcc -v
Merlin Moncure wrote:
Is 'hot standby' going to be the official moniker for the feature?
(not 'standby replication', or something else?). I wonder if we
should pick something more descriptive.
Could also be something like "allow_connections_during_recovery".
I'd keep the word "replication" ou
On Fri, Jan 23, 2009 at 10:10:55AM +0100, Carlos Gonzalez-Cadenas wrote:
> Yes it's an option, but you cannot rely on the typical consulting company to
> do that. Do you know any specialized consulting boutique or individual
> developer that could do that?
Sending an email to pgsql-j...@postgresql
On 1/23/09, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Fri, 2009-01-23 at 12:58 +0200, Devrim GÜNDÜZ wrote:
> > > On Fri, 2009-01-23 at 10:05 +, Simon Riggs wrote:
> > > > I'll add it now, default = on.
> > >
> > > Did you mean "off"?
> >
> > No, do you?
>
>
> Depends on the
Andrew Chernow wrote:
> Christopher Browne wrote:
> > FYI: There are AIX 5.3 nodes on BuildFarm - if the change is a
> > regression, it will be noticed :-).
> >
>
> This confirms that its an isolated AIX 4.3 bug.
It confirms that the bug exists in 4.3 but not on 5.3; not sure how you
can make
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> AIX 4.3 was released in late 1999, so I thought it was worth mentioning.
> >> I only have AIX 4.3 and 6.1, so I have no idea how AIX 5 handles this.
> >> AIX 6.1 works fine.
> >>
> >> Anyways, the service argument to
On Fri, 2009-01-23 at 16:14 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > * Put corrected version into GIT
> > * Produce outstanding items as patch-on-patch via GIT
>
> I've applied the hot standby patch and recovery infra v9 patch to
> branches in my git repository, and pushed those
Simon Riggs wrote:
>
> On Fri, 2009-01-23 at 12:58 +0200, Devrim GÜNDÜZ wrote:
> > On Fri, 2009-01-23 at 10:05 +, Simon Riggs wrote:
> > > I'll add it now, default = on.
> >
> > Did you mean "off"?
>
> No, do you?
Depends on the setting :-) It is "hot_standby=off" by default, right?
I thin
Christopher Browne wrote:
FYI: There are AIX 5.3 nodes on BuildFarm - if the change is a
regression, it will be noticed :-).
This confirms that its an isolated AIX 4.3 bug.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hack
Alvaro Herrera píše v pá 23. 01. 2009 v 11:14 -0300:
> Zdenek Kotala wrote:
> >
> > Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> > > Zdenek Kotala wrote:
> > > > I attached patch which add capability to have single record for all
> > > > realation kind in the reloption list. It is usefu
Bruce Momjian wrote:
Andrew Chernow wrote:
AIX 4.3 was released in late 1999, so I thought it was worth mentioning.
I only have AIX 4.3 and 6.1, so I have no idea how AIX 5 handles this.
AIX 6.1 works fine.
Anyways, the service argument to getaddrinfo is busted on AIX 4.3, thus
src/bac
On Fri, Jan 23, 2009 at 9:18 AM, Andrew Chernow wrote:
> AIX 4.3 was released in late 1999, so I thought it was worth mentioning. I
> only have AIX 4.3 and 6.1, so I have no idea how AIX 5 handles this. AIX
> 6.1 works fine.
>
> Anyways, the service argument to getaddrinfo is busted on AIX 4.3,
Andrew Chernow wrote:
> AIX 4.3 was released in late 1999, so I thought it was worth mentioning.
> I only have AIX 4.3 and 6.1, so I have no idea how AIX 5 handles this.
> AIX 6.1 works fine.
>
> Anyways, the service argument to getaddrinfo is busted on AIX 4.3, thus
> src/backend/libpq/i
AIX 4.3 was released in late 1999, so I thought it was worth mentioning.
I only have AIX 4.3 and 6.1, so I have no idea how AIX 5 handles this.
AIX 6.1 works fine.
Anyways, the service argument to getaddrinfo is busted on AIX 4.3, thus
src/backend/libpq/ip.c pg_getaddrinfo_all() is busted o
Simon Riggs wrote:
* Put corrected version into GIT
* Produce outstanding items as patch-on-patch via GIT
I've applied the hot standby patch and recovery infra v9 patch to
branches in my git repository, and pushed those to:
git://git.postgresql.org/git/~hlinnaka/pgsql.git
You can clone that
Zdenek Kotala wrote:
>
> Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> > Zdenek Kotala wrote:
> > > I attached patch which add capability to have single record for all
> > > realation kind in the reloption list. It is usefull in situation when
> > > all parameters are same for all relatio
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
> Zdenek Kotala wrote:
> > I attached patch which add capability to have single record for all
> > realation kind in the reloption list. It is usefull in situation when
> > all parameters are same for all relation kinds.
>
> Do you have an exam
Zdenek Kotala wrote:
> I attached patch which add capability to have single record for all
> realation kind in the reloption list. It is usefull in situation when
> all parameters are same for all relation kinds.
Do you have an example use case for this?
--
Alvaro Herrera
Zdenek Kotala escreveu:
> I attached patch which add capability to have single record for all
> realation kind in the reloption list. It is usefull in situation when
> all parameters are same for all relation kinds.
>
Doesn't work. One of the reasons to separate relation kinds was that different
k
I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation when
all parameters are same for all relation kinds.
Zdenek
diff -Nrc pgsql_spacereserve.4cf1ae611238/src/backend/access/common/reloptions.c pgsql_spacerese
I'm very sorry, but v0.24 has a silly bug with not initialized value :(.
New version is attached
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.25.gz
Description: Unix ta
On Fri, 2009-01-23 at 14:28 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-01-23 at 10:35 +0200, Heikki Linnakangas wrote:
> >> As the patch stands, there's no way to disable hot standby. The server
> >> always opens for read-only connections as soon as it can. That might
Simon Riggs wrote:
On Fri, 2009-01-23 at 10:35 +0200, Heikki Linnakangas wrote:
As the patch stands, there's no way to disable hot standby. The server
always opens for read-only connections as soon as it can. That might not
be what you want.
I think we need a GUC to enable/disable hot standby
On Fri, 2009-01-23 at 10:35 +0200, Heikki Linnakangas wrote:
> As the patch stands, there's no way to disable hot standby. The server
> always opens for read-only connections as soon as it can. That might not
> be what you want.
>
> I think we need a GUC to enable/disable hot standby. It would
On Fri, 2009-01-23 at 12:58 +0200, Devrim GÜNDÜZ wrote:
> On Fri, 2009-01-23 at 10:05 +, Simon Riggs wrote:
> > I'll add it now, default = on.
>
> Did you mean "off"?
No, do you?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-h
On Fri, 2009-01-23 at 10:05 +, Simon Riggs wrote:
> I'll add it now, default = on.
Did you mean "off"?
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
signature.asc
Description: This is a digitally signed
On Fri, 2009-01-23 at 10:35 +0200, Heikki Linnakangas wrote:
> As the patch stands, there's no way to disable hot standby. The server
> always opens for read-only connections as soon as it can. That might not
> be what you want.
>
> I think we need a GUC to enable/disable hot standby. It would
Hmm, IIRC it is based on a monotonically increasing number. It could
have been anything. LSN was just a monotonically increasing number that
would be available if WAL was implemented first (or in parallel).
You are right, but without WAL-logging we would need to implement some kind of
sequenc
Yes it's an option, but you cannot rely on the typical consulting company to
do that. Do you know any specialized consulting boutique or individual
developer that could do that?
Carlos Gonzalez-Cadenas
CEO, ExperienceOn - New generation search
http://www.experienceon.com
Mobile: +34 652 911 201
S
On Thu, 2009-01-22 at 18:45 -0500, Tom Lane wrote:
> There are other recent examples of proposed hooks that in fact
> failed to be useful because of some oversight or other, and it was
> not until we insisted on seeing a live use of the hooks that this
> became apparent. (IIRC, one or both of th
As the patch stands, there's no way to disable hot standby. The server
always opens for read-only connections as soon as it can. That might not
be what you want.
I think we need a GUC to enable/disable hot standby. It would become
handy if the unimaginable happens and there's a bug in the hot
Alvaro Herrera wrote:
Euler Taveira de Oliveira escribió:
Alvaro Herrera escreveu:
Alvaro Herrera escribió:
I have a separate branch on which I keep the old patch from Euler
updated to the current reloptions code; so it is probably very similar
to what Euler just sent. (I'll have a look at t
99 matches
Mail list logo
