I have simplified the code according to the discussion. Now there is no pipe
or signaling threads, process access shared memory directly to pass signals.
Seems everything works fine except pg_ctl. I now have two choices to fix it:
(1) Record Shared memory name (it is already there) and the offset
Personally I don't think that it is a good idea to do that.
People will tend to corrupt their systems because they want speed
(sometimes without thinking about the consequences).
I can only think of one scenario where nologging would actually make
sense: Many people use session tables to keep
On Wed, 1 Jun 2005, Christopher Kings-Lynne wrote:
How much money (US Dollars) would you need?
Command Prompt could jump on that as well. We could help sponsor a bit.
Maybe we could start a funding project for it?
USD convert to lots of roubles I assume, so it'd be good like that. Perhaps
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On May 31, 2005, at 12:48 AM, Tom Lane wrote:
>> Actually, practically all of the Postgres code assumes int is at least
>> 32 bits. Feel free to change pg_tm's field to be declared int32
>> instead
>> of just int if that bothers you, but it is rea
On Wed, 2005-06-01 at 00:40 -0400, Alvaro Herrera wrote:
> This doesn't work for COPY, but maybe for CREATE TABLE AS we could log
> the fact that the command was executed, so the replayer could execute
> the same command again.
>
> Of course, this handwaving doesn't explain how the system in recov
On May 31, 2005, at 1:40 AM, Tom Lane wrote:
Josh Berkus writes:
Unfortunately, it appears that tri-partitioning INTERVAL ( year/
month ;
week/day ; hour/minute/second ) is a violation of the SQL spec
which has only
the two partitions ( year/month ; week/day/hour/minute/second ).
I
On Tue, May 31, 2005 at 10:47:30PM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Recent test results have shown a substantial performance improvement
> > (+25%) if WAL logging is disabled for large COPY statements.
> BTW, I'm sure you are the last one who needs to be reminde
On May 31, 2005, at 12:48 AM, Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
tm_mday is an int value, which is only guaranteed to be 2
bytes (though it may be larger), if I understand correctly.
Actually, practically all of the Postgres code assumes int is at least
32
Simon Riggs <[EMAIL PROTECTED]> writes:
> Recent test results have shown a substantial performance improvement
> (+25%) if WAL logging is disabled for large COPY statements.
How much of that is left after we fix the 64-bit-CRC issue?
> Now, I would like to discuss adding an enable_logging USERSET
Simon Riggs <[EMAIL PROTECTED]> writes:
> Hmmm. I seem to recall asking myself why xl_prev existed if it wasn't
> used, but passed that by. Damn.
I couldn't believe it'd been overlooked this long, either. It's the
sort of thing that you assume got done the first time :-(
> PreAllocXLog was alrea
Simon Riggs <[EMAIL PROTECTED]> writes:
> If a table is created as WITHOUT OIDS, is it still possible to take
> advantage of the physical tlist optimization?
Um ... it depends. There are cases where you have to have an OID,
and cases where you have to not have one. See ExecContextForcesOids.
Finally, I found the tablelog project at the pgFoundary...
(B
(Bhttp://pgfoundry.org/projects/tablelog/
(B
(BSatoshi Nagayasu wrote:
(B> Hiroshi Saito wrote:
(B>
(B>>http://archives.postgresql.org/pgsql-general/2004-08/msg01439.php
(B>>I remember that the approach which he enjoyed was bein
Simon Riggs <[EMAIL PROTECTED]> writes:
> Is this a change that would be backpatched as you suggested previously?
I don't think we can backpatch any of these items, since they involve
changes in the on-disk file format. I was thinking of them as CVS HEAD
changes only.
reg
How much money (US Dollars) would you need?
Command Prompt could jump on that as well. We could help sponsor a bit.
Maybe we could start a funding project for it?
USD convert to lots of roubles I assume, so it'd be good like that.
Perhaps someone (not me - too busy) on the PostgreSQL Founda
Hiroshi Saito wrote:
(B> http://archives.postgresql.org/pgsql-general/2004-08/msg01439.php
(B> I remember that the approach which he enjoyed was being done.
(B
(BThanks for the information.
(B
(B> However, I hope variously as a function of the PostgreSQL core.
(B
(BI hope they goes into the
On Wed, 2005-06-01 at 09:30 +0800, Christopher Kings-Lynne wrote:
> This whole GiST concurrency think really needs to be looked at :(
I spent some time looking at it toward the end of last year, but
unfortunately I didn't have enough time to devote to it to get a working
implementation (it is quit
Christopher Kings-Lynne wrote:
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrency&recovery for GiST. I'm trying to find support here in Russia
for our work.
How much money (US Dollars) would you need?
Command Prompt could jump on that as well. We could help s
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrency&recovery for GiST. I'm trying to find support here in Russia
for our work.
How much money (US Dollars) would you need?
Chris
---(end of broadcast)---
TIP 6: Have
The real solution is to upgrade GIST to be concurrent. Oleg and Teodor
have made some noises about that in the past, but nothing's been done
about it that I've heard of.
This whole GiST concurrency think really needs to be looked at :( There
is so much cool stuff that can be done with it, and
From: "Satoshi Nagayasu" <[EMAIL PROTECTED]>
(B
(B> Hi all,
(B>
(B> I'm now interested in audit facilities for database accessing.
(B> Are anyone thinking or working on audit stuffs?
(B
(Bhttp://archives.postgresql.org/pgsql-general/2004-08/msg01439.php
(BI remember that the approach which
Hi all,
(B
(BI'm now interested in audit facilities for database accessing.
(BAre anyone thinking or working on audit stuffs?
(B
(B--
(BNAGAYASU Satoshi <[EMAIL PROTECTED]>
(BOpenSource Development Center,
(BNTT DATA Corp. http://www.nttdata.co.jp/
(B
(B---(end of
Jeff,
> If we're looking at the same benchmark (File Server DriveMark), the
> fastest SCSI disk is 65% faster than the fastest SATA disk. The fastest
> SCSI 10K disk is 25% faster than the SATA.
I think it's misleading to compare drives on the basis of one benchmark.
One of the things I like a
On Tue, 2005-05-31 at 17:05 -0400, Tom Lane wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > I'm sure this has been thought of but was wondering whether anyone had
> > discussed the allowance of run-time block size specifications at the
> > tablespace level?
>
> Can you produce any evi
On Tue, 2005-05-31 at 16:26 -0400, Tom Lane wrote:
> The TODO item that comes to mind immediately is "Compress WAL entries".
> A more concrete version of this is: examine the page to see if the
> pd_lower field is between SizeOfPageHeaderData and BLCKSZ, and if so
> whether there is a run of consec
On Tue, 2005-05-31 at 12:27 -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >>> Is the random WAL data really the concern? It seems like a more reliable
> >>> way
> >>> of dealing with that would be to just accompany every WAL entry with a
Tom,
You and I both know that depending on the application and data,
different block sizes are beneficial. As for actual statistics due to
overhead, I don't know what I can give you.
I can provide stats from an application which fits the case for multiple
block sizes on Oracle, but Oracle a
Recent test results have shown a substantial performance improvement
(+25%) if WAL logging is disabled for large COPY statements. This is to
be expected, though has a price attached: losing the ability to crash
recover data loaded in this manner.
There are two parts to this proposal. First, when a
On Tue, 31 May 2005, Tom Lane wrote:
(2) we acquire and release the index lock for each *tuple* rather than
each statement. Then client2 doesn't hold the index lock while it's
waiting for the row lock to clear.
Neither of these cures sounds attractive :-(. I think #1 would probably
do as m
If a table is created as WITHOUT OIDS, is it still possible to take
advantage of the physical tlist optimization?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Tue, 31 May 2005, Tom Lane wrote:
The real solution is to upgrade GIST to be concurrent. Oleg and Teodor
have made some noises about that in the past, but nothing's been done
about it that I've heard of.
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrency&rec
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 31 May 2005, Tom Lane wrote:
>> I take it from your title that this only happens if there's a tsearch2
>> index on the table? Can you put together a test case?
> I haven't tried this myself, but the client wrote this very quick script
> th
On Tue, May 31, 2005 at 02:55:29PM -0600, Jonah H. Harris wrote:
> Hey everyone,
>
> I'm sure this has been thought of but was wondering whether anyone had
> discussed the allowance of run-time block size specifications at the
> tablespace level? I know that a change such as this would substant
Yes,
That is what I/my clients have been discussing. It is a nifty
performance feature.
Bricklen Anderson wrote:
Jonah H. Harris wrote:
Hey everyone,
I'm sure this has been thought of but was wondering whether anyone
had discussed the allowance of run-time block size specifications at
Jonah H. Harris wrote:
Hey everyone,
I'm sure this has been thought of but was wondering whether anyone had
discussed the allowance of run-time block size specifications at the
tablespace level? I know that a change such as this would substantially
impact buffer operations, transactions, acc
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I'm sure this has been thought of but was wondering whether anyone had
> discussed the allowance of run-time block size specifications at the
> tablespace level?
Can you produce any evidence whatsoever that this could be worth the cost?
Aside from
On Tue, 31 May 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = where id = ;
client2: update articles set some_col2 = where id = ;
client1: update art
Hey everyone,
I'm sure this has been thought of but was wondering whether anyone had
discussed the allowance of run-time block size specifications at the
tablespace level? I know that a change such as this would substantially
impact buffer operations, transactions, access methods, the storage
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, May 31, 2005 at 02:49:09PM -0400, Tom Lane wrote:
>> It's a rather lame attempt to ensure that you don't get a corrupt copy
>> due to the database changing while you copy it ... I'd like to find
>> a better way to do it ...
> You sounded less en
It seems we are more or less agreed that 32-bit CRC ought to be enough
for WAL; and we also need to make a change to ensure that backup blocks
are positively linked to their parent WAL record, as I noted earlier
today. So as long as we have to mess with the WAL record format, I was
wondering what
On Tue, May 31, 2005 at 02:49:09PM -0400, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > ERROR: source database "template1" is being accessed by other users
>
> > Why is this not allowed?
>
> It's a rather lame attempt to ensure that you don't get a corrupt copy
> due to th
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Just want to make sure that this is, in fact, what is expected:
> client1: begin;
> client1: update articles set some_col = where id = ;
> client2: update articles set some_col2 = where id = ;
> client1: update articles set some_col3 = where id =
On Tue, May 31, 2005 at 02:53:41PM -0300, Marc G. Fournier wrote:
> ERROR: source database "template1" is being accessed by other users
>
> Why is this not allowed? Not that there is generally a reason to be in
> template1, but am curious as to why it prevents a new DB from being
> created if
On Tue, May 31, 2005 at 14:53:41 -0300,
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
>
>
> ERROR: source database "template1" is being accessed by other users
>
> Why is this not allowed? Not that there is generally a reason to be in
> template1, but am curious as to why it prevents a new
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> ERROR: source database "template1" is being accessed by other users
> Why is this not allowed?
It's a rather lame attempt to ensure that you don't get a corrupt copy
due to the database changing while you copy it ... I'd like to find
a better way
On Mon, 2005-05-30 at 21:38 -0700, Luke Lonergan wrote:
> Tom,
>
> This is a story that is evolving. Anyone else use StorageReview? Great
> comprehensive drive benchmarks:
> http://www.storagereview.com/
>
> Check the comparisons between 15K RPM SCSI drives and the 2004 Western
> Digital 10K
On Tue, 31 May 2005 12:07:53 +0100, "Mark Cave-Ayland"
<[EMAIL PROTECTED]> wrote:
>Perhaps Manfred can tell us the generator
>polynomial that was used to create the lookup tables?
32 26 23 22 16 12 11 10 8 7 5 4 2 1
X + X + X + X + X + X + X + X + X + X + X + X +
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = where id = ;
client2: update articles set some_col2 = where id = ;
client1: update articles set some_col3 = where id = ;
client1: ** deadlock **
client2 can't finish its 't
ERROR: source database "template1" is being accessed by other users
Why is this not allowed? Not that there is generally a reason to be in
template1, but am curious as to why it prevents a new DB from being
created if someone is connected to it ...
Marc G. Fournier Hub.Org
Do to moderator error (namely, mine), several hundred messages (spread
across all the lists) were just approved ...
Sorry for all the incoming junk :(
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy
binFZu6XGWBjF.bin
Description:
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>>> Is the random WAL data really the concern? It seems like a more reliable way
>>> of dealing with that would be to just accompany every WAL entry with a
>>> sequential id and stop when the next id isn't the correct one
Tom Lane <[EMAIL PROTECTED]> writes:
> > Is the random WAL data really the concern? It seems like a more reliable way
> > of dealing with that would be to just accompany every WAL entry with a
> > sequential id and stop when the next id isn't the correct one.
>
> We do that, too (the xl_prev link
Josh Berkus writes:
>>> I was wondering whether it will be useful to extend postgreSQL support
>>> to ddl triggers.
>>
>> This has been proposed and rejected before ... see the archives.
> Eh? I thought it was a TODO.
Or "see the TODO list" ... I was looking for some small evidence of
familiar
Tom,
> > I was wondering whether it will be useful to extend postgreSQL support
> > to ddl triggers.
>
> This has been proposed and rejected before ... see the archives.
Eh? I thought it was a TODO.
--Josh
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end
Bruce,
> > >Added to TODO:
> > >
> > >* Add the features of packages
> > > o Make private objects accessable only to objects in the same
> > > schema
> > > o Allow current_schema.objname to access current schema objects
> > > o Add session variables
> > > o Allow
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> It's not really a matter of backstopping the hardware's error detection;
>> if we were trying to do that, we'd keep a CRC for every data page, which
>> we don't. The real reason for the WAL CRCs is as a reliable metho
On Tue, May 31, 2005 at 10:44:58AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > No, the ERROR is in a completely unrelated transaction. The scenario
> > again is this:
>
> > CREATE TABLE foo ();
>
> > BEGIN;
> > DROP TABLE foo;
> > PREPARE TRANSACTION 'foo';
>
>
> >
On Tue, May 31, 2005 at 11:49:20 +0200,
Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
> On Tue, 31 May 2005, Tom Lane wrote:
>
> > The case that convinced me we need to keep some sort of backslash
> > capability is this: suppose you want to put a string including a tab
> > into your database. Try
Barnali <[EMAIL PROTECTED]> writes:
> I was wondering whether it will be useful to extend postgreSQL support
> to ddl triggers.
This has been proposed and rejected before ... see the archives.
regards, tom lane
---(end of broadcast)---
Tom Lane <[EMAIL PROTECTED]> writes:
> It's not really a matter of backstopping the hardware's error detection;
> if we were trying to do that, we'd keep a CRC for every data page, which
> we don't. The real reason for the WAL CRCs is as a reliable method of
> identifying the end of WAL: when th
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > The only thing I'm not clear on is what exactly is the use case for E''
> > strings. That is, who do you expect to actually use them?
>
> The case that convinced me we need to keep some sort of backslash
> capability is this: suppose you
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> No, the ERROR is in a completely unrelated transaction. The scenario
> again is this:
> CREATE TABLE foo ();
> BEGIN;
> DROP TABLE foo;
> PREPARE TRANSACTION 'foo';
> SELECT * FROM foo;
> -
Hi
I was wondering whether it will be useful to extend postgreSQL support
to ddl triggers.
This may be useful for tracking and auditing purposes.
I am planning on prototyping this.
Would be interested to hear any comment.
Thanks
Barnali
---(end of broadcast)-
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 30. Mai 2005 20:11 schrieb Tom Lane:
>> Why don't we instead arrange to run it during install?
> It does currently run during the install. How does that help?
I'm sorry, I meant "later than it is now". Presumably the person doing
the cro
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
>> Alternatively, we might say that 64-bit CRC was overkill from
>> day one, and we'd rather get the additional 10% or 20% or so
>> speedup. I'm kinda leaning in that direction, but only weakly.
> What would you need to persuade you either way? I b
* Jonah H. Harris ([EMAIL PROTECTED]) wrote:
> Is anyone going to be working on this immediately? If so, I'd be glad
> to work with someone. Unfortunately, I don't have the time to devote to
> taking something this big on, but I think it would be a really great
> thing to have. Just let me kn
Am Montag, 30. Mai 2005 20:11 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The problem is that the program zic in src/timezone/ is built and run
> > during the build process, which doesn't work if it's compiled by a
> > cross-compiler.
>
> Why don't we instead arrange to run
Thanks for adding this Bruce!
Is anyone going to be working on this immediately? If so, I'd be glad
to work with someone. Unfortunately, I don't have the time to devote to
taking something this big on, but I think it would be a really great
thing to have. Just let me know [EMAIL PROTECTED]
On Tue, May 31, 2005 at 02:09:56AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > But at awakening, the user will get this:
> > ERROR: relation 66002 deleted while still in use
> > This is ugly -- I don't think there is a way to get out of it.
>
> There had better be a wa
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 27 May 2005 17:49
> To: Mark Cave-Ayland (External)
> Cc: 'Manfred Koizar'; 'Greg Stark'; 'Bruce Momjian';
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
> I went
On Tue, 31 May 2005, Tom Ivar Helbekkmo wrote:
> ...or ^V followed by TAB, as per age-old tradition. :-)
Right, I forgot about that one. One can also do other control characters
instead of TAB by pressing CTRL-J and similar.
Well, I just wanted to point out that it's possible. The main problem
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> To insert a tab using readline you can press ESC followed by TAB.
...or ^V followed by TAB, as per age-old tradition. :-)
-tih
--
Don't ascribe to stupidity what can be adequately explained by ignorance.
---(end of broadca
On Tue, 31 May 2005, Tom Lane wrote:
> The case that convinced me we need to keep some sort of backslash
> capability is this: suppose you want to put a string including a tab
> into your database. Try to do it with psql:
> t=> insert into foo values ('
> Guess what: you won't get anywhere,
73 matches
Mail list logo
