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 way, since (I suppose) the ERROR is preventing the
commit from succeeding
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 ('TAB
Guess what: you won't get anywhere,
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
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
-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 back
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 way, since
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]
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 it during
* 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 know
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 believe
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
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
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;
-- hangs
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 want to
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 the
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
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 to do it
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';
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 method of
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 nested schemas
Hmmm
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 of
Josh Berkus josh@agliodbs.com 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
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 links and
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.
We do
binFZu6XGWBjF.bin
Description:
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
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1: update articles set some_col3 = foo where id = bar;
client1: ** deadlock **
client2
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 + X +
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 RPM
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 to do
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 DB from
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
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 = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1: update articles set some_col3 = foo
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 the database
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
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
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
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 = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1:
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 the
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,
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
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
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
that
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
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
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:
(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
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
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
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
sequential id
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 consecutive
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 evidence
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
Hi all,
I'm now interested in audit facilities for database accessing.
Are anyone thinking or working on audit stuffs?
--
NAGAYASU Satoshi [EMAIL PROTECTED]
OpenSource Development Center,
NTT DATA Corp. http://www.nttdata.co.jp/
---(end of
From: "Satoshi Nagayasu" [EMAIL PROTECTED]
Hi all,
I'm now interested in audit facilities for database accessing.
Are anyone thinking or working on audit stuffs?
http://archives.postgresql.org/pgsql-general/2004-08/msg01439.php
I remember that the approach which he
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,
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrencyrecovery 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
Christopher Kings-Lynne wrote:
unfortunately, we still couldn't find 2-3 months for dedicated work on
concurrencyrecovery 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
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
Hiroshi Saito wrote:
http://archives.postgresql.org/pgsql-general/2004-08/msg01439.php
I remember that the approach which he enjoyed was being done.
Thanks for the information.
However, I hope variously as a function of the PostgreSQL core.
I hope they goes into the
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
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.
Finally, I found the tablelog project at the pgFoundary...
http://pgfoundry.org/projects/tablelog/
Satoshi Nagayasu wrote:
Hiroshi Saito wrote:
http://archives.postgresql.org/pgsql-general/2004-08/msg01439.php
I remember that the approach which he enjoyed was being
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.
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 already a
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
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
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 reminded that
On May 31, 2005, at 1:40 AM, Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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 ;
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 recovery
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 really quite
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
72 matches
Mail list logo
