On Mon, Aug 13, 2012 at 1:11 AM, Alexander Korotkov wrote:
> On Thu, Aug 9, 2012 at 12:44 AM, Alexander Korotkov
> wrote:
>
>> My conclusion is so, that current errors are probably ok for selectivity
>> estimation. But taking into attention that generated datasets ideally fits
>> assumptions of e
"Kevin Grittner" wrote:
> OK, attached
[sigh]
This time for sure!
-Kevin
hotstandby-serializable.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas wrote:
> While playing around, I bumped into another related bug, and after
> googling around I found out that it was already reported by Robert
> Haas earlier, but still not fixed:
> Kevin, the last message on that thread says you'll write a patch
> for that. Ping?
OK, at
On Tue, 2012-07-24 at 16:14 -0400, Robert Haas wrote:
> On Tue, Jul 24, 2012 at 4:09 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Yeah, you're right. So you do get the table name. But you don't get
> >> the cause, which is what you really need to understand why it's
> >> happening. Attache
Robert Haas writes:
> On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch wrote:
>> Overall, though, I think it best to plug this. We could set a flag before
>> each operation, like evaluation of SQL arithmetic, for which SIGFPE is
>> normal.
> Yeah, that's what I thought of, too. It seems like it'd
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch wrote:
> If this use of SIGFPE is handy, we should expose it under a better name. What
> hazards make it unsafe?
Well, the most obvious problem is that a backend might receive it
while holding a spinlock.
> Overall, though, I think it best to plug th
* Daniel Farina (dan...@heroku.com) wrote:
> On Mon, Aug 13, 2012 at 5:32 PM, Josh Berkus wrote:
> > To date, I seem to be the only one convinced that this is an actual
> > deficiency ...
>
> It is an actual deficiency, and I am convinced.
Yeah, I think there's more people that agree with this u
On Mon, Aug 13, 2012 at 01:04:58PM -0400, Robert Haas wrote:
> A member of our technical team brought it to my attention that if you
> have a recalcitrant backend that doesn't die when you send it a
> SIGTERM, and you don't want to cause a crash-and-restart cycle by
> sending it SIGQUIT, you can ha
On Mon, Aug 13, 2012 at 5:32 PM, Josh Berkus wrote:
> To date, I seem to be the only one convinced that this is an actual
> deficiency ...
It is an actual deficiency, and I am convinced.
--
fdr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On 14/08/12 12:32, Josh Berkus wrote:
Mark,
Looking at the docs (section 25.2.6 paragraph 6) leads one to believe
that downstream standbys can continue to receive and process wal merely
by reconnecting after the cascading standby is promoted - but this does
not seem to be the case (indeed the s
Mark,
> Looking at the docs (section 25.2.6 paragraph 6) leads one to believe
> that downstream standbys can continue to receive and process wal merely
> by reconnecting after the cascading standby is promoted - but this does
> not seem to be the case (indeed the same paragraph notes that timeline
Looking at the docs (section 25.2.6 paragraph 6) leads one to believe
that downstream standbys can continue to receive and process wal merely
by reconnecting after the cascading standby is promoted - but this does
not seem to be the case (indeed the same paragraph notes that timelines
now no lo
We are going to prepare back-branch update releases to take care of
a couple of minor security issues that have been waiting much too
long already. The schedule will be a bit unusual though: wrap tarballs
this Tuesday evening (that's tomorrow) for public announcement Friday
the 17th.
This is not
Heikki Linnakangas wrote:
> While playing around, I bumped into another related bug, and
> after googling around I found out that it was already reported by
> Robert Haas earlier, but still not fixed:
>
http://archives.postgresql.org/message-id/CA%2BTgmoa0UM2W1YkjjneEgJctzxopC3G53ocYPaCyoEOWT3a
A member of our technical team brought it to my attention that if you
have a recalcitrant backend that doesn't die when you send it a
SIGTERM, and you don't want to cause a crash-and-restart cycle by
sending it SIGQUIT, you can have your cake and eat it too by sending
it SIGFPE, which will cheerful
Hello
this is VIP patch that implements shared - "status" variables to
PostgreSQL. A motivation for this features is possibility to take
client parameters inside inlined PL blocks.
This design is based on Magnus's ideas. Content is synchronized
between server and client. This doesn't need a proto
On 08.08.2012 17:35, Tom Lane wrote:
A runtime check for too many parameters seems appropriate. Assuming
that the error message it throws is well written, I don't think we need
to adjust the documentation. There are many limitations that are not
spelled out in the docs, and adding every one of
On Mon, Aug 13, 2012 at 4:34 AM, Tom Lane wrote:
> I've been experimenting with moving the Unix socket directory to
> /var/run/postgresql for the Fedora distribution (don't ask :-().
> It's mostly working, but I found out yet another way that pg_upgrade
> can crash and burn: it doesn't consider th
I've been looking at this further and I have made some improvements,
but also found a problem.
On 1 July 2012 23:35, Dean Rasheed wrote:
> I'm also aware that my new function ChangeVarAttnos() is almost
> identical to the function map_variable_attnos() that Tom recently
> added, but I couldn't im
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
Sent: Monday, August 13, 2012 12:47 PM
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas
Sent: Monday, August 13, 2012 12:
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas
Sent: Monday, August 13, 2012 12:14 PM
On 12.08.2012 17:39, Tom Lane wrote:
> Heikki Linnakangas writes:
>>> The problem is that when a postmaster subprocess is launched, it calls
>
Heikki Linnakangas writes:
> On 12.08.2012 17:39, Tom Lane wrote:
>> A larger point is that I think it's broken for any GUC assignment
>> function to be calling something as transient as RecoveryInProgress to
>> start with.
> Hmm, it seems like the logical place to complain if you do a manual "SE
22 matches
Mail list logo
