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
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
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 the
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
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
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 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 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-hackers
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
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
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 not
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
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
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
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
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 example use
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 relation kinds.
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
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
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/ip.c
On Fri, Jan 23, 2009 at 9:18 AM, Andrew Chernow a...@esilo.com 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
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
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 usefull in situation
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
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 think having a
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 getaddrinfo is
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
On 1/23/09, Alvaro Herrera alvhe...@commandprompt.com 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
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
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 out
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
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, assuming that mv is
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Andrew Chernow a...@esilo.com 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.
Hi Emmanuel,
Please find my comments in-lined:
On 1/23/09, Emmanuel Cecchet m...@frogthinker.org 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
Zdenek Kotala zdenek.kot...@sun.com 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
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 to:
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?
Depends on the setting
Simon Riggs si...@2ndquadrant.com 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
Albe Laurenz laurenz.a...@wien.gv.at 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
Tom Lane wrote:
Andrew Chernow a...@esilo.com 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
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,
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,
@@ -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
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 like
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 default?
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 by
Alvaro Herrera alvhe...@commandprompt.com 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
Andrew Chernow a...@esilo.com 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
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:
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.
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
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
awkward.
On 1/23/09, Tom Lane t...@sss.pgh.pa.us 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
On Fri, 2009-01-23 at 10:35 -0600, Kevin Grittner wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 Herrera
Simon Riggs si...@2ndquadrant.com 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
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 | Modifiers
Andrew Chernow a...@esilo.com 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
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 of
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 buffer is
On Fri, 2009-01-23 at 12:17 -0600, Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com 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
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
Tom Lane wrote:
Andrew Chernow a...@esilo.com 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
Merlin Moncure wrote:
On 1/23/09, Tom Lane t...@sss.pgh.pa.us 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
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
Andrew Chernow a...@esilo.com 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
Tom Lane wrote:
Andrew Chernow a...@esilo.com 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
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 does
Andrew Chernow a...@esilo.com 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
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 if it
On Fri, 2009-01-23 at 10:33 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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
Merlin Moncure wrote:
On 1/23/09, Tom Lane t...@sss.pgh.pa.us 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
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 ?
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us 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
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:
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
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
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
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
Simon Riggs si...@2ndquadrant.com 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
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 mean it's
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
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us 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
On Fri, 2009-01-23 at 17:32 -0500, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us 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
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*
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,
Oleg Bartunov o...@sai.msu.su 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
On Fri, Jan 23, 2009 at 5:52 PM, Josh Berkus j...@agliodbs.com 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
--On 23. Januar 2009 17:32:55 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied.
Uh well, i'd be happier if such review
On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us 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
--On 23. Januar 2009 18:02:55 -0500 Jaime Casanova
jcasa...@systemguards.com.ec 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
--On 23. Januar 2009 18:07:38 -0500 Jaime Casanova
jcasa...@systemguards.com.ec 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
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us 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
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.
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
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
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
99 matches
Mail list logo
