On Tue, May 13, 2008 at 4:12 PM, Bryce Nesbitt <[EMAIL PROTECTED]> wrote:
>
> Tom Lane wrote:
>>
>> After experimenting for a bit, I'd say "never". This output format is
>> extremely ugly. Maybe if it had enough smarts not to break in the
>> middle of words ...
>> regards, tom lane
>
> Yet, wra
On Mon, May 12, 2008 at 11:23:17PM -0600, Josh Tolley wrote:
> SPI_push();
> retval =
> InputFunctionCall(&flinfo, lolVarGetString(returnVal, true),
> resultTypeIOParam, -1);
> SPI_pop();
Won't
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Now that psql '\pset format wrapped' is in CVS, we should consider when
we want to use 'wrapped' format by default.
After experimenting for a bit, I'd say "never". This output format is
extremely ugly. Maybe if
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
I still think going with the older method would be the safest, though,
for the other reasons. You agree?
Seems reasonable to me.
Since it didn't really sound like a nice option, here's a third one I
came up with later. Basically, t
On Mon, 2008-05-12 at 22:40 -0400, Andrew Dunstan wrote:
>
> Robert Treat wrote:
> > On Monday 12 May 2008 18:58:37 Andrew Dunstan wrote:
> >
> >> Simon Riggs wrote:
> >>
> Lastly, not quite related to this output, but in the same general area,
> should we have an option on pg_st
Having posted this to -general [1] per -hackers list instructions [2]
to try elsewhere first, and waited (not very long, I admit) in vain
for a response, I'm posting this to -hackers now. My apologies if my
impatience in that regard annoys.
While developing PL/LOLCODE, I've found something wrong w
On Mon, 2008-05-12 at 23:03 -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> Simon Riggs wrote:
> >>
> >>> Well, the patch was rejected long ago, not sure why its in this
> >>> commitfest. But its an open issue on the Windows port.
> >>>
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I like this syntax, but I am not if it's good idea add new similar
>> statement. I don't know - but maybe it's can be better then extending
>> RAISE - and way to get consensus.
>
> I looked a bit more at the SQ
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
Well, the patch was rejected long ago, not sure why its in this
commitfest. But its an open issue on the Windows port.
Surely the right fix is to use the recently implemented
pgwin32_safestat()
Robert Treat <[EMAIL PROTECTED]> writes:
> On Monday 12 May 2008 14:40:46 Pavel Stehule wrote:
>> In plpgsql I prefer PL/SQL syntax.
> I think nod's toward PL/SQL compatability should be given in general.
This position seems just about entirely unhelpful for resolving the
problem at hand, because
Robert Treat wrote:
On Monday 12 May 2008 18:58:37 Andrew Dunstan wrote:
Simon Riggs wrote:
Lastly, not quite related to this output, but in the same general area,
should we have an option on pg_standby to allow removing the archive
file after it has been restored?
There alr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Well, the patch was rejected long ago, not sure why its in this
>> commitfest. But its an open issue on the Windows port.
> Surely the right fix is to use the recently implemented
> pgwin32_safestat() (if we aren't already - I sus
On Monday 12 May 2008 14:40:46 Pavel Stehule wrote:
> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> > "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> >> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> >>> It would get less annoying if we allowed user-declared exception names.
> >>
> >> Tom, it's exactly like m
Simon Riggs wrote:
On Mon, 2008-05-12 at 18:58 -0400, Andrew Dunstan wrote:
No, it had to do with pg_standby waiting for a WAL file that had already
gone, somehow. I will try to reproduce it when I get a spare moment.
Sounds like the bug I just fixed.
Yes, so I see. I didn't
On Monday 12 May 2008 18:58:37 Andrew Dunstan wrote:
> Simon Riggs wrote:
> >> Lastly, not quite related to this output, but in the same general area,
> >> should we have an option on pg_standby to allow removing the archive
> >> file after it has been restored?
> >
> > There already is one, but it
On Mon, 2008-05-12 at 18:58 -0400, Andrew Dunstan wrote:
> No, it had to do with pg_standby waiting for a WAL file that had already
> gone, somehow. I will try to reproduce it when I get a spare moment.
Sounds like the bug I just fixed.
> > There is an outstanding Windows issue with pg_stan
Simon Riggs wrote:
What is more, I apparently managed to get the recovery
server to lose a WAL file and hang totally by having a bad
recovery.conf. Triple ick.
Sounds like a bug you should report in the normal way. Correctness is
paramount. Or are you confusing the message in the l
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I still think going with the older method would be the safest, though,
> for the other reasons. You agree?
Seems reasonable to me.
> (I assume you mean GUC enum here, that seems fairly obvious)
Sorry, was writing in too much of a hurry.
> In these,
On Mon, 2008-05-12 at 16:57 -0400, Andrew Dunstan wrote:
> I have just been working on setting up a continuous recovery failover
> system, and noticed some odd log lines, shown below. (Using 8.3).
Hmmm, well, the first time you use something complex, there are some
surprising features, I guess.
Alvaro Herrera napsal(a):
I try to play with lint now if it gets better results.
Ok, good.
Hmm, It generates a lot of unnecessary includes in *.c files. I have checked
only couple of them and it seems that they are really unnecessary. A attach
output. Unfortunately, it does not detect miss
I have just been working on setting up a continuous recovery failover
system, and noticed some odd log lines, shown below. (Using 8.3).
First note that our parsing of recovery.conf in xlog.c is pretty bad,
and at least we need to document the quirks if it's not going to be
fixed. log_restart
Tom Lane wrote:
> I see that assign_xlog_sync_method() is still assigning to
> sync_method. This is 100% wrong: an assign hook is chartered to set
> derived values, but not to set the GUC variable itself. This will
> for example result in set_config_option() stacking the wrong value
> (the already
I see that assign_xlog_sync_method() is still assigning to sync_method.
This is 100% wrong: an assign hook is chartered to set derived values,
but not to set the GUC variable itself. This will for example result
in set_config_option() stacking the wrong value (the already-updated
one) as the value
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>> Well, then it is not working, because transam.h is missing from
>> bufpage.h ...
>
> It tried catch problems with defines not with datatypes. If you mean that
> TransactionID is not defined.
No, I mean that TransactionIdIsNormal() is used in Pa
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
I attached script which should check it. In first step it runs C
preprocessor on each header (postgres.h is included as well). The
output from first step is processed again with preprocessor and
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I like this syntax, but I am not if it's good idea add new similar
> statement. I don't know - but maybe it's can be better then extending
> RAISE - and way to get consensus.
I looked a bit more at the SQL spec. It already defines a MESSAGE_TEXT, whi
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > I need to leave for a couple of hours, will look again when I get
> > back. But so far, I'm quite surprised. Here's my reasoning, please
> > poke holes in it :-)
>
> I think you forgot to handle SYNC_METHOD_OPEN_DSYNC in
> issue_xlo
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>> Zdenek Kotala wrote:
>>> I attached script which should check it. In first step it runs C
>>> preprocessor on each header (postgres.h is included as well). The
>>> output from first step is processed again with preprocessor and
>>> define.h i
Alvaro Herrera napsal(a):
Zdenek Kotala escribió:
Regarding to Robert Mach's work during Google SOC on data integrity
check. I would like to improve storage module and implement some
Robert's code into the core.
Did this go anywhere?
I did not catch May commit fest :(. I plan to send cor
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Alvaro Herrera wrote:
(Digging further, it seems like bufpage.h should also include transam.h
in order to get TransactionIdIsNormal ... I start to wonder how many
problems of this nature we have on our headers. Without having a way to
detect whe
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm probably in the minority, but I care more about SQL/PSM
>> compatibility than Oracle compatibility.
>
> Well, a different line of attack would be to leave RAISE as-is and adopt
> the SQL/PSM syntax for a m
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm probably in the minority, but I care more about SQL/PSM
>> compatibility than Oracle compatibility.
>
> Well, a different line of attack would be to leave RAISE as-is and adopt
> the SQL/PSM syntax for a m
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'm probably in the minority, but I care more about SQL/PSM
> compatibility than Oracle compatibility.
Well, a different line of attack would be to leave RAISE as-is and adopt
the SQL/PSM syntax for a modernized command. What I'm seeing in Part 4
is
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
>>> It would get less annoying if we allowed user-declared exception names.
>
>> Tom, it's exactly like my patch that you rejected two years ago.
>
> Uh, no, not "exactly
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> I've started to look over Pavel's revised RAISE patch
> http://archives.postgresql.org/pgsql-patches/2008-05/msg00187.php
> and I've got a few quibbles with the syntax choices.
>
> Pavel proposes extending RAISE like this:
>
> RAISE level 'format' [, expres
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
>> It would get less annoying if we allowed user-declared exception names.
> Tom, it's exactly like my patch that you rejected two years ago.
Uh, no, not "exactly like" --- that patch doesn't have anything to do
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> I agree that the % formatting in the RAISE message is weird, but it is
>> useful.
>
> Sure, I'm not proposing removing it.
>
>> What would we do if the user specifies a %-formatted message as well
>> as a MESSAG
2008/5/12 Kevin Grittner <[EMAIL PROTECTED]>:
Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> Now, the elephant in the room is the issue of Oracle compatibility.
>> None of this looks anything even a little bit like Oracle's RAISE
>> command. Oracle allows
>> RAISE exception_name ;
>> RA
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I agree that the % formatting in the RAISE message is weird, but it is
> useful.
Sure, I'm not proposing removing it.
> What would we do if the user specifies a %-formatted message as well
> as a MESSAGE option?
Throw an error (just like if they speci
Hans-Juergen Schoenig wrote:
i suggest to introduce a --with-long-xids flag which would give me 62 /
64 bit XIDs per vacuum on the entire database.
this should be fairly easy to implement.
i am not too concerned about the size of the tuple header here - if we
waste 500 gb of storage here i am t
On Tue, May 13, 2008 at 2:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> 1. The parentheses around the USING list seem useless; let's drop 'em.
Yes.
>
> 2. I think the separation between SQLSTATE and CONDITION is just
> complication. A SQLSTATE is required to be exactly 5 digits and/or
> upper
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I need to leave for a couple of hours, will look again when I get back.
> But so far, I'm quite surprised. Here's my reasoning, please poke holes
> in it :-)
I think you forgot to handle SYNC_METHOD_OPEN_DSYNC in issue_xlog_fsync.
If you are going to s
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> Now, the elephant in the room is the issue of Oracle compatibility.
> None of this looks anything even a little bit like Oracle's RAISE
> command. Oracle allows
> RAISE exception_name ;
> RAISE ;
I'm probably in the minority, but I care mo
Tom Lane wrote:
BTW, aside from selecting the index the command would have to verify
that the indexed columns are all NOT NULL. We could either have it
just throw an error if they aren't, or have it silently try to do
an ALTER SET NOT NULL, which would require a table scan.
I'm going to argue
Zdenek Kotala escribió:
> Regarding to Robert Mach's work during Google SOC on data integrity
> check. I would like to improve storage module and implement some
> Robert's code into the core.
Did this go anywhere?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I realize most feel we don't need to add a rename to this, but there are
> two more reasons _not_ to do this.
One other thought I had about this is that the proposed syntax
ALTER TABLE tab ADD PRIMARY KEY (col [, ...]) USING INDEX foo
is not we
I've started to look over Pavel's revised RAISE patch
http://archives.postgresql.org/pgsql-patches/2008-05/msg00187.php
and I've got a few quibbles with the syntax choices.
Pavel proposes extending RAISE like this:
RAISE level 'format' [, expression [, ...] ] [ USING ( option = value [, ... ]
)
On Sun, May 11, 2008 at 01:50:22AM -0300, Euler Taveira de Oliveira wrote:
> I found another bug when using 'exec sql include filename'. If you use a
> filename that doesn't exist, ecpg crashes while trying to close a null
> pointer. The above test case shows it. A possible fix is attached.
Th
On Sat, May 10, 2008 at 12:14:57AM -0300, Euler Taveira de Oliveira wrote:
> While i'm working on a ecpg patch I found a bug in ecpg code. The simple
> program above could reproduce it. But basically it crashes (segfault)
It appeared that the whole error checking code was missing. Fixed now.
Joshua D. Drake wrote:
> Tom Lane wrote:
>
> >> Well it should be optional but it would be nice if we had the option to
> >> have it renamed per the default... meaning the same output if I were to
> >> do this:
> >
> > If you want that, you can rename the index (either before or afterwards).
>
Zdenek Kotala wrote:
> Alvaro Herrera wrote:
>> (Digging further, it seems like bufpage.h should also include transam.h
>> in order to get TransactionIdIsNormal ... I start to wonder how many
>> problems of this nature we have on our headers. Without having a way to
>> detect whether the defined
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which
> > is a change you had objected to previously :-(
> > http://archives.postgresql.org/pgsql-patches/2008-04/msg00149.php
>
> Hmm. I did notice that the patch see
Magnus Hagander wrote:
> Tom Lane wrote:
> > [EMAIL PROTECTED] (Magnus Hagander) writes:
> > > Convert wal_sync_method to guc enum.
> >
> > Buildfarm says you broke things for Windows.
>
> Yeah, working on that with Dave. First part was to unbreak the error
> message so we can actually figure out
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. Is that really a good idea, compared to hard-wiring the checks
>> into nodeSeqscan and friends?
> My eyebrows went up when I read this too. Presumably, if it's hardwired
> like you suggest then the planner can't take any accoun
Stephen Frost wrote:
> > And it's completely unnecessary. For example, I have set my majordomo
> > preferences for the postgresql.org lists not to send me copies of emails
> > where I am also in the To: or Cc: lines. After doing that I get no
> > duplicates.
>
> This doesn't help at all, ac
Tom Lane wrote:
KaiGai Kohei <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Yeah, I remember those. What needs to be looked at here is *why* the
output is changing. For a patch that allegedly does not touch the
planner, it's fairly disturbing that you don't get the same results.
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, I remember those. What needs to be looked at here is *why* the
>> output is changing. For a patch that allegedly does not touch the
>> planner, it's fairly disturbing that you don't get the same results.
> SE-PostgreSQL does not
Stephen Frost wrote:
Andrew,
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
For example, because it put *my* address in the list for your message
above, it caused my MUA quite correctly to add a To: line to myself,
which I certainly didn't want to do.
Honestly, I suspect thunderbird
Andrew,
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> For example, because it put *my* address in the list for your message
> above, it caused my MUA quite correctly to add a To: line to myself,
> which I certainly didn't want to do.
Honestly, I suspect thunderbird just doesn't know your addr
Hi,
The code uses Asynchronous I/O for fetching certain tids. The code works fine
if I use only one condition in where condition, but fails if I use multiple
condition.
--
Suresh Iyengar
Gregory Stark <[EMAIL PROTECTED]> wrote: "Suresh" writes:
> Hello,
>
> I have custom postgres code.
Wha
"Suresh" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I have custom postgres code.
What kind of code is this? The error below is typical if you create new
threads in the server.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres supp
Hello,
I have custom postgres code. I get the error below for the query
"select l_orderkey as a from tpcd.orders, tpcd.lineitem where
o_orderkey=l_orderkey and l_partkey<100 and l_linestatus='F';"
ERROR: stack depth limit exceeded
HINT: Increase the configuration parameter "max_stack_depth".
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Oops :-( I just noticed that I removed bufmgr.h from bufpage.h, which
is a change you had objected to previously :-(
However, it seems the right fix is to move BufferGetPageSize and
BufferGetPage from bufpage.h to bufmgr.h.
+1 It makes more sense
"Hans-Juergen Schoenig" <[EMAIL PROTECTED]> writes:
> i forgot to mention - i am on 8.1 here.
> so, VACUUM is not so smart yet.
So even if we added 64-bit xids it wouldn't be useful to you. You would have
to update (at which point you get all the other improvements which make it
less useful.) Or
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Some of the test fails contains minor differences from expected results,
>> like:
>
>> | SELECT '' AS "xxx", *
>> | FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
>> |xxx | a | b | c | d
>> | -+---+---+-
Joshua D. Drake wrote:
Hans-Juergen Schoenig wrote:
regards, tom lane
overhead is not an issue here - if i lose 10 or 15% i am totally fine
as long as i can reduce vacuum overhead to an absolute minimum.
overhead will vary with row sizes anyway - this is not the point.
I a
66 matches
Mail list logo
