Josh Berkus 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
technically hard, dependin
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
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 free
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 bel
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;
end;
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 'r
> 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
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 schem
"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, whi
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
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 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 obtai
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 r
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 th
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 b
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:
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 n
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 (
conditionName=0
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 woul
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 t
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 (
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 co
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
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 an
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 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
> >>>jus
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 f
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: Input/outp
"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
> 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 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)
"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
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 ha
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?
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
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 mor
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 :
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 t
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 :)
Be
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 w
> > 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
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
> > >
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
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 t
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 proba
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 i
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
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 co
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 loo
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 wo
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
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 fi
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 broadcast)
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 t
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 b
55 matches
Mail list logo
