2012/8/15 Tom Lane :
> Pavel Stehule writes:
>> My colleague found a issue on 9.2 - sorry for query formatting - this
>> query is generated from ours query engine
>
> Fixed, thanks for the report.
thank you
Pavel
>
> regards, tom lane
--
Sent via pgsql-hackers mailing
Peter Geoghegan writes:
> On 14 August 2012 21:26, Bruce Momjian wrote:
>> Revert "commit_delay" change; just add comment that we don't have
>> a microsecond specification.
> I think that if we eventually decide to change the name of
> commit_delay for 9.3 (you previously suggested that that mig
Pavel Stehule writes:
> My colleague found a issue on 9.2 - sorry for query formatting - this
> query is generated from ours query engine
Fixed, thanks for the report.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Tue, 2012-08-14 at 20:58 -0600, Alex Hunsaker wrote:
> I know i've used 5.14 in the past successfully. Wat happens if you
> regenerate plperl_opmask.h? (rm plperl_opmask.h && make)
Yeah, it seems to have something to do with a perl upgrade happening
between builds. It was fixed by building fr
On Tue, 2012-08-14 at 17:56 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
> >> What about having single user mode talk fe/be protocol, and talk to it via
> >> a UNIX pipe, with pg_upgrade starting the single user backend as a
> >> subprocess?
>
On Tue, 2012-08-14 at 11:30 -0400, Alvaro Herrera wrote:
> And so on (there are several more). Note that here we use "check
> constraint" without any capitalization. However this doesn't
> translate
> too well as is; I mean, if I were to translate "check" into its
> equivalent spanish word, I'm s
On Tue, 2012-08-14 at 12:04 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Speaking of english words, I was wondering at "check" the other day.
> > For example, we have
>
> > #: catalog/heap.c:2171
> > #, c-format
> > msgid "check constraint \"%s\" already exists"
>
> > #: catalog/heap.c:25
On Fri, 2012-08-10 at 17:57 +0100, Greg Stark wrote:
> On Thu, Aug 9, 2012 at 5:40 PM, Tom Lane wrote:
> > Fair enough. I was not sold on doing that either. I would still like
> > to know if it's okay to use one string with %s for the cases where
> > there's not a good reason for the "context" t
> "Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>> On 14.08.2012 14:25, Kevin Grittner wrote:
Attached is version 3.
>>> Oh, further testing this morning shows that while *queries* on
>>> the HS seem OK, streaming replication is now broken. I probably
>>> need to override transaction isolat
Is there a TODO here?
---
On Wed, Aug 10, 2011 at 09:43:18PM +0300, Peter Eisentraut wrote:
> On ons, 2011-08-10 at 19:29 +0100, Dave Page wrote:
> > On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut wrote:
> > > I would li
On Tue, Aug 14, 2012 at 06:53:49PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
> >> The implementation I'm visualizing is that a would-be client (think psql
> >> or pg_dump, though the code would actually be in libpq) forks off a
> >
On Sun, Aug 12, 2012 at 9:57 PM, Peter Eisentraut wrote:
> It appears that a recent Perl version (I have 5.14.2) has eliminated
> OP_SETSTATE, which causes the current PostgreSQL build to fail:
>
> plperl.c: In function ‘_PG_init’:
> plperl.c:442:5645: error: ‘OP_SETSTATE’ undeclared (first use i
On Tue, 2012-08-14 at 17:36 -0400, Bruce Momjian wrote:
> On Tue, Aug 14, 2012 at 05:34:02PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Aug 4, 2011 at 09:00:11PM +0300, Peter Eisentraut wrote:
> > >> On tor, 2011-08-04 at 14:44 +0200, Boszormenyi Zoltan wrote:
> > >>> I meant
On 08/14/2012 05:03 PM, Michael Braun wrote:
Hi,
I've just recently upgraded to postgrsql 9.1 and also hit bug #5763.
Having +group not match all superusers is essential to be able to assign
different authentication backends to different superusers with needing
to edit configuration files on th
Bruce Momjian writes:
> On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
>> The implementation I'm visualizing is that a would-be client (think psql
>> or pg_dump, though the code would actually be in libpq) forks off a
>> process that becomes a standalone backend, and then they communica
I assume we didn't feel any action was necessary on this issue.
---
On Thu, Aug 11, 2011 at 01:50:02PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Aug 9, 2011 at 2:16 PM, Peter Eisentraut wrote:
> >> But I'm a
Hi,
I've just recently upgraded to postgrsql 9.1 and also hit bug #5763.
Having +group not match all superusers is essential to be able to assign
different authentication backends to different superusers with needing
to edit configuration files on the radius host system. E.g. to be able
to authent
On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
> >> What about having single user mode talk fe/be protocol, and talk to it via
> >> a UNIX pipe, with pg_upgrade starting the single user backend as a
> >> subpro
Peter Eisentraut writes:
> On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
>> What about having single user mode talk fe/be protocol, and talk to it via a
>> UNIX pipe, with pg_upgrade starting the single user backend as a subprocess?
> I think that's essentially equivalent to starting the server on
On 8/10/12 7:12 PM, Doug Coleman wrote:
What it looks like is the first line of each section is pattern matching.
If __LP64__ is defined, then it's a 64-bit architecture, and we want
to use the top part of the if statement. The #defines they target seem
to be all of the ones that are different o
On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
Another thing worth considering is to have pg_upgrade init, stop and
start clusters as necessary instead of requesting the user to do it.
I think this is two less steps.
Then you'd need to expose the entire pg_ctl shutdown mode logic through
pg_upg
Noah Misch writes:
> On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
>> On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark wrote:
>>> It is possible to check if the signal was synchronous or was sent from
>>> an external process. You can check siginfo->si_pid to see who sent you
>>> the sig
Did these comment updates ever get addressed?
---
On Fri, Aug 5, 2011 at 11:02:24AM -0400, Robert Haas wrote:
> I think that the first sentence, in the following comment within
> GetSnapshotData(), is not quite right, becau
On Tue, Aug 14, 2012 at 05:34:02PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Aug 4, 2011 at 09:00:11PM +0300, Peter Eisentraut wrote:
> >> On tor, 2011-08-04 at 14:44 +0200, Boszormenyi Zoltan wrote:
> >>> I meant a mass "sed -e 's/TRUE/true/g' -e 's/FALSE/false/g'" run
> >>> so
Bruce Momjian writes:
> On Thu, Aug 4, 2011 at 09:00:11PM +0300, Peter Eisentraut wrote:
>> On tor, 2011-08-04 at 14:44 +0200, Boszormenyi Zoltan wrote:
>>> I meant a mass "sed -e 's/TRUE/true/g' -e 's/FALSE/false/g'" run
>>> so all the ~200 occurrences of both "TRUE" and "FALSE" get
>>> convert
Heikki Linnakangas wrote:
> On 14.08.2012 14:25, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> On 14.08.2012 08:23, Kevin Grittner wrote:
>> Oh, further testing this morning shows that while *queries* on
>> the HS seem OK, streaming replication is now broken. I probably
>> need to ove
On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark wrote:
> > It is possible to check if the signal was synchronous or was sent from
> > an external process. You can check siginfo->si_pid to see who sent you
> > the signal. I'm not sure check
On Thu, Aug 4, 2011 at 09:00:11PM +0300, Peter Eisentraut wrote:
> On tor, 2011-08-04 at 14:44 +0200, Boszormenyi Zoltan wrote:
> > 2011-08-04 14:32 keltezéssel, Robert Haas írta:
> > > 2011/8/4 Boszormenyi Zoltan :
> > >> Shouldn't these get fixed to be consistent?
> > > I believe I already did.
On 14.08.2012 14:25, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 14.08.2012 08:23, Kevin Grittner wrote:
OK, attached is a first cut to confirm that the approach looks
sane to everyone; I *think* it is along the lines that we reached
consensus. After moving the check to the point wher
> Yeah, I think there's more people that agree with this use-case than you
> seem to think.. That said, I appreciate that it's not a trivial thing
> to support cleanly.
Not trivial, no, but not major either. Really what needs to happen is
for the timeline change record to get transmitted over t
Alvaro Herrera writes:
> Speaking of english words, I was wondering at "check" the other day.
> For example, we have
> #: catalog/heap.c:2171
> #, c-format
> msgid "check constraint \"%s\" already exists"
> #: catalog/heap.c:2534
> #, c-format
> msgid "only table \"%s\" can be referenced in chec
On 14.08.2012 09:45, Alexander Korotkov wrote:
After fixing few more bugs, I've a version with much more reasonable
accuracy.
Great! One little thing just occurred to me:
You're relying on the regular scalar selectivity estimators for the <<,
>>, &< and &> operators. That seems bogus, in part
Excerpts from Greg Stark's message of vie ago 10 12:57:25 -0400 2012:
> On Thu, Aug 9, 2012 at 5:40 PM, Tom Lane wrote:
> > Fair enough. I was not sold on doing that either. I would still like
> > to know if it's okay to use one string with %s for the cases where
> > there's not a good reason fo
Noah Misch writes:
> On Tue, Aug 14, 2012 at 08:38:44AM -0400, Robert Haas wrote:
>> On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane wrote:
>>> That would depend on how many places there are where SIGFPE is expected.
>>> Are we sure there are any? Maybe we should just remove the handler and
>>> let S
On Tue, Aug 14, 2012 at 8:55 AM, k...@rice.edu wrote:
> On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
>> 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,
On Tue, Aug 14, 2012 at 08:38:44AM -0400, Robert Haas wrote:
> On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane wrote:
> > That would depend on how many places there are where SIGFPE is expected.
> > Are we sure there are any? Maybe we should just remove the handler and
> > let SIGFPE be treated as a c
Heikki Linnakangas wrote:
> we have to somehow fix the crash and the assertion failure on 9.1.
Here's a revision with some changes based on your feedback. I have
to go to my "day job" now, and I was unable to find the right place
to fix the streaming replication problem. I fear I won't be ab
On Mon, Aug 13, 2012 at 11:52:06PM -0400, Tom Lane wrote:
> 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
> >>
On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark wrote:
> It is possible to check if the signal was synchronous or was sent from
> an external process. You can check siginfo->si_pid to see who sent you
> the signal. I'm not sure checking that and handling it at
> check_for_interrupts if it's asynchrono
On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane wrote:
> 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.
>
Heikki Linnakangas wrote:
> On 14.08.2012 08:23, Kevin Grittner wrote:
>> OK, attached is a first cut to confirm that the approach looks
>> sane to everyone; I *think* it is along the lines that we reached
>> consensus. After moving the check to the point where we get a
>> serializable snapshot,
It is possible to check if the signal was synchronous or was sent from
an external process. You can check siginfo->si_pid to see who sent you
the signal. I'm not sure checking that and handling it at
check_for_interrupts if it's asynchronous is the best solution or not
though.
I'm a bit confused.
Should we do something to plug this, and if so, what? If not, should
we document the danger?
I am not sure if I really understood the intention of the question correctly,
but if the question was if pg should try to work around misuse of signals, then
my answer would be a definite no.
IMHO,
On 14.08.2012 08:23, Kevin Grittner wrote:
OK, attached is a first cut to confirm that the approach looks sane
to everyone; I *think* it is along the lines that we reached
consensus. After moving the check to the point where we get a
serializable snapshot, it was still behaving badly. It took a
Hello
My colleague found a issue on 9.2 - sorry for query formatting - this
query is generated from ours query engine
testdb=# \i planbug.sql
DROP TABLE
DROP TABLE
DROP TABLE
DROP TABLE
DROP TABLE
CREATE TABLE
CREATE TABLE
CREATE TABLE
CREATE TABLE
CREATE TABLE
psql:planbug.sql:66: ERROR: failed
Hello
patch that implements "shared" client/server session variables
Regards
Pavel Stehule
shared_variables-01.diff
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-ha
46 matches
Mail list logo
