Am Mittwoch, 10. Mai 2006 22:23 schrieb Mark Dilger:
> Martijn van Oosterhout wrote:
> > On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
> Could we make BEGIN fail when we already are in a transaction?
...
>
> Or if you really want to screw things up, you could require COMMIT; C
Folks,
We are approaching our ceiling of 75 attendees for the PostgreSQL Anniversary.
If you are planning to come, and have not registered, you should do so ASAP.
conference.postgresql.org
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)
Tom Lane skrev:
The SQL99 spec does say (in describing START TRANSACTION,
which is the standard spelling of BEGIN)
1) If a statement is executed when an
SQL-transaction is currently active, then an exception condition
is raised: invalid transaction state - activ
Tom Lane wrote:
> Log Message:
> ---
> Clean up code associated with updating pg_class statistics columns
> (relpages/reltuples). To do this, create formal support in heapam.c for
> "overwrite" tuple updates (including xlog replay capability) and use that
> instead of the ad-hoc overwrites
On 5/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Martijn van Oosterhout writes:
> How do other database deal with this? Either they nest BEGIN/COMMIT or
> they probably throw an error without aborting the transaction, which is
> pretty much what we do. Is there a database that actually aborts a
>
I forgot to mention it in the commit message, but this patch
http://archives.postgresql.org/pgsql-committers/2006-05/msg00069.php
includes a fix to avoid "tuple concurrently updated" failures in
CREATE INDEX's update of the parent relation's pg_class entry.
I'm still not convinced that that's where
Joachim Wieland <[EMAIL PROTECTED]> writes:
> The documentation suggests that the hostname part of .pgpass can be set to
> "localhost" to allow for automatic unix domain socket authentication. This
> doesn't seem to work. Instead you have to set the directory of the socket as
> the hostname part.
Martijn van Oosterhout writes:
> How do other database deal with this? Either they nest BEGIN/COMMIT or
> they probably throw an error without aborting the transaction, which is
> pretty much what we do. Is there a database that actually aborts a
> whole transaction just for an extraneous begin?
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, May 09, 2006 at 03:13:01PM -0400, Tom Lane wrote:
>> PFC <[EMAIL PROTECTED]> writes:
>>> Fun thing is, the rowcount from a temp table (which is the problem here)
>>> should be available without ANALYZE ; as the temp table is not concurrent,
>
The documentation for the .pgpass file seems to be incorrect with respect to
unix domain sockets.
There's also a user comment saying that:
http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
The documentation suggests that the hostname part of .pgpass can be set to
"localhost" to al
On Thu, May 11, 2006 at 12:09:32AM +0200, Martijn van Oosterhout wrote:
> > > This stack trace doesn't make any sense. ClosePostmasterPorts is not
> > > calling PostgresMain. And pq_getbyte is not calling TouchSocketFile,
> > > which in turn isn't calling secure_read.
> >
> > So I see... that's
On Wed, May 10, 2006 at 04:52:38PM -0500, Jim C. Nasby wrote:
> On Wed, May 10, 2006 at 04:24:45PM -0400, Alvaro Herrera wrote:
> > Jim C. Nasby wrote:
> > > We tried reproducing this on a backup server. We haven't been able to
> > > wedge the system into a state where there's tons of sblock proces
On Wed, May 10, 2006 at 04:24:45PM -0400, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > We tried reproducing this on a backup server. We haven't been able to
> > wedge the system into a state where there's tons of sblock processes
> > and nothing's getting done, but we were able to get some proce
On Wed, May 10, 2006 at 04:03:51PM -0500, Jim C. Nasby wrote:
> On Wed, May 10, 2006 at 12:31:52PM +0200, Mario Weilguni wrote:
> > Maybe. I just want to emphasize that it will break existing applications.
>
> If the existing application is trying to start a new transaction from
> within an existi
Here is some work someone has done:
http://archives.postgresql.org/pgsql-patches/2006-03/msg00258.php
See the followup for feedback. Seems it could be cleaned up.
---
Zdenek Kotala wrote:
>
> I would like to impl
On Wed, May 10, 2006 at 12:31:52PM +0200, Mario Weilguni wrote:
> Am Mittwoch, 10. Mai 2006 10:59 schrieb Peter Eisentraut:
> > Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
> > > You want to make a GUC that makes:
> > >
> > > BEGIN;
> > > BEGIN;
> > >
> > > Leave you with an abor
There is/was a pg_autotune project, but it was pretty rudamentary and
didn't work very well when I tried it circa 2001. Your best bet is
probably to either do a lot of research, or hire a consultant.
On Tue, May 09, 2006 at 05:34:26PM +0530, Dhanaraj M wrote:
> I am currently looking at some perfo
Jim C. Nasby wrote:
> We tried reproducing this on a backup server. We haven't been able to
> wedge the system into a state where there's tons of sblock processes
> and nothing's getting done, but we were able to get some processes into
> sblock and get stack traces:
>
> #0 0x00080135bd2c in
Martijn van Oosterhout wrote:
> On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
>
Could we make BEGIN fail when we already are in a transaction?
>>>
>>>We could, but it'd probably break about as many apps as it fixed.
>>>I wonder whether php shouldn't be complaining about this,
Zdenek Kotala wrote:
> I performed some investigation and I found that signal handler
> (SIGHUP_handler) contents a big code and contents signal nonsafe
> functions. It should generate deadlock or damage some internal data
> structure in the standard c library. See
> http://www.opengroup.org/onlin
We tried reproducing this on a backup server. We haven't been able to
wedge the system into a state where there's tons of sblock processes
and nothing's getting done, but we were able to get some processes into
sblock and get stack traces:
#0 0x00080135bd2c in recvfrom () from /lib/libc.so.6
On Tue, May 09, 2006 at 06:29:31PM +0200, PFC wrote:
You mean the cursors'storage is in fact the same internal machinery
as a temporary table ?
Use the source, Luke...
LOL, yeah, I should have, sorry.
See tuplestore_begin_heap in backend/utils/sort/tuplestore.c an
Have you tried getting a profile of what exactly PostgreSQL is doing
that takes so long when creating a temp table?
Nope, I'm not proficient in the use of these tools (I stopped using C
some time ago).
BTW, I suspect catalogs might be the answer,
Probably, because :
-
On Tue, May 09, 2006 at 06:29:31PM +0200, PFC wrote:
> You mean the cursors'storage is in fact the same internal machinery
> as a temporary table ?
Use the source, Luke...
See tuplestore_begin_heap in backend/utils/sort/tuplestore.c and
heap_create_with_catalog in backend/catalog/he
Speaking of which, if a temp table is defined as ON COMMIT DROP or
DELETE ROWS, there shouldn't be any need to store xmin/xmax, only
cmin/cmax, correct?
Yes, that's that type of table I was thinking about...
You can't ROLLBACK a transaction on such a table.
You can however rol
On Tue, May 09, 2006 at 01:29:56PM +0200, PFC wrote:
> 0.101 ms BEGIN
> 1.451 ms CREATE TEMPORARY TABLE tmp ( a INTEGER NOT NULL, b INTEGER NOT
> NULL, c TIMESTAMP NOT NULL, d INTEGER NOT NULL ) ON COMMIT DROP
> 0.450 ms INSERT INTO tmp SELECT * FROM bookmarks ORDER BY annonce_id DESC
> LIMIT 2
On Tue, May 09, 2006 at 03:13:01PM -0400, Tom Lane wrote:
> PFC <[EMAIL PROTECTED]> writes:
> > Fun thing is, the rowcount from a temp table (which is the problem
> > here)
> > should be available without ANALYZE ; as the temp table is not concurrent,
> > it would be simple to inc/decremen
I would like to implement following item from TODO list:
* Allow commenting of variables in postgresql.conf to restore them to
defaults. Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.
Does anybody work on it?
I performed some investi
On Tue, May 09, 2006 at 11:33:42AM +0200, PFC wrote:
> - Repeating the query might yield different results if records were
> added or deleted in the meantime.
BTW, SET TRANSACTION ISOLATION LEVEL serializeable or BEGIN ISOLATION
LEVEL serializeable would cure that.
--
Jim C. Nasby,
I would suggest the guy simply use the popular ADODB package for his
database abstraction layer so he can make use of its "Smart Transaction"
feature.
http://phplens.com/lens/adodb/docs-adodb.htm#ex11
Lastly, StartTrans/CompleteTrans is nestable, and only the outermost
block is executed. In con
Simon Riggs wrote:
> Could you turn full_page_writes = off and do a few more tests? I think
> the full page writes is swamping the xlog and masking the performance we
> might see for normal small xlog writes.
> I'd try XLOG_BLCKSZ = 4096 and 8192 to start with. Thanks.
Ok, got data for XLOG_BLCKXZ
I dont think anyone is arguing that such an application is not
broken. We should see how we can stop a developer from writing buggy
code.
IMO, such a GUC variable _should_ be created and turned on by default.
In case an application fails, at the least, the developer knows
that his appli
Peter Eisentraut skrev:
Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
You want to make a GUC that makes:
BEGIN;
BEGIN;
Leave you with an aborted transaction? That seems like a singularly
useless feature...
If a command doesn't do what it is supposed to do, then it s
Hi, Nils,
Nis Jorgensen wrote:
> It will probably be quite common for the number to depend on the number
> of rows in other tables. Even if this is fairly constant within one db
> (some assumption), it is likely to be different in others using the same
> function definition. Perhaps a better solu
Martijn van Oosterhout wrote:
> On Wed, May 10, 2006 at 04:38:31PM +0200, PFC wrote:
>> You need to do some processing to know how many rows the function
>> would return.
>> Often, this processing will be repeated in the function itself.
>> Sometimes it's very simple (ie. the
The reason the cast isn't found is that find_coercion_pathway() strips
off the domains before it ever even looks in pg_cast. We can't simply
remove that logic without breaking things (notably, the ability to cast
between a domain and its base type). I think it would be a mistake to
consider th
Hi, PFC,
PFC wrote:
> You need to do some processing to know how many rows the function
> would return.
> Often, this processing will be repeated in the function itself.
> Sometimes it's very simple (ie. the function will RETURN NEXT each
> element in an array, you know the array le
On Wed, May 10, 2006 at 04:38:31PM +0200, PFC wrote:
> You need to do some processing to know how many rows the function
> would return.
> Often, this processing will be repeated in the function itself.
> Sometimes it's very simple (ie. the function will RETURN NEXT each
The problem is that you need a set-returning function to retrieve
the values. SRFs don't have rowcount estimates, so the plans suck.
What about adding some way of rowcount estimation to SRFs, in the way of:
CREATE FUNCTION foo (para, meters) RETURNS SETOF bar AS
$$ ... function code ...
Hi, PFC,
PFC wrote:
> The problem is that you need a set-returning function to retrieve
> the values. SRFs don't have rowcount estimates, so the plans suck.
What about adding some way of rowcount estimation to SRFs, in the way of:
CREATE FUNCTION foo (para, meters) RETURNS SETOF bar AS
$$
--On Mittwoch, Mai 10, 2006 12:36:07 +0200 Mario Weilguni
<[EMAIL PROTECTED]> wrote:
Such a behavior is already broken by design. I think it's not desirable
to blindly do
transaction start or commit without tracking the current transaction
state. So these wrappers
need to be fixed first.
Y
I could see the following in TODO list
but I am not clear what is expected out of this.
Can anyone explain this?
1. *Allow VIEW/RULE recompilation when the underlying tables change *
*Another issue is whether underlying table changes should be
reflected in the view,
e.g. should SELECT *
Hi!
Sorry for delay, I hadn't access to Internet.
> [3]
> Again, in g_int_decompress(), I couldn't figure out the functionality of
> below lines:
gist__int_ops use rangeset compression technique, read about in "THE RD-TREE: AN
INDEX STRUCTURE FOR SETS", Joseph M. Hellerstein,
http://www.sai.m
Am Mittwoch, 10. Mai 2006 11:44 schrieb Bernd Helmle:
> --On Mittwoch, Mai 10, 2006 10:14:22 +0200 Mario Weilguni
>
> <[EMAIL PROTECTED]> wrote:
> > No, I want that there is a setting or GUC that controls whether an error
> > or a warning is raised when "begin" is executed within a transaction. I
Am Mittwoch, 10. Mai 2006 10:59 schrieb Peter Eisentraut:
> Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
> > You want to make a GUC that makes:
> >
> > BEGIN;
> > BEGIN;
> >
> > Leave you with an aborted transaction? That seems like a singularly
> > useless feature...
>
> If a co
--On Mittwoch, Mai 10, 2006 10:14:22 +0200 Mario Weilguni
<[EMAIL PROTECTED]> wrote:
No, I want that there is a setting or GUC that controls whether an error
or a warning is raised when "begin" is executed within a transaction. I
know of several php database wrappers that will be seriously
Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
> You want to make a GUC that makes:
>
> BEGIN;
> BEGIN;
>
> Leave you with an aborted transaction? That seems like a singularly
> useless feature...
If a command doesn't do what it is supposed to do, then it should be an error.
Tha
Am Mittwoch, 10. Mai 2006 09:41 schrieb Mario Weilguni:
> Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
> > Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > > Yesterday I helped a guy on irc with a locking problem, he thought
> > > that locking in postgresql was broken. It turned out that he ha
On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
> > > Could we make BEGIN fail when we already are in a transaction?
> >
> > We could, but it'd probably break about as many apps as it fixed.
> > I wonder whether php shouldn't be complaining about this, instead
> > --- doesn't php ha
Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > Yesterday I helped a guy on irc with a locking problem, he thought
> > that locking in postgresql was broken. It turned out that he had a PHP
> > function that he called inside his transaction and t
Tom Lane wrote:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
>> Could we make BEGIN fail when we already are in a transaction?
>
> We could, but it'd probably break about as many apps as it fixed.
I'd say that a program that issues BEGIN inside a transaction is
already broken, if only by design
51 matches
Mail list logo
