On 10/27/05, Andrew Dunstan [EMAIL PROTECTED] wrote:
Yes, MySQL is broken in some regards, as usual. However, the API isn't
bad (except for the fact that it doesn't care what invalid crap you
throw at it), and more importantly there are thousands of apps and
developers who think around that
Hi Tom,
Attached is a completed patch, which I've had no time to test yet, but
I have to leave for the evening right now --- so here it is in case
anyone is awake and wants to poke at it.
The patch was applied correctly only when I reverted Alvaro's first
patch, so I suppose it was meant to
On Thu, Oct 27, 2005 at 11:44:24AM -0500, Jim C. Nasby wrote:
The second option would help us where users are stymied by the system
trying to change the core size ulimit, why not make it easier?
It would also be very good if there was a way to verify that the backend
should be able to
Hi,
Should I try Alvaro's second patch that you said not going to work?
I'll add that this works for me, that's it prevents invalid alloc
requests to show.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of
On 2005-10-28, at 07:37, Oleg Bartunov wrote:
On Fri, 28 Oct 2005, Christopher Kings-Lynne wrote:
Grzegorz - it'd be great if you submitted documentation
improvements :)
I don't see any GiST specific problem in Grzegorz's case.
Other than just stupid bug, I know. It was just hard to
Gregory Maxwell wrote:
And in doing so you could insert a enum in the middle of the existing
list without breaking the values already in the table? If so that
would be very useful.
You do it by altering the column type, not by altering the type itself.
MySQL's way of doing this is made
Andrew wrote:
Jim C. Nasby wrote:
Personally, I don't see why enum can't just be syntactic sugar on top
of
a side-table of values and a foreign key. And I guess a view to hide
the
internals from normal viewing. That would certainly allow the most
flexibility, although it probably wouldn't
Rod Taylor wrote:
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to say
the least. I think there's a very good case for providing true enums.
Then why did you use
Tom Lane wrote:
I wrote:
Hmm. pqStrerror is defined in libpgport (which is linked into the
backend) as well as libpq. ISTM that libpq should not be linked with
-Wl,-bI:../../../src/backend/postgres.imp, since it's not intended to
be loaded into the backend. Without having looked at the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok. I had hoped to reproduce the problem with pristine sources, in
order to verify that I was able to show it not appearing with my patch.
However I have been unable to create a situation in which the problem
appears. So I attach
Kevin Murphy wrote:
It seems that the right place to put this is BE_DLLLIBS, which is a
macro that probably didn't exist when the AIX support was last looked
at. But both Windows and Darwin ports use it now, so we may as well
bring AIX up to speed. Would you try the attached patch and see
Matteo Beccati wrote:
Hi,
Should I try Alvaro's second patch that you said not going to work?
I'll add that this works for me, that's it prevents invalid alloc
requests to show.
Yeah, the problem with that patch is that there's another, different
race condition, of much lower
Alvaro Herrera [EMAIL PROTECTED] writes:
I think I understand your approach, but I wonder why Matteo didn't find
an improvement with your patch. Maybe there's a bug on it?
Yeah, looking at it this morning, I got the retry condition wrong.
It might be fixable but I'm less enthused about it than
I wrote:
Your idea of handling the wraparound ambiguity by ignoring
InvalidTransactionId isn't bad --- I'll take a look at that.
OK, I think this version may actually work, and get the wraparound
case right too. It hasn't failed yet on the pgbench test case anyway.
Matteo, could you try it on
On Fri, 2005-10-28 at 08:31 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2005-10-28 at 13:21 +1300, Mark Kirkwood wrote:
regression=# SELECT c.relname, m.relblocknumber, m.blockfreebytes
FROM pg_freespacemap m INNER JOIN pg_class c
Hmm. pqStrerror is defined in libpgport (which is linked into the
backend) as well as libpq. ISTM that libpq should not be
linked with
-Wl,-bI:../../../src/backend/postgres.imp, since it's not
intended to
be loaded into the backend. Without having looked at the code, I'm
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Were you able to create a test case? I tried several things, including
stopping a backend in the middle of creating a MultiXactId, but no luck
yet.
I've had some success using Tatsuo's new scriptable pgbench:
Hmm. I wasn't able
Tom Lane wrote:
OK, I think this version may actually work, and get the wraparound
case right too. It hasn't failed yet on the pgbench test case anyway.
Matteo, could you try it on your test case?
Yes, it's working. The test case ran for a several minutes without errors.
Thank you all :)
Tom Lane [EMAIL PROTECTED] writes:
creatingOffsetZero will be a bool that gets set before releasing
MultiXactGenLock if offset 0 is being returned, and then we clear it
after updating the slru data structures if we had starting offset 0.
If you're going to have a special flag indicating this
Greg Stark [EMAIL PROTECTED] writes:
If you're going to have a special flag indicating this couldn't you just have
a special flag indicating that the offset isn't ready yet? Loop until that
flag is cleared instead of looking for offset != 0 at all.
Well, the whole idea didn't work anyway :-(.
On Fri, Oct 28, 2005 at 05:05:25PM +0100, Simon Riggs wrote:
3. Helping Readahead efficiency: Currently blocks are allocated one at a
time. If many tables are extending at the same time, the blocks from
multiple tables will be intermixed together on the disk. Reading the
data back takes more
Alvaro Herrera wrote:
Additionally, I can confirm that the problem doesn't manifest with your
latest patch. I'm running several instances just to be sure.
Ok, I tested several runs and the problem didn't manifest. Additionally
I tested that wraparound also worked on at least some cases, by
Simon Riggs [EMAIL PROTECTED] writes:
There are a few issues with current FSM implementation, IMHO, discussing
as usual the very highest end of performance:
Do you have any evidence that the FSM is actually a source of
performance issues, or is this all hypothetical?
On Fri, Oct 28, 2005 at 02:26:31PM +1000, Gavin Sherry wrote:
Have spoken with Jim on IRC, he says that there have been several crashes
recently due to a faulty disk array. I guess the zeroing could be an
outcome of the faulty disk. I wonder if the crash the faulty disk resulted
in could have
Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] writes:
Thank you for the work, please apply.
Done. Thanks for testing it.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
Jim C. Nasby [EMAIL PROTECTED] writes:
What has been happening is periodic random crashes, around 1 a week. I
now have a good core for one, as well as an assert:
TRAP: FailedAssertion(!(shared-page_number[slotno] == pageno
shared-page_status[slotno] == SLRU_PAGE_READ_IN_PROGRESS), File:
From: Tom Lane [mailto:[EMAIL PROTECTED]
Jim C. Nasby [EMAIL PROTECTED] writes:
What has been happening is periodic random crashes, around
1 a week. I
now have a good core for one, as well as an assert:
TRAP: FailedAssertion(!(shared-page_number[slotno] == pageno
Jim Nasby [EMAIL PROTECTED] writes:
From: Tom Lane [mailto:[EMAIL PROTECTED]
The whole contents of *shared and the local variables of
SimpleLruReadPage would be good for starters.
I know how to get to the SimpleLruReadPage frame, but what commands do I need
to use after that?
p *shared
Here's the full info from 2 different cores:
[EMAIL PROTECTED] coredumps]# cat slru.gdb
f 3
p *shared
p pageno
p slotno
p ok
p xid
quit
[EMAIL PROTECTED] coredumps]# gdb -x slru.gdb /usr/bin/postmaster core.25146
|tail -n 13
warning: svr4_current_sos: Can't read pathname for load map:
On Thu, Oct 27, 2005 at 11:07:19PM -0400, Rod Taylor wrote:
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to say
the least. I think there's a very good case for
On Thu, Oct 27, 2005 at 10:34:57PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On Thu, Oct 27, 2005 at 09:45:05PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Andrew, you mentioned that if you want to change the ordering you should
just create a new type. What
On Fri, Oct 28, 2005 at 12:10:00AM -0400, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Without really wishing to volunteer myself: should plpgsql allow using
parameters with the same name as the columns being referred to within the
function, provided they're qualified as
On Fri, 2005-10-28 at 13:20 -0500, Jim C. Nasby wrote:
On Thu, Oct 27, 2005 at 11:07:19PM -0400, Rod Taylor wrote:
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to
BTW, what's the stack trace in those two core files?
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Jim C. Nasby wrote:
But why force a re-write of the entire table just to change the name of
something?
Because you are not just changing the name of something.
No, I was refering specifically to the case of wanting to rename
something. IE: you setup an enum for sky
On Fri, Oct 28, 2005 at 03:04:02PM -0400, Tom Lane wrote:
BTW, what's the stack trace in those two core files?
From 25146:
#0 0x003b8942e37d in raise () from /lib64/tls/libc.so.6
#1 0x003b8942faae in abort () from /lib64/tls/libc.so.6
#2 0x005d36f8 in ExceptionalCondition (
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by creating fake
primary keys for the purpose of obtaining performance because using the
proper primary key (single or multiple columns) is often very slow.
The automatic and
On Fri, Oct 28, 2005 at 04:12:01PM -0400, Andrew Dunstan wrote:
Well, with enumkit you can't, because the values are hardwired in the
.so file. With a builtin facility you would be able to, because the
values would live in the catalog. However, hacking the catalog is not
something I would
Here's another core... (pid 805 for reference)
#0 0x003b8942e37d in raise () from /lib64/tls/libc.so.6
#0 0x003b8942e37d in raise () from /lib64/tls/libc.so.6
#1 0x003b8942faae in abort () from /lib64/tls/libc.so.6
#2 0x005d36f8 in ExceptionalCondition (
Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 04:12:01PM -0400, Andrew Dunstan wrote:
Well, with enumkit you can't, because the values are hardwired in the
.so file. With a builtin facility you would be able to, because the
values would live in the catalog. However, hacking the catalog is
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by creating fake
primary keys for the purpose of obtaining performance because using the
proper primary key (single or
Jim C. Nasby wrote:
Here's another core... (pid 805 for reference)
All of them have in common that the slotno being passed ($3 below) is in
SLRU_PAGE_READ_IN_PROGRESS state ... could it be a problem with lock
reordering? Maybe somebody is trying to read in a page, and somebody
else steals the
Alvaro Herrera [EMAIL PROTECTED] writes:
All of them have in common that the slotno being passed ($3 below) is in
SLRU_PAGE_READ_IN_PROGRESS state ... could it be a problem with lock
reordering? Maybe somebody is trying to read in a page, and somebody
else steals the buffer from under them.
On Fri, Oct 28, 2005 at 04:58:56PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
All of them have in common that the slotno being passed ($3 below) is in
SLRU_PAGE_READ_IN_PROGRESS state ... could it be a problem with lock
reordering? Maybe somebody is trying to read in a
On Fri, Oct 28, 2005 at 04:36:26PM -0400, Rod Taylor wrote:
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by creating fake
primary keys for the purpose of obtaining
I wrote:
I suppose there's a bug in this path, but I'm darned if I can see what
it is. There are a number of obvious inefficiencies, but those
shouldn't be important given that this isn't supposed to happen much.
But how's it getting to the Assert failure?
While I'm disinclined to change
On Fri, Oct 28, 2005 at 05:45:51PM -0400, Tom Lane wrote:
I wrote:
I suppose there's a bug in this path, but I'm darned if I can see what
it is. There are a number of obvious inefficiencies, but those
shouldn't be important given that this isn't supposed to happen much.
But how's it
Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Oct 28, 2005 at 05:45:51PM -0400, Tom Lane wrote:
Jim, are you interested
in seeing if this patch makes the problem go away for you?
Well, this is a production system... what's the risk with that patch?
Well, it's utterly untested, which means
On Fri, 2005-10-28 at 16:28 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 04:36:26PM -0400, Rod Taylor wrote:
On Fri, 2005-10-28 at 15:21 -0500, Jim C. Nasby wrote:
On Fri, Oct 28, 2005 at 02:57:03PM -0400, Rod Taylor wrote:
The basic idea is that most of us break out schemas by
From: Tom Lane [mailto:[EMAIL PROTECTED]
Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Oct 28, 2005 at 05:45:51PM -0400, Tom Lane wrote:
Jim, are you interested
in seeing if this patch makes the problem go away for you?
Well, this is a production system... what's the risk with
that
On Fri, Oct 28, 2005 at 06:10:26PM -0400, Rod Taylor wrote:
It isn't supposed to impact the external representation of the data and
generally neither is an ENUM outside of the potential sorting ability. I
was just getting the impression that the big push for enums was to be
able to use a 'real
Folks,
On 8.0.4 and 8.1b4 given:
create type return_value as (
id INTEGER,
message TEXT
);
this function:
create function return_test (
vuser INT, vsession INT
) returns return_value as $fnc$
declare vtemp return_value;
begin
vtemp := row( -1, 'bad' );
return vtemp;
Folks,
Two corrections:
The second example was the wrong code, it should have been this function:
create function return_test_2 (
vuser INT, vsession INT
) returns return_value as $fnc$
begin
return row( -1, 'bad' );
end; $fnc$ language plpgsql;
Also, this issue is documented, but I
Folks,
Are foreign keys on temp tables not allowed just because nobody requested
them, or because they're hard to do?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: don't forget to increase your
Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ...
if anyone is sitting on *anything*, please say something before about
midnight GMT ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy
Josh Berkus josh@agliodbs.com writes:
Are foreign keys on temp tables not allowed just because nobody requested
them, or because they're hard to do?
You can have foreign keys between temp tables, just not between temp and
permanent tables. The latter case is either fairly silly, or
56 matches
Mail list logo