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 the function did BEGIN
and COMMIT. Since BEGIN inside a
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 have its own ideas about controlling where the
transaction commit points are?
All PHP does is when the connection is returned to the pool, if it is
Tom Lane wrote:
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 the function did BEGIN
and COMMIT. Since BEGIN
On 5/10/06, Tom Lane [EMAIL PROTECTED] wrote:
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 the function
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.
I
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 the
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 have its own
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 had a PHP
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.
That
--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: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 command doesn't do
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
know of
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,
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 *
--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.
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
$$
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 ...
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
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
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
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 function
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
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
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
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 at
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
quote
Lastly, StartTrans/CompleteTrans is nestable, and only the outermost
block is executed. In
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
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,
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/decrement a
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 20
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
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
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...
LOL, yeah, I should have, sorry.
See tuplestore_begin_heap in backend/utils/sort/tuplestore.c
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
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
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, instead
---
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
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
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 aborted transaction?
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
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 existing
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 processes
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 processes
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 rather
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
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,
it would be
Martijn van Oosterhout kleptog@svana.org 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
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.
It
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
On 5/10/06, Tom Lane [EMAIL PROTECTED] wrote:
Martijn van Oosterhout kleptog@svana.org 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
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 we'd
Tom Lane skrev:
The SQL99 spec does say (in describing START TRANSACTION,
which is the standard spelling of BEGIN)
1) If a start transaction statement statement is executed when an
SQL-transaction is currently active, then an exception condition
is raised:
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
54 matches
Mail list logo
