2008/12/21 Hitoshi Harada :
> 2008/12/20 Tom Lane :
>> I've been studying the grammar for the windowing patch a bit. It seems
>> to me that the option for
>> got left out. I think that WindowDef needs to have two name fields,
>> one for the name (if any) defined by the window definition, and on
2008/12/20 Tom Lane :
> I've been studying the grammar for the windowing patch a bit. It seems
> to me that the option for
> got left out. I think that WindowDef needs to have two name fields,
> one for the name (if any) defined by the window definition, and one
> for the referenced window name
Hi,
On Fri, Dec 19, 2008 at 5:50 PM, Simon Riggs wrote:
>
> On Fri, 2008-12-19 at 09:43 +0900, Fujii Masao wrote:
>
>> > Yes, please check the call points for ForceSyncCommit.
>> >
>> > Do I think every xlog flush should be synchronous, no, I don't.
>> That's why we have a user settable parameter
2008/12/20 Tom Lane :
> "Hitoshi Harada" writes:
>> Here's the patch, including latest function default args. Regards,
>
> The comments added to planner.c contain various claims that setrefs.c
> will fix up window function references, but I see no code related to
> that in setrefs.c. Please expla
2008/12/21 Tom Lane :
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> So I'm thinking we'd better rename it, but I'm not coming up with
>>> anything good; the best I can do after a long day is "EvalWindow",
>>> and that doesn't seem particularly inspired. Any suggestions?
>
>> EvalWindow soun
Hi Benedek.
At 2008-11-06 15:08:14 +0100, l...@benedekl.tvnetwork.hu wrote:
>
> I created an updated patch according to your notices.
I had a look at your updated patch, and it looks fine. I fiddled with
the documentation a little, and fixed up one place where the code had
drifted and the patch d
Alvaro Herrera wrote:
Andrew Dunstan wrote:
We (i.e. probably Magnus and I in the first instance) should think about
creating a bit of a cookbook if we're going to persist with this build
system.
Well, we were going to try CMake, but we need somebody to do the work.
Yes, in
Tom Lane wrote:
> It seems like it might be better to rephrase error messages to ensure
> that anything really critical is mentioned in the primary message.
> In this case, perhaps instead of
> errmsg("could not locate required checkpoint record")
> we could have it print
> errmsg("cou
Alvaro Herrera writes:
> Euler Taveira de Oliveira wrote:
>> Yes, please. But i'm afraid it is too 'complicated' to expose
>> 'pg_toast.pg_toast_x' to user (but we can solve it with good
>> documentation).
> Hmm, now that I look at that again, it seems a very bad idea.
Yeah --- whatever sol
Andrew Gierth writes:
> I propose that this behaviour be changed such that 'terse' is ignored
> for all log messages of FATAL or PANIC severity.
> [ on the strength of a single example ]
This seems like using a blunderbuss where a rifle is called for.
There may indeed be some places where we hav
Andrew Dunstan writes:
> Also, because one of the Makefiles involved (src/foreign/Makefile)
> doesn't follow one of our standard patterns.
Is there a really good reason why it doesn't?
(eg, why "FDW" and not "SUBDIRS"?)
regards, tom lane
--
Sent via pgsql-hackers maili
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
> > I'm wondering if I should just allow all reloptions (including
> > fillfactor) or just the autovacuum ones.
> >
> Yes, please. But i'm afraid it is too 'complicated' to expose
> 'pg_toast.pg_toast_x' to user (but we can solve it w
Alvaro Herrera escreveu:
> I'm wondering if I should just allow all reloptions (including
> fillfactor) or just the autovacuum ones.
>
Yes, please. But i'm afraid it is too 'complicated' to expose
'pg_toast.pg_toast_x' to user (but we can solve it with good
documentation). What about xxx_toast
Hi,
Mark Mielke wrote:
> Good answers, Markus. Thanks.
You are welcome.
> So it looks like there is value to both ends of the spectrum, and while
> I feel the most value would be in providing a very fast system that
> scales near linear to the number of nodes in the system, even at the
> expense
Heikki Linnakangas wrote:
> Gregory Stark wrote:
>> A vacuum being replayed -- even in a different database -- could trigger the
>> error. Or with the btree split issue, a data load -- again even in a
>> different
>> database -- would be quite likely cause your SELECT to be killed.
>
> Hmm, I wond
Right now we don't allow setting reloptions to toast tables:
=# alter table pg_toast.pg_toast_16395 set (fillfactor = 40);
ERROR: "pg_toast_16395" is not a table or index
However this is needed for autovacuum, per previous discussion.
I'm wondering if I should just allow all reloptions (includi
Andrew Dunstan wrote:
> We (i.e. probably Magnus and I in the first instance) should think about
> creating a bit of a cookbook if we're going to persist with this build
> system.
Well, we were going to try CMake, but we need somebody to do the work.
--
Alvaro Herrera
Magnus Hagander wrote:
Just adding new files to exisitng makefiles, or adding a new subdir that
adds more files to an existing target, should require no changes.
It might help clarify things if you say why it *didn't* pick up these
new foreign-server libraries. Is it because they wer
Currently setting "log_error_verbosity = terse" causes all HINT output
to the log file to be suppressed (along with some other stuff).
I propose that this behaviour be changed such that 'terse' is ignored
for all log messages of FATAL or PANIC severity.
The main reason for this is messages like (
Tom Lane wrote:
> Magnus Hagander writes:
>>> Exactly what type of changes affec the MSVC build system?
>
>> Anything the system doesn't pick up automatically. That means most new
>> build targets (but it will pick up a contrib automatically, and a
>> conversion proc, for example). Also if modifi
Magnus Hagander writes:
>> Exactly what type of changes affec the MSVC build system?
> Anything the system doesn't pick up automatically. That means most new
> build targets (but it will pick up a contrib automatically, and a
> conversion proc, for example). Also if modifications are made to the
Joe Conway writes:
> Tom Lane wrote:
>> It seems this is a pile of pretty useless code, so far as the core
>> distribution is concerned, unless somebody fixes dblink to use it.
>> Is that on anyone's radar for 8.4?
> How much time is left to get it done? I might be able to find some time
> on th
Gregory Stark wrote:
A vacuum being replayed -- even in a different database -- could trigger the
error. Or with the btree split issue, a data load -- again even in a different
database -- would be quite likely cause your SELECT to be killed.
Hmm, I wonder if we should/could track the "latestRe
Anything the system doesn't pick up automatically. That means most new
build targets (but it will pick up a contrib automatically, and a
conversion proc, for example). Also if modifications are made to the
scripts that run (like gen_fmgr.sh).
Just adding new files to exisitng makefiles, or adding
Tom Lane wrote:
Peter wrote:
SQL/MED catalog manipulation facilities
This doesn't do any remote or external things yet, but it gives modules
like plproxy and dblink a standardized and future-proof system for
managing their connection information.
It seems this is a pile of pretty useless code
Peter wrote:
> SQL/MED catalog manipulation facilities
>
> This doesn't do any remote or external things yet, but it gives modules
> like plproxy and dblink a standardized and future-proof system for
> managing their connection information.
It seems this is a pile of pretty useless code, so far a
Exactly what type of changes affec the MSVC build system?
---
Magnus Hagander wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
> >>> I do not think this is an a
Tom Lane wrote:
> Peter Eisentraut writes:
>> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
>>> I do not think this is an appropriate attitude for a committer to take.
>
>> I would like to have this clarified, as I keep running afoul of it.
>
> My two cents: I don't expect you to fix the
Peter Eisentraut writes:
> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
>> I do not think this is an appropriate attitude for a committer to take.
> I would like to have this clarified, as I keep running afoul of it.
My two cents: I don't expect you to fix the MSVC scripts if you are
uni
Tom Lane wrote:
Definitely a necessary fix, but you missed what I think is actually
causing the crashes:
if (PointerIsValid(DatumGetPointer(datum)))
! repl_val[Anum_pg_foreign_data_wrapper_fdwoptions - 1] =
ObjectIdGetDatum(datum);
should be
Martin Pihlak writes:
> Thanks for that. There was an additional use of the Datum as Oid in
> AlterForeignDataWrapper, namely the assignment to repl_vals.
Ah, I just finished rediscovering that myself.
> Another bug was uncovered on orca -- a missing semicolon in gram.y:3004
Yeah, newer bisons
hei...@postgresql.org (Heikki Linnakangas) writes:
> Don't use OidIsValid to check the return value of transformGenericOptions,
> because transformGenericOptions returns an array, not an Oid. I'm not
> sure if this fixes the crashes seen in buildfarm, but it should be fixed
> anyway.
Definitely a
Hi,
Josh Berkus wrote:
> Peter Eisentraut wrote:
>> It's the color of the bikeshed ...
Agreed. It's why I've decided to support various modes for Postgres-R.
I'm glad to see that the current "Sync Rep" approach does the same.
> Hmmm. I thought this was pretty clear. There's three levels of syn
Hi,
Mark Mielke wrote:
> Robert Haas wrote:
>> On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane wrote:
>>> We won't call it anything, because we never will or can implement that.
>>> See the theory of relativity: the notion of exactly simultaneous events
>>
>> OK, fine. I'll be more precise. I think w
Good answers, Markus. Thanks.
I've bought the thinking of several here that the user should have some
control over what they expect (and what optimizations they are willing
to accept as a good choice), but that commit should still be able to
have a capped time limit.
I can think of many of m
Heikki Linnakangas wrote:
> The callers of transformGenericOptions-function in foreigncmds.c use
> OidIsValid to check the return value of transformGenericOptions, but it
> returns an array, not an Oid. I committed a fix for that, we'll see if
> it heals the buildfarm.
>
Thanks for that. There wa
On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
> Peter Eisentraut writes:
> > Dave Page wrote:
> >> Any eta on a fix for this? My internal builds are failing as well as
> >> red_bat. (and yes, the other 2 MSVC buildfarm members are currently
> >> waiting for Dell to get hold of a new motherb
Heikki Linnakangas writes:
> Tom Lane wrote:
>> So I'm thinking we'd better rename it, but I'm not coming up with
>> anything good; the best I can do after a long day is "EvalWindow",
>> and that doesn't seem particularly inspired. Any suggestions?
> EvalWindow sounds like a function in src/back
Hi,
Mark Mielke wrote:
> Where does the expectation come from?
I find the seat reservation, bank account or stock trading examples
pretty obvious WRT user expectations.
Nonetheless, I've compiled some hints from the documentation and sources:
"Since in Read Committed mode each new command start
Tom Lane wrote:
> pet...@postgresql.org (Peter Eisentraut) writes:
> > Log Message:
> > ---
> > SQL/MED catalog manipulation facilities
>
> The buildfarm says this patch has got serious portability issues.
FWIW I recently learned that you can set MALLOC_PERTURB_ to a nonzero
value to caus
Robert,
I thoroughly appreciate the constructive criticism.
The compile errors are due to my development process being convoluted.
I will endeavor to not waste your time in the future with errors
caused by my development process.
I have updated the code to follow the conventions and suggestions
Tom Lane wrote:
pet...@postgresql.org (Peter Eisentraut) writes:
Log Message:
---
SQL/MED catalog manipulation facilities
The buildfarm says this patch has got serious portability issues.
grebe, dugong, and ermine are all crashing here:
--- 109,115
(3 rows)
ALTER FOREIGN
Simon Riggs wrote:
On Sat, 2008-12-20 at 09:21 +0200, Heikki Linnakangas wrote:
Gregory Stark wrote:
Simon Riggs writes:
Increasing the waiting time increases the failover time and thus
decreases the value of the standby as an HA system. Others value high
availability higher than you and so
On Sat, 2008-12-20 at 09:21 +0200, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > Simon Riggs writes:
> >
> >> Increasing the waiting time increases the failover time and thus
> >> decreases the value of the standby as an HA system. Others value high
> >> availability higher than you and s
Hi,
On Fri, 19 Dec 2008, Tom Lane wrote:
SQL/MED catalog manipulation facilities
The buildfarm says this patch has got serious portability issues.
grebe, dugong, and ermine are all crashing here:
--- 109,115
(3 rows)
ALTER FOREIGN DATA WRAPPER foo OPTIONS (a '1', b '2');
! server cl
OLAPWindow? Gives a clue what meaning of "window" it's referring to...
--
Greg
On 20 Dec 2008, at 03:13, Heikki Linnakangas > wrote:
Tom Lane wrote:
I'm looking at the window-functions patch and wondering just what
kind
of trouble we'll get into if we leave its new plan node type named
Tom Lane wrote:
I'm looking at the window-functions patch and wondering just what kind
of trouble we'll get into if we leave its new plan node type named just
"Window". I've already confirmed that this is a direct conflict against
a typedef in , and I'd be not the least bit surprised if it's
use
47 matches
Mail list logo
