Re: [HACKERS] enums

2005-10-28 Thread Gregory Maxwell
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Matteo Beccati
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

Re: [HACKERS] Ideas for easier debugging of backend problems

2005-10-28 Thread Martijn van Oosterhout
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Matteo Beccati
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

Re: SOLVED Re: [HACKERS] _penalty gist method invoked with one key

2005-10-28 Thread Grzegorz Jaskiewicz
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

Re: [HACKERS] enums

2005-10-28 Thread Andrew Dunstan
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

Re: [HACKERS] enums

2005-10-28 Thread Merlin Moncure
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

Re: [HACKERS] enums

2005-10-28 Thread Andrew Dunstan
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

Re: [HACKERS] [GENERAL] aix build question re: duplicate symbol warning

2005-10-28 Thread Kevin Murphy
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Alvaro Herrera
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

Re: [HACKERS] [GENERAL] aix build question re: duplicate symbol warning

2005-10-28 Thread Andrew Dunstan
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Alvaro Herrera
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] [PATCHES] TODO Item - Add system view to show free space map

2005-10-28 Thread Simon Riggs
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

Re: [HACKERS] [GENERAL] aix build question re: duplicate symbol warning

2005-10-28 Thread Zeugswetter Andreas DAZ SD
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Alvaro Herrera
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Matteo Beccati
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 :)

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Greg Stark
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Tom Lane
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 :-(.

Re: [HACKERS] [PATCHES] TODO Item - Add system view to show free space map

2005-10-28 Thread Martijn van Oosterhout
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

Re: [HACKERS] ERROR: invalid memory alloc request size a_big_number_here

2005-10-28 Thread Alvaro Herrera
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

Re: [HACKERS] [PATCHES] TODO Item - Add system view to show free space map

2005-10-28 Thread Tom Lane
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?

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] [GENERAL] aix build question re: duplicate symbol warning

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Tom Lane
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:

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim Nasby
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim C. Nasby
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:

Re: [HACKERS] enums

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] enums

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] pl/pgsql breakage in 8.1b4?

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] enums

2005-10-28 Thread Rod Taylor
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] enums

2005-10-28 Thread Andrew Dunstan
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim C. Nasby
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 (

Re: [HACKERS] enums

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] enums

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim C. Nasby
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 (

Re: [HACKERS] enums

2005-10-28 Thread Andrew Dunstan
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

Re: [HACKERS] enums

2005-10-28 Thread Rod Taylor
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Alvaro Herrera
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Tom Lane
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.

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] enums

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim C. Nasby
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Tom Lane
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

Re: [HACKERS] enums

2005-10-28 Thread Rod Taylor
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

Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),

2005-10-28 Thread Jim Nasby
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

Re: [HACKERS] enums

2005-10-28 Thread Jim C. Nasby
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

[HACKERS] TODO for plpgsql: RETURN should accept arbitrary composite expressions

2005-10-28 Thread Josh Berkus
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;

Re: [HACKERS] TODO for plpgsql: RETURN should accept arbitrary composite expressions

2005-10-28 Thread Josh Berkus
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

[HACKERS] FKs on temp tables: hard, or just omitted?

2005-10-28 Thread Josh Berkus
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

[HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-28 Thread Marc G. Fournier
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

Re: [HACKERS] FKs on temp tables: hard, or just omitted?

2005-10-28 Thread Tom Lane
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