On 11/11/2005 2:20 PM, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Surely they require a unique constraint --- else the behavior isn't
even well defined, is it?
They require that the merge condition does not match for more than one
row, but since the merge c
On 11/20/2005 11:23 AM, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
On Sat, 2005-11-19 at 12:22 -0500, Tom Lane wrote:
... The problem is that given the
current structure, that means changing the APIs of heap_insert and
heap_update, or else making near-duplicate versions that take
On 10/20/2005 2:17 AM, Greg Stark wrote:
(I can't believe anyone really wants varchar to be space padded. Space padding
always seemed like a legacy feature for databases with fixed record length
data types. Why would anyone want a string data type that can't represent all
strings?)
They must h
On 9/24/2005 8:17 PM, Jim C. Nasby wrote:
Would it be difficult to vacuum as part of a dump? The reasoning behind
this is that you have to read the table to do the dump anyway,
I think aside from what's been said so far, it would be rather difficult
anyway. pg_dump relies on MVCC and require
On 8/18/2005 5:14 AM, Qingqing Zhou wrote:
""Marc G. Fournier"" <[EMAIL PROTECTED]> writes
I've done a grep through the code, to see if its something that we do use,
and
it doesn't seem to come back with anything ... I believe its considered
common knowledge that 'swapping' for a database is
On 6/28/2005 5:55 AM, Peter Eisentraut wrote:
Neil Conway wrote:
I agree the current parser is a hack, but it's difficult to see how
else it could be implemented.
Since the lexical structure of SQL/PSM seems to be about the same as the
main SQL, maybe you could get away with having the main p
On 6/26/2005 4:10 PM, Pavel Stehule wrote:
On Sun, 26 Jun 2005, Tom Lane wrote:
"Denis Lussier" <[EMAIL PROTECTED]> writes:
> For various technical and backward compatibility reasons, I don't think
> SQL/PSM should be a replacement for PL/pgSQL. Although I do think it
> should heavily leverag
On 6/25/2005 6:58 PM, Tom Lane wrote:
I wrote:
It seems our choices are (a) somehow fix things so CREATE DATABASE
replay doesn't have to zap the whole directory, (b) force a checkpoint
immediately after any CREATE DATABASE, so that we never have to replay
one except in a PITR situation, or (c) a
On 6/22/2005 1:29 AM, Neil Conway wrote:
Tom Lane wrote:
The long-term point in my mind is that removing syntactical
redundancy always reduces the ability to detect errors or report
errors acccurately
Lexical scoping is unambiguous in a language like PL/PgSQL. Since it is
simple to determine
Added pgsql-hackers
Added Bruce Momjian
On 6/23/2005 12:19 PM, Michael Fuhr wrote:
The question I have is how exactly you manage to get the trigger fired
when restoring the dump. By default, the dump created by pg_dump will
create the table, fill in the data and create the trigger(s) only afte
On 6/13/2005 2:29 PM, Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip&#
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing something other than what the user requested ... I don't
think this is the right way to become the most popular open
On 6/10/2005 3:04 PM, Tom Lane wrote:
pgbench: I see repeated complaints on -performance about how
pgbench results are misleading. Why are we shipping it with
PostgreSQL then?
It's handy to have *some* simple concurrent-behavior test included,
even if it's not something we put a lot of stoc
On 4/26/2005 5:58 PM, Tom Lane wrote:
David Wheeler <[EMAIL PROTECTED]> writes:
No, you can have multiple queries--you just have to understand that
those that come first might have an effect on those that come later.
... which indeed can be a feature, not a bug, depending on what you're
doing ...
On 4/26/2005 3:01 PM, Rob Butler wrote:
Are rules even needed anymore? Can't you do this all
with triggers? If you want to "DO INSTEAD" just use a
row based trigger, and return null. Or is this less
efficient?
On INSERT, yes, on UPDATE, how so?
Jan
Later
Rob
--- David Wheeler <[EMAIL PROTECTED]>
On 4/22/2005 3:53 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
tuples fetched is the number of raw, possibly dead tuples fetched from
the heap. Tuples returned is the number of alive tuples ... IIRC.
No, count_heap_fetch only counts tuples that have already passed the
snapsho
On 4/22/2005 3:30 PM, Tom Lane wrote:
Josh Berkus writes:
Well, technically a bitmapscan is a different operation. So it should
probably have its own columns. Unless you're talking about an overhaul of
the stats views more drastic than that? If so, what?
That was basically what I was asking
On 1/25/2005 6:23 PM, Marc G. Fournier wrote:
On Tue, 25 Jan 2005, Bruce Momjian wrote:
pgman wrote:
Not yet --- I suggested it but didn't get any yeas or nays. I don't
feel this is solely core's decision anyway ... what do the assembled
hackers think?
I am not in favor of adjusting the 8.1 releas
On 1/17/2005 1:15 AM, Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
FYI, IBM has applied for a patent on ARC (AFAICS the patent application
is still pending, although the USPTO site is a little hard to grok):
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u
On 12/15/2004 12:10 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Still, we need to avoid scanning over all the clean blocks of a large
buffer pool, so there is need for a separate dirty-LRU.
That's not happening, unless you want to undo the cntxDirty stuff,
with unknown i
On 12/14/2004 2:40 PM, Tom Lane wrote:
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
Is it possible to do a patch that produces a dirty buffer list in LRU order
and stops early when eighter maxpages is reached or bgwriter_percent
pages are scanned ?
Only if you redefine the meaning of bg
On 12/12/2004 9:43 PM, Neil Conway wrote:
On Sun, 2004-12-12 at 22:08 +, Simon Riggs wrote:
> On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
> Is the plan to make bgwriter_percent = 100 the default setting?
Hmm...must confess that my only plan is:
i) discover dynamic behaviour of bgwriter
ii)
On 12/12/2004 5:08 PM, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Simon Riggs wrote:
> If the bgwriter_percent = 100, then we should actually do the sensible
> thing and prepare the list that we need, i.e. limit
> StrategyDirtyBufferList to finding at most bgwriter_maxpages.
On 12/3/2004 12:23 PM, Thomas Hallgren wrote:
Jan Wieck wrote:
There is no "try" in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
On 12/2/2004 3:18 AM, Thomas Hallgren wrote:
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
On 12/2/2004 8:16 PM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One more issue. Until we start RC, patches that are bug fixes will
> continue to be applied. Do we want that? By going RC we are basically
> saying we need to focus on docs and packaging and we
On 12/1/2004 1:35 PM, Brett Schwarz wrote:
--- Jan Wieck <[EMAIL PROTECTED]> wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
> On 12/1/2004 4:27 AM, Richard Huxton wrote:
>
>> Thomas Hallgren wrote:
>>> Richard Huxton wrote:
>>>
>>>> Can I mak
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then roll
On 11/29/2004 2:03 PM, Marc G. Fournier wrote:
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using
the mailing lists?
Certainly not.
Jan
The USENET community seems to think that there would be a mass exodu
On 11/27/2004 7:40 PM, Tom Lane wrote:
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
So why not have VACUUM FULL FREEZE just do what you propose: VACUUM
FULL then VACUUM FREEZE.
The objective is to make it more safe, not less so. Doing that would
require rewriting a whole bunch of code, which
On 11/29/2004 10:43 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I don't agree that the right cure is to execute each and every statement
itself as a subtransaction. What we ought to do is to define a wrapper
for the catch Tcl command, that creates a subtransaction and ex
On 11/19/2004 7:54 PM, Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be mad
On 11/18/2004 11:43 AM, Tom Lane wrote:
"David Parker" <[EMAIL PROTECTED]> writes:
What I think is happening with the missing pg_statistic entries:
The install of our application involves a lot of data importing (via
JDBC) in one large transaction, which can take up to 30 minutes. (I
realize I left
On 11/10/2004 11:57 PM, Mark Kirkwood wrote:
Your example and ones like :
SELECT max(foo), count(foo) FROM bar
SELECT max(a.foo1), max(b.foo2) FROM bar1 AS a NATURAL JOIN bar2 AS b
have made me realize that the scope of "what should be optimized" is
somewhat subtle.
I am inclined to keep it simpl
On 11/8/2004 5:32 PM, Tom Lane wrote:
Another relevant question is why you are expecting to get this
information through pgstats and not by looking in the postmaster log.
The pgstats were originally designed to give "hints" for tuning. That's
why they cover cache hits vs. misses per table and numb
On 11/8/2004 12:03 PM, D'Arcy J.M. Cain wrote:
I checked the FAQ and docs but haven't found anything definitive. This
is my SQL test script:
SELECT pg_backend_pid();
SELECT * FROM pg_stat_activity order by procpid;
When I run psql reading that I find that my backend procpid is not in
the list. I
On 11/4/2004 5:44 PM, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Moved to -hackers where this belongs :)
On Fri, 5 Nov 2004, Justin Clift wrote:
Would making max_fsm_relations and max_fsm_pages dynamically update
themselves whilst PostgreSQL runs be useful?
Possibly, but it is
On 10/26/2004 1:53 AM, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> writes:
Another issue is what we do with the effective_cache_size value once we
have a number we trust. We can't readily change the size of the ARC
lists on the fly.
Huh? I thought effective
On 10/22/2004 4:09 PM, Kenneth Marshall wrote:
On Fri, Oct 22, 2004 at 03:35:49PM -0400, Jan Wieck wrote:
On 10/22/2004 2:50 PM, Simon Riggs wrote:
>I've been using the ARC debug options to analyse memory usage on the
>PostgreSQL 8.0 server. This is a precursor to more complex
On 10/22/2004 4:21 PM, Simon Riggs wrote:
On Fri, 2004-10-22 at 20:35, Jan Wieck wrote:
On 10/22/2004 2:50 PM, Simon Riggs wrote:
>
> My proposal is to alter the code to allow an array of memory linked
> lists. The actual list would be [0] - other additional lists would be
> created
On 10/22/2004 2:50 PM, Simon Riggs wrote:
I've been using the ARC debug options to analyse memory usage on the
PostgreSQL 8.0 server. This is a precursor to more complex performance
analysis work on the OSDL test suite.
I've simplified some of the ARC reporting into a single log line, which
is encl
On 10/22/2004 12:23 PM, Michael Paesold wrote:
D'Arcy J.M. Cain wrote:
I have an idea for a change to the contributed module pg_autovacuum that
I would like to run by people. What I want to do is make sure that when
vacuum (or analyze) runs that it takes no time from actual transactions.
To this e
lias is using Slony-I in production, Andrew
Sullivan will not let me do whatever I want if there's a severe problem
nobody else can fix.
So don't worry, I'll be around.
Jan
Ed
On Friday October 22 2004 7:26, Jan Wieck wrote:
Sorry folks,
the Slony-I team has produced a great product,
Sorry folks,
the Slony-I team has produced a great product, but the project
management (that's mostly me here) sucks big time!
Shortly after giving Chris Browne green light for the 1.0.4 announcement
we found a way to guard against bug #896. That being a really bad one I
decided to stop the 1.0
s, section 21.1.3, for an
explanation of why this is. I think the 7.0 docs don't contain all
that info, BTW). We have a very dangerous tool we've used for testing
that will thump the xid in 7.2, but I have no idea whether that'd
work in versions prior to that. Jan Wieck might know,
On 10/19/2004 12:11 PM, Andreas Pflug wrote:
Marc G. Fournier wrote:
Enjoy the break :) Hints as to the 'other stuff' that is more
intersting then PostgreSQL? :) Or is it secret ... ?
It's probably just a joke. Can you imagine something more interesting
than PostgreSQL?!?
There comes the time i
Trying to think a little out of the box, how "common" is it in modern
operating systems to be able to swap out shared memory?
Maybe we're not using the ARC algorithm correctly after all. The ARC
algorithm does not consider the second level OS buffer cache in it's
design. Maybe the total size of
On 10/17/2004 3:40 PM, [EMAIL PROTECTED] wrote:
Seeing as I've missed the last N messages... I'll just reply to this
one, rather than each of them in turn...
Tom Lane <[EMAIL PROTECTED]> wrote on 16.10.2004, 18:54:17:
I wrote:
> Josh Berkus writes:
>> First off, two test runs with OProfile are ava
Any chance for bad memory?
Jan
On 9/30/2004 6:16 AM, Gaetano Mendola wrote:
Hi all,
I'm running postgres 7.4.5 on a linux box, this morning I got this error on my logs:
WARNING: FlushRelationBuffers("exp_provider", 1836): block 1460 is referenced
(private 0, global 1)
ERROR: FlushRelationBuffers
On 9/24/2004 10:24 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Now the scary thing is that not only did this crash rollback a committed
transaction. Another session had enough time in between to receive a
NOTIFY and select the data that got rolled back later.
Different sessi
On 9/24/2004 6:37 PM, Tom Lane wrote:
Can you still reproduce the problem if you take out the ereport call
in quickdie()?
Will check ...
BTW, what led you to develop this test setup ... had you already seen
something that made you suspect a data loss problem?
Good guess ... what actually happenend
On 9/24/2004 5:12 PM, Tom Lane wrote:
This means either that the server sent a commit message before it had
xlog'd the commit, or that Pgtcl mistakenly reported the command as
successful when it was not. Any thoughts?
Is it somehow possible that the commit record was still sitting in the
shared W
The attached archive contains a script that I used to reproduce the
error multiple times.
Setup:
* create database crashtest
* start 6 instances of testload.tcl as
./testload.tcl tN dbname=crashtest
where N = 1..6
* frequently kill a backend to cause a postmaster restart.
The te
On 9/20/2004 2:02 AM, Michael Paesold wrote:
The bgwriter always flushes the oldest dirty buffers, and every buffer
touched (hit or faulted in). The output above doesn't tell you how many
buffers are really dirty. But if the system is under load, that is
pretty much the same as the distance between
On 9/18/2004 8:38 AM, Michael Paesold wrote:
Tom Lane wrote:
There is some debug output available from the ARC code,
but I dunno if its output is actually useful ;-). Try
http://developer.postgresql.org/docs/postgres/runtime-config.html#GUC-DEBUG-SHARED-BUFFERS
"debug_shared_buffers (integer)
Num
On 9/17/2004 7:32 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The problem comes and goes. So either I can cause a coredump just on the
snap by running a shellscript that does 100 psql -c "select version()"
calls, or it is next to impossible to crash it at all.
Hm
On 4/19/2004 1:18 PM, Jan Wieck wrote:
Tom Lane wrote:
Andrew Sullivan <[EMAIL PROTECTED]> writes:
On Thu, Apr 15, 2004 at 07:52:59PM -0400, Tom Lane wrote:
I can see from your trace that you are using the getaddrinfo code from
libc, but where is configure finding a header that declares
On 9/1/2004 9:02 PM, Gaetano Mendola wrote:
Jan Wieck wrote:
Which is another point I was about to ask. How do these people, running
those huge and horribly important databases, ever test a single
application change? Or any schema changes for that matter. Do they
really type "psql -c &
On 9/1/2004 1:51 PM, Serguei A. Mokhov wrote:
Date: Tue, 31 Aug 2004 23:35:18 -0400
On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:
On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
On Tue, 31 Aug 2004, Josh Berkus wrote:
Andrew,
If I were loony enough to want to make an attempt at a version
update
On 9/1/2004 10:29 AM, Joe Conway wrote:
Jeff wrote:
On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
Huh?You can replicate onto the same server.Kicks your
performance in
the teeth but it works fine. Heck, I did it on my laptop as a demo.
Doesn't work If you have say, a 100GB db and only 5
On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:
On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
On Tue, 31 Aug 2004, Josh Berkus wrote:
Andrew,
If I were loony enough to want to make an attempt at a version
updater
(i.e. migrate a
7.4 database to 8.0 without an initdb), any suggestions on where
On 8/25/2004 1:32 AM, Greg Stark wrote:
A dirty read is a read that includes data that hasn't been committed yet. Or
as the SQL 92 standard puts it:
[...]
It could also be useful for referential integrity checks since, for example,
it would let you see if someone has deleted the referenced record b
On 8/14/2004 11:38 PM, Tom Lane wrote:
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
I see stats collector processes die in current when I suspend
postmaster then put it in background from a terminal:
Is this normal?
Doesn't 7.4 behave the same?
It looks to me like 7.4 and current have the same signal
I have seen similar when running under heavy load with high frequent
insert+delete+vacuum. What happens is that adding another item to an
index page in the btree access method fails. It seems to me that the
decision to add an item to a page and the real work of actually adding
it are not atomic
On 8/9/2004 7:41 PM, Gaetano Mendola wrote:
If I remember well this is the first command that need to change
GUC in order to change behaviour, I don't think we wrote:
set vacuum_mode = full;
set vacuum_verbosity = on;
vacuum;
You got a point here. However, we don't have
SELECT foo FROM bar WHER
On 8/9/2004 3:46 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 8/8/2004 11:58 AM, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The only open issue I see for beta1 is perhaps disabling vacuum delay.
>
> Given that Jan is clearly in the minority on that, I s
On 8/9/2004 1:19 PM, Gaetano Mendola wrote:
Jan Wieck wrote:
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM
On 8/9/2004 12:53 PM, Josh Berkus wrote:
People,
> DELETE FROM target_tbl USING other_tbls WHERE ...
Feels much more understandable. The second FROM looks like a hickup.
Yes, although imagine:
DELETE FROM staff USING users JOIN logons USING (user_id)
WHERE last_logon < ( now() - '6 months');
On 8/8/2004 11:58 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
The only open issue I see for beta1 is perhaps disabling vacuum delay.
Given that Jan is clearly in the minority on that, I suggest we just
turn it off for beta1. We can always turn it on later if he manages
to convin
On 8/9/2004 7:19 AM, Gaetano Mendola wrote:
Hi all,
I have seen the big debat about to have the delay
off or on by default.
Why not enable it by default and introduce a new
parameter to vacuum command itself ? Something like:
VACUUM WITH DELAY 100;
It's not just one parameter to tune here. It
On 8/9/2004 12:29 AM, Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
Well, as yall have pointed out, the feature is not sql spec (for some
reason I thought it had been put in) so since the update syntax seems
quite similar to oracles, perhaps they can provide a pointer on delete
syntax as
On 8/3/2004 11:38 PM, Greg Stark wrote:
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
On Tue, 2004-08-03 at 13:05, CSN wrote:
> Just wondering, is updateable views slated for a
> future version of Postgresql? In addition to using
> rules that is.
I would think that a basic fleshing out of the logic w
On 8/6/2004 11:34 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 8/6/2004 9:04 PM, Bruce Momjian wrote:
> Updated. Thanks.
I thought we want to have the feature activated ... I reversed your
change and brought guc.c in sync instead.
Uh, if the guy is doing a vacuum at night, does he want the de
On 8/6/2004 9:04 PM, Bruce Momjian wrote:
Updated. Thanks.
I thought we want to have the feature activated ... I reversed your
change and brought guc.c in sync instead.
Jan
---
Matthew T. O'Connor wrote:
Related to autovacuu
First of all "promised at OSCON to fix" is a bit exaggerated. I said I
will look into the issue and see what can be done.
Having done something similar for the SPI manager once, so that
parameters can have unknown type and the code calling SPI_prepare() will
find the chosen types in the type ar
On 7/14/2004 1:13 PM, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by th
On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:
Yes, but it has been committed, it will be released - the only thing is
that people will have to wait a few more months for it. My point was
Just a few more months? That is exactly what I was asking for, put some
of the stuff into 7.6 so it w
ase?
Hmmm ... I wonder what you think who those people are who "want" ARC
right this second, and who "you guys" are on the other hand.
To fill you in a little, I am the PostgreSQL CORE team member Jan Wieck,
who burned Afilias payroll hours to implement the ARC buffer replacem
On 7/11/2004 12:22 AM, Alvaro Herrera wrote:
There is not a lot of difference. This was allowed in nested
transactions because we wanted the nesting be to OK when using it in a
possibly aborted transaction block, so the user would not commit a
transaction that could not have been created. In save
On 7/10/2004 6:55 PM, Josh Berkus wrote:
Bruce,
It seems anonymous savepoints really don't buy us anything. They don't
match the Oracle behavior, and don't do anything more than nested
transactions. I agree we want them, but I don't see the value they add
value right now.
Anonymous Savepoints == N
On 7/10/2004 11:02 PM, Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Marc isn't the only one who didn't like waiting for more features going
into 7.5 two mont
On 7/10/2004 10:54 AM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we want to add this to TODO:
>* Issue an extra message when COMMIT completes a failed transaction
No --- it's (a) wordy and (b) not responsive to the original complaint,
which was that a
On 7/10/2004 3:21 PM, Simon Riggs wrote:
On Sat, 2004-07-10 at 15:04, Jan Wieck wrote:
> ...Nobody is shouting YES, so its a dodo...
No way!
Sorry...I meant "this idea is dead, just like the extinct Dodo bird".-
I've been trying to be succinct, but that has led to inform
, I see that it does it in create_sub() now ... thanks for the
clearification.
Jan
cheers
andrew
Jan Wieck wrote:
while playing with the OSCON CD's, I noticed that the current version
of plperl installs the same function handler for both, plperl and
plperlu. I was wondering how it implement
On 7/6/2004 3:58 PM, Simon Riggs wrote:
On Tue, 2004-07-06 at 08:38, Zeugswetter Andreas SB SD wrote:
> - by time - but the time stamp on each xlog record only specifies to the
> second, which could easily be 10 or more commits (we hope)
>
> Should we use a different datatype than time_t for
On 7/5/2004 6:16 PM, Simon Riggs wrote:
On Mon, 2004-07-05 at 22:30, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
> ...While recovering, it is very straightforward to simply ignore every
> record associated with one (or more) transactions. That gives us the
> ability to recover "all apar
while playing with the OSCON CD's, I noticed that the current version of
plperl installs the same function handler for both, plperl and plperlu.
I was wondering how it implements the important security difference or,
in case it is not handled and both are in fact the same, who ignored
this IMHO
On 6/12/2004 3:45 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
But a per relation bitmap that tells if a block is a) free of dead
tuples and b) all remaining tuples in it are frozen could be used to let
vacuum skip them (there can't be anything to do). The bit would
On 6/10/2004 10:37 AM, Shridhar Daithankar wrote:
[EMAIL PROTECTED] wrote:
The session table is a different issue, but has the same problems. You
have an active website, hundreds or thousands of hits a second, and you
want to manage sessions for this site. Sessions are created, updated many
times,
On 6/10/2004 8:49 AM, Bruce Momjian wrote:
Jan Wieck wrote:
Make it so that --enable-thread-safety bombs out, but make another
--enable-thread-safey-anyway work the way Tom descibed it.
Sure, we can do that by just not running the thread_test program. In
fact a cross-compile already skips
On 6/10/2004 2:11 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was
A new BETA tarball for the Slony-I replication system is now available
for download form the project homepage:
http://gborg.postgresql.org/project/slony1/projdisplay.php
Regards, the Slony-I project team
---(end of broadcast)---
TIP 7: don't fo
On 6/9/2004 1:44 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> What we really need is a way to do the uid->username mapping in a
> thread-safe way. Could we check the environment for $USER or $LOGNAME?
> Could we require them to be set for thre
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid->username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases where the username is not spe
On 6/8/2004 11:46 AM, [EMAIL PROTECTED] wrote:
This strikes me as a complete nonstarter.
Tom, I have to chuckle here. You HATE every suggestion I ever make. I
can't think of one thing I've suggested over the years that was ever met
with enthusiasm. Never change. :-)
I happen to agree with Tom on th
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> Jan Wieck wrote:
>> I am wondering why thread_test.c is checking for mktemp()? That function
>> is nowhere used in the libpq.
>
> Uh, it isn't checking for mktemp,
On 6/9/2004 11:45 AM, Bruce Momjian wrote:
Jan Wieck wrote:
The problem is that if your thread-safety tests fail, there is no way to
build libpq with -pthread and -DREENTRANT or whatever is required on
that platform. On Solaris this results in errno being defined as
extern int errno;
as
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was us
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application has to have
mutexes around certain operations, but being entir
301 - 400 of 970 matches
Mail list logo
