Yeb Havinga writes:
> Hello Royce,
> Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
The biggest problem is that the patch cuts up and reassembles the source
text and then han
Hello
2011/10/15 Josh Berkus :
>
>> Now that we have syntax for adding miscellaneous options to RAISE
>> statements, what I suggest we consider is a RAISE option that suppresses
>> all context lines for the message, perhaps
>>
>> RAISE NOTICE 'fee, fi, fo, fum' USING context = false;
>
> Yeah, tha
2011/10/15 Tom Lane :
> I can't recall whether there was some good reason for underspecifying
> these test queries. It looks like all the problematic ones were added in
> commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 "Extend the set of frame
> options supported for window functions", which means
> > if (!shutdown && XLogStandbyInfoActive())
> > + {
> > LogStandbySnapshot(&checkPoint.oldestActiveXid,
> > &checkPoint.nextXid);
> > + XLogReportParameters(REPORT_ON_BACKEND);
> > + }
> >
> > Why doesn't the change of FPW need to be WAL-logged when
> > shutdown c
Heikki Linnakangas writes:
> * Have you tested this on an architecture with strict alignment? I don't
> see any alignment bugs, but I think there's a lot of potential for them..
Well, fwiw, this patch passes its regression tests on HPPA, except for this
which seems more to do with the already-no
> As I suggested in the reply to Simon, I think that the change of FPW
> should be WAL-logged separately from that of HS parameters. ISTM
> packing them in one WAL record makes XLogReportParameters()
> quite confusing. Thought?
I want to confirm the reply of Simon. I think we cannot decide how th
Tom Lane wrote:
> Bruce Momjian writes:
> > Oops, I see a problem. Right now, our first major release has no zero,
> > e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is
> > that with this patch it is confusing to have a psql config file that
> > matches 9.2.0, but not 9.2.5, b
Florian Pflug writes:
> On Oct14, 2011, at 23:51 , Tom Lane wrote:
>> It seems to me that a client-side facility would be unlikely to do the
>> right things, because it has not got enough information to know which
>> messages came from plpgsql RAISE commands. Moreover, it's not apparent
>> that a
On Oct14, 2011, at 23:51 , Tom Lane wrote:
> Josh Berkus writes:
>>> I meant verbosity, not error level. This quick test shows what I meant
>>> -- but it doesn't work; the server log is altered as I expected (and does
>>> not
>>> include the context lines), but not plpgsql's:
>
>> Yeah, what we
On Oct14, 2011, at 20:00 , Josh Berkus wrote:
>>> We do transmit the individual parts of a NOTICE separately, so I'd say
>>> suppressing some of them is the client's job. So, instead of a GUC I'd say
>>> we'd need a psql setting ERROR_VERBOSITY.
>>
>> Well, we do have a psql setting as well (\set
On Fri, Oct 14, 2011 at 3:19 PM, Bruce Momjian wrote:
> Where are we on this?
Well, I don't know. We had a couple of different ideas on what to do
about it, and I'm not sure anyone was completely in love with any of
the available options.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.co
> Now that we have syntax for adding miscellaneous options to RAISE
> statements, what I suggest we consider is a RAISE option that suppresses
> all context lines for the message, perhaps
>
> RAISE NOTICE 'fee, fi, fo, fum' USING context = false;
Yeah, that would do it. Pavel? ;-)
--
Josh Be
On Fri, Oct 14, 2011 at 3:24 PM, Bruce Momjian wrote:
> Alexander Korotkov wrote:
>> Version of patch with few more comments and some fixes.
The CommitFest app page is here.
https://commitfest.postgresql.org/action/patch_view?id=539
It was reviewed in July by Nate Boley, and never updated.
Loo
Josh Berkus writes:
> In any case, this doesn't address the inconsistency of supressing
> CONTEXT for the first level of the call stack with RAISE INFO but not
> for the others. (RAISE EXCEPTION shows CONTEXT for all levels of the
> call stack).
Oh? I don't see that. AFAICT the behavior is not
Josh Berkus writes:
>> I meant verbosity, not error level. This quick test shows what I meant
>> -- but it doesn't work; the server log is altered as I expected (and does not
>> include the context lines), but not plpgsql's:
> Yeah, what we'd need is a client_error_verbosity setting.
It seems t
So I'm testing a patch to make the planner use measured all-visible-page
counts for index-only scans. I was expecting to possibly see some plan
changes in the regression tests, but this diff scared me:
***
*** 906,921
FROM tenk1 WHERE unique1 < 10;
sum | unique1
-+---
Bruce Momjian writes:
> Oops, I see a problem. Right now, our first major release has no zero,
> e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is
> that with this patch it is confusing to have a psql config file that
> matches 9.2.0, but not 9.2.5, because you can't write 9.2
Alvaro Herrera wrote:
>
> Excerpts from Robert Haas's message of vie oct 14 09:36:47 -0300 2011:
> >
> > On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
>
> > >> Oh, true, we have that, though it's not very usable because you have to
> > >> rename the file fro
Alexander Korotkov wrote:
> Version of patch with few more comments and some fixes.
Where are we on this?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers
Where are we on this?
---
David Fetter wrote:
> On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
> > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut wrote:
> > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casa
Magnus Hagander wrote:
> On Wed, Jun 22, 2011 at 17:48, Tom Lane wrote:
> > Magnus Hagander writes:
> >> Something along the line of this?
> >
> > I think this is a seriously, seriously bad idea:
> >
> >> +#define strdup(x) pg_strdup(x)
> >> +#define malloc(x) pg_malloc(x)
> >> +#define calloc(x,
Excerpts from Peter Geoghegan's message of vie oct 14 15:36:32 -0300 2011:
> This evening, David Fetter described a problem to me that he was
> having building the Twitter FDW. It transpired that it was down to its
> dependence on an #include that was recently judged to be
> redundant.This seems l
This evening, David Fetter described a problem to me that he was
having building the Twitter FDW. It transpired that it was down to its
dependence on an #include that was recently judged to be
redundant.This seems like another reason to avoid using pgrminclude -
even if we can be certain that the #
On Wed, Oct 12, 2011 at 7:07 PM, Tom Lane wrote:
> Phil Sorber writes:
>> Then there is a separate section of code that is called as a separate
>> function 'dumpUserConfig()' that does other role attributes like
>> 'ALTER ROLE bob SET role TO charlie'. These are the ALTER's that can
>> have depen
>> We do transmit the individual parts of a NOTICE separately, so I'd say
>> suppressing some of them is the client's job. So, instead of a GUC I'd say
>> we'd need a psql setting ERROR_VERBOSITY.
>
> Well, we do have a psql setting as well (\set VERBOSITY). But is Josh
> using psql?
Not in thi
Excerpts from Florian Pflug's message of vie oct 14 14:41:11 -0300 2011:
>
> On Oct14, 2011, at 19:27 , Josh Berkus wrote:
> >> I meant verbosity, not error level. This quick test shows what I meant
> >> -- but it doesn't work; the server log is altered as I expected (and does
> >> not
> >> inc
On Oct14, 2011, at 19:27 , Josh Berkus wrote:
>> I meant verbosity, not error level. This quick test shows what I meant
>> -- but it doesn't work; the server log is altered as I expected (and does not
>> include the context lines), but not plpgsql's:
>
> Yeah, what we'd need is a client_error_ver
On Fri, Oct 14, 2011 at 12:05 PM, Tom Lane wrote:
> Is this important enough to back-patch?
IMHO, yes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Fri, Oct 14, 2011 at 12:59 PM, Josh Berkus wrote:
>> Ideally we would have something like checkpoint_warning that warns users
>> in the log when there are too few autovacuum workers and cleanup is
>> being delayed.
>
> I don't think that any table-stats based approach is going to work. I
> thi
> I meant verbosity, not error level. This quick test shows what I meant
> -- but it doesn't work; the server log is altered as I expected (and does not
> include the context lines), but not plpgsql's:
Yeah, what we'd need is a client_error_verbosity setting.
--
Josh Berkus
PostgreSQL Experts
Bruce Momjian wrote:
> Is this a TODO?
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> If we don't want to change it wholesale, one option would be to
>>> support different lengths of filenames in slru.c for different
>>> slrus. At a quick glance, it seems pretty easy. That would allow
Excerpts from Josh Berkus's message of vie oct 14 14:16:43 -0300 2011:
>
> > Maybe set the verbosity to a lower level in the function? I dunno if
> > plpgsql lets you do that though. We have a GUC that controls the server
> > log verbosity, and psql can do it too; but plpgsql is sort of in
> >
> Maybe set the verbosity to a lower level in the function? I dunno if
> plpgsql lets you do that though. We have a GUC that controls the server
> log verbosity, and psql can do it too; but plpgsql is sort of in
> between.
The problem is that there is no level of verbosity which will supress
th
Excerpts from Josh Berkus's message of vie oct 14 13:52:32 -0300 2011:
> All,
>
> I'm noticing some inconsistent and (I believe) undesirable behavior on
> RAISE INFO.
>
> If you call a function, and it posts progress reports using RAISE INFO,
> then you get the INFO statements plain back to the
> Is this important enough to back-patch? We can't force initdb in back
> branches, but we could suggest that people could drop and re-create the
> information_schema (I think that's supposed to work).
I wouldn't worry about emphasizing the rebuild. Most users don't use
information_schema, and
On 14 October 2011 17:48, Bruce Momjian wrote:
>
> Is this going to be done for 9.2?
>
> ---
I didn't spot this thread before. I posted something related
yesterday: http://archives.postgresql.org/pgsql-hackers/2011-10/msg007
> Ideally we would have something like checkpoint_warning that warns users
> in the log when there are too few autovacuum workers and cleanup is
> being delayed.
I don't think that any table-stats based approach is going to work. I
think you need to measure the queue of tables which need autovac
Is this a TODO?
---
Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 09.06.2011 15:50, Robert Haas wrote:
> >> And I would guess that there's a lot more interest in raising BLCKSZ
> >> than lowering it. It might not be
All,
I'm noticing some inconsistent and (I believe) undesirable behavior on
RAISE INFO.
If you call a function, and it posts progress reports using RAISE INFO,
then you get the INFO statements plain back to the client. However, if
that function calls another function, then you also get a three-l
Is this going to be done for 9.2?
---
Greg Smith wrote:
> Following up on the idea we've been exploring for making some extensions
> more prominent, attached is the first rev that I think may be worth
> considering serious
Robert Haas wrote:
> On Wed, Jun 8, 2011 at 10:55 PM, Euler Taveira de Oliveira
> wrote:
> > Em 08-06-2011 20:35, Robert Haas escreveu:
> >> Is the hint correct? ?I mean, what if there were 100 small tables that
> >> needed vacuuming all at the same time. ?We'd hit this limit no matter
> >> how hi
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar sep 20 21:30:42 -0300 2011:
>> Could we please fix those tests to not have such
>> fragile timing assumptions?
> The fix has now been installed for two weeks and no new failure has
> occured. The only failure in the IsolationCheck
Consider this example in an empty database:
db=# create table t1 (f1 int);
CREATE TABLE
db=# create unique index t1f1 on t1(f1);
CREATE INDEX
db=# create table t2 (f2 int references t1(f1));
CREATE TABLE
db=# create table t3(f3 int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create impl
Excerpts from Tom Lane's message of mar sep 20 21:30:42 -0300 2011:
>
> The buildfarm is still showing isolation test failures more days than
> not, eg
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pika&dt=2011-09-17%2012%3A43%3A11
> and I've personally seen such failures when testing
On Thu, Oct 13, 2011 at 12:27 PM, Kohei KaiGai wrote:
> The attached patch fixes this problem.
> Unfortunately, we have no code that invokes get_object_address()
> with missing_ok = true now, so please apply a couple of patches
> to rework DROP statement of mine.
>
> DROP TRIGGER no_such_trigger O
Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of vie oct 14 12:12:22 -0300 2011:
> >
> > Alvaro Herrera wrote:
>
> > > The guideline, last I checked, was that before getting into coding any
> > > item from the TODO list, the prospective hacker should check previous
> > > discus
Robert Haas writes:
> On Fri, Oct 14, 2011 at 11:12 AM, Bruce Momjian wrote:
>> OK. But if we are pretty sure we don't want something, e.g. hibernate,
>> we shouldn't add it.
> Fair enough, but I'm not even slightly sure that we don't want that.
> I think having prewarming utilities available a
Excerpts from Bruce Momjian's message of vie oct 14 12:12:22 -0300 2011:
>
> Alvaro Herrera wrote:
> > The guideline, last I checked, was that before getting into coding any
> > item from the TODO list, the prospective hacker should check previous
> > discussions and initiate a new one on this l
Alvaro Herrera writes:
> Excerpts from Bruce Momjian's message of vie oct 14 11:56:22 -0300 2011:
>> Tom Lane wrote:
>>> There is plenty of stuff in the TODO list for which there is no
>>> consensus.
>> Uh, we should probably remove those then. Can you think of any?
> Unless something is blatan
On Fri, Oct 14, 2011 at 11:12 AM, Bruce Momjian wrote:
> OK. But if we are pretty sure we don't want something, e.g. hibernate,
> we shouldn't add it.
Fair enough, but I'm not even slightly sure that we don't want that.
I think having prewarming utilities available as contrib modules or on
PGXN
On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt wrote:
>> On the third hand, Josh's previous batch of changes to clean up
>> psql's behavior in this area are clearly a huge improvement: you can
>> now display the comment for nearly anything by running the appropriate
>> \d command for whatever
Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of vie oct 14 11:56:22 -0300 2011:
> > Tom Lane wrote:
> > > =?ISO-8859-1?Q?C=E9dric_Villemain?=
> > > writes:
> > > > 2011/10/14 Bruce Momjian :
> > > >> Should this be marked as TODO?
> > >
> > > > I suppose TODO items *are* want
Excerpts from Bruce Momjian's message of vie oct 14 11:56:22 -0300 2011:
> Tom Lane wrote:
> > =?ISO-8859-1?Q?C=E9dric_Villemain?=
> > writes:
> > > 2011/10/14 Bruce Momjian :
> > >> Should this be marked as TODO?
> >
> > > I suppose TODO items *are* wanted and so working on them should remove
Excerpts from Robert Haas's message of vie oct 14 09:36:47 -0300 2011:
>
> On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Oh, true, we have that, though it's not very usable because you have to
> >> rename the file from .psqlrc-9.0.3 to .psqlrc-9.0.4 when
Robert Haas wrote:
> On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Excerpts from Tom Lane's message of mi? may 25 16:07:55 -0400 2011:
> >> > Alvaro Herrera writes:
> >> > > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
> >> > >> Right
Tom Lane wrote:
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
> > 2011/10/14 Bruce Momjian :
> >> Should this be marked as TODO?
>
> > I suppose TODO items *are* wanted and so working on them should remove
> > the pain to convince people here to accept the feature, aren't they ?
>
> There is
Hello,
I am writing an extension to easily execute queries with conditions
expressing constraints in fuzzy logics.
I wrote some C functions that get or set global variables in C.
The variables are MU (FLOAT : degree of a fuzzy predicate), ALPHA
(FLOAT : threshold for filtering predicates) and K (
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2011/10/14 Bruce Momjian :
>> Should this be marked as TODO?
> I suppose TODO items *are* wanted and so working on them should remove
> the pain to convince people here to accept the feature, aren't they ?
There is plenty of stuff in the TODO list fo
On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of mié may 25 16:07:55 -0400 2011:
>> > Alvaro Herrera writes:
>> > > Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
>> > >> Right. It would also increase the c
On Thu, Oct 13, 2011 at 9:35 PM, Bruce Momjian wrote:
>
> I assume this was addressed with this commit:
>
> commit 465883b0a2b4236ba6b31b648a9eabef3b7cdddb
> Author: Simon Riggs
> Date: Tue Jun 28 22:58:17 2011 +0100
>
> Introduce compact WAL record for the commo
2011/10/13 Jun Ishiduka :
> I updated to patch corresponded above-comments.
Thanks for updating the patch!
As I suggested in the reply to Simon, I think that the change of FPW
should be WAL-logged separately from that of HS parameters. ISTM
packing them in one WAL record makes XLogReportParameter
On Thu, Oct 13, 2011 at 10:08 AM, Fujii Masao wrote:
> On Wed, Oct 12, 2011 at 10:29 PM, Robert Haas wrote:
>> On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao wrote:
>>> In 9.2dev and 9.1, when walreceiver detects an error while sending data to
>>> WAL stream, it always emits ERROR even if there ar
On 14.10.2011 11:44, Cédric Villemain wrote:
2011/10/14 Bruce Momjian:
Should this be marked as TODO?
I suppose TODO items *are* wanted and so working on them should remove
the pain to convince people here to accept the feature, aren't they ?
I don't think this is worthwhile to have in the
Hi,
We have several users working on a 8.4 database, using it as a
back-end for several related apps and transfering data to and from it.
The database tends to get a bit messy, so i've made a little table to
provide an overview.
This table is truncated and refilled daily, it shows all tables and
v
2011/10/14 Bruce Momjian :
>
> Should this be marked as TODO?
I suppose TODO items *are* wanted and so working on them should remove
the pain to convince people here to accept the feature, aren't they ?
>
> ---
>
> Mitsuru IW
65 matches
Mail list logo
