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
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
| -+---+---+--+---
| - |
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 at
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
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_partkey100 and l_linestatus='F';
ERROR: stack depth limit exceeded
HINT: Increase the configuration parameter max_stack_depth.
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 support!
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.
What kind
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
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
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 touch
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.
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, actually.
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 account of the
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 what's
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 seemed to
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 macros
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).
I don't see
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.
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.
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 [, ... ]
)
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 well
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/
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
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 more about
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 split
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 case
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
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 specified
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 ;
RAISE ;
I'm
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 MESSAGE option?
Throw
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
with the
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' [, expression [,
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 like --- that
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]:
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
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 modernized
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
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
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 is included.
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_xlog_fsync. If
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 condition
information
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
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
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
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
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.
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
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.
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, the
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
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_standby
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 its more
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 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 my patch that you
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 suspect we
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
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
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()
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 SQL spec. It
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.
Surely the
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
61 matches
Mail list logo
