Kevin Grittner wrote:
I still haven't actually read the paper so I should probably bow out
from the conversation until I do. I was apparently already under
one misapprehension as Laurenz just claimed the paper does not show
how to prevent phantoms (phantom reads I assume?). Perhaps it's
On Friday 08 May 2009 22:03:56 Tom Lane wrote:
I hesitate though to suggest that we think about porting
ourselves to NSS --- I'm not sure that there would be benefits to us
within the context of Postgres alone.
That could be attractive if we ripped out the OpenSSL code at the same time,
as
Peter Eisentraut wrote:
On Friday 08 May 2009 22:03:56 Tom Lane wrote:
I hesitate though to suggest that we think about porting
ourselves to NSS --- I'm not sure that there would be benefits to us
within the context of Postgres alone.
That could be attractive if we ripped out the OpenSSL
Andrew Gierth wrote:
Magnus asked me for this, when the subject came up on IRC. This is a
longstanding ignored issue, for example
http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
Seth Robertson wrote:
In message 14727.1241816...@sss.pgh.pa.us, Tom Lane writes:
It is of course possible to support both at the same time (at
compile-time, if nowhere else).
Yes, I suppose we'd not wish to just drop openssl completely.
I wonder how much code
hello everybody,
i would like to propose an extension to our SELECT FOR UPDATE mechanism.
especially in web applications it can be extremely useful to have the
chance to terminate a lock after a given timeframe.
i would like to add this functionality to PostgreSQL 8.5.
the oracle syntax is
Can't you to this today with statement_timeout? Surely you do want to
rollback the whole transaction or at least the subtransaction if you
have error handling.
--
Greg
On 11 May 2009, at 10:26, Hans-Juergen Schoenig postg...@cybertec.at
wrote:
hello everybody,
i would like to propose
--On Mittwoch, Mai 06, 2009 19:04:21 -0400 Tom Lane t...@sss.pgh.pa.us
wrote:
So I'm now persuaded that a better textual representation for bytea
should indeed make things noticeably better here. It would be
useful though to cross-check this thought by profiling a case that
dumps a comparable
hello greg,
the thing with statement_timeout is a little bit of an issue.
you could do:
SET statement_timeout TO ...;
SELECT FOR UPDATE ...
SET statement_timeout TO default;
this practically means 3 commands.
the killer argument, however, is that the lock might very well happen
ways
2009/5/11 Hans-Juergen Schoenig postg...@cybertec.at
the thing with statement_timeout is a little bit of an issue.
you could do:
SET statement_timeout TO ...;
SELECT FOR UPDATE ...
SET statement_timeout TO default;
Why not extend the SET instruction to allow configuration parameters
--On 11. Mai 2009 06:38:44 -0300 Lucas Brito luca...@gmail.com wrote:
Why not extend the SET instruction to allow configuration parameters to
be set only in the duration of the transaction or the next n commands?
It's already there: see SET LOCAL.
--
Thanks
Bernd
--
Sent via
--
Greg
On 11 May 2009, at 11:18, Hans-Juergen Schoenig postg...@cybertec.at
wrote:
hello greg,
the thing with statement_timeout is a little bit of an issue.
you could do:
SET statement_timeout TO ...;
SELECT FOR UPDATE ...
SET statement_timeout TO default;
this practically
I tend to think there should be protocol level support for options
like this but that would require buy-in from the interface writers.
how would you do it?
if you support it on the protocol level, you still need a way to allow
the user to tell you how ...
i would see WAIT for DELETE,
Tom Lane wrote:
Erik Rijkers e...@xs4all.nl writes:
On Sun, May 10, 2009 02:05, Alvaro Herrera wrote:
I'm wondering that it could have forgotten to migrate the later table
segments ...
It seems al 'truncated' tables give
pg_relation_size(oid) = 1073741824
Looks like Alvaro nailed
We are looking for an experienced Postgresql DBA willing to travel and
provide short and tailored Postgresql training as well as develop an
interface in VB or VB.NET for data capture and query postgresql database.
The application shall be client server.
Immediate, 10 days assignment all costs
Albe Laurenz laurenz.a...@wien.gv.at wrote:
All the authors show with regard to predicate handling is
handwaving,
That is because predicate locking is a mature technology with many
known implementations. The best technique for any database product
will depend on that product, and their
On Mon, May 11, 2009 at 2:49 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Albe Laurenz laurenz.a...@wien.gv.at wrote:
All the authors show with regard to predicate handling is
handwaving,
That is because predicate locking is a mature technology with many
known implementations. The
Kevin Grittner wrote:
All the authors show with regard to predicate handling is
handwaving,
That is because predicate locking is a mature technology with many
known implementations. The best technique for any database product
will depend on that product, and their technique doesn't
Greg Stark st...@enterprisedb.com wrote:
I thought the big problem with providing true serializability was
the predicate locking. If it doesn't address that need then does
this get us any closer?
I thought the big problem was the perception that performance would
suffer and that the level
On Mon, May 11, 2009 at 3:11 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Stark st...@enterprisedb.com wrote:
I thought the big problem with providing true serializability was
the predicate locking. If it doesn't address that need then does
this get us any closer?
I thought
Albe Laurenz laurenz.a...@wien.gv.at wrote:
In my first reply I wondered if the presence of concurrent read
committed transactions would somehow affect the correctness of the
algorithm, as the authors don't mention that.
Yeah, I was concerned about that, too. In thinking it through I've
Magnus Hagander wrote:
Andrew Gierth wrote:
Magnus asked me for this, when the subject came up on IRC. This is a
longstanding ignored issue, for example
http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
Magnus Hagander wrote:
Another thought: if we were to make ourselves support multiple SSL
libraries (that has been suggested before - at that point, people wanted
GnuTLS), we could also add support for Windows SChannel, which I'm sure
some win32 people would certainly prefer - much easier to
Hans-Juergen Schoenig postg...@cybertec.at writes:
i would like to propose an extension to our SELECT FOR UPDATE mechanism.
especially in web applications it can be extremely useful to have the
chance to terminate a lock after a given timeframe.
I guess my immediate reactions to this are:
1.
Alvaro Herrera alvhe...@commandprompt.com writes:
Magnus Hagander wrote:
Applied, thanks!
Shouldn't this be backpatched?
It looks like a feature change to me ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Greg Stark st...@enterprisedb.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Greg Stark st...@enterprisedb.com wrote:
I thought the big problem with providing true serializability was
the predicate locking. If it doesn't address that need then does
this get us any closer?
I
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Magnus Hagander wrote:
Applied, thanks!
Shouldn't this be backpatched?
It looks like a feature change to me ...
Yup, I think so too. It changes the behavior if you have such a file.
//Magnus
--
Sent via pgsql-hackers
In message 4a07db89.2080...@hagander.net, Magnus Hagander writes:
Is NSS available on all the platforms that we are (and that has OpenSSL
today)?
NSS stopped publishing their supported platform list for NSS for some
strange reasons (older version have it). But I'd probably assume that
In message 20090511144317.gc8...@alvh.no-ip.org, Alvaro Herrera writes:
Magnus Hagander wrote:
Another thought: if we were to make ourselves support multiple SSL
libraries (that has been suggested before - at that point, people wanted
GnuTLS), we could also add support
There was just another complaint about something we've heard about
before, namely that dropping a child table doesn't interact nicely
with queries concurrently accessing the parent table:
http://archives.postgresql.org/pgsql-bugs/2009-05/msg00113.php
As I responded there, this isn't fixable by
On Monday 11 May 2009 11:02:17 Magnus Hagander wrote:
Another thought: if we were to make ourselves support multiple SSL
libraries (that has been suggested before - at that point, people wanted
GnuTLS), we could also add support for Windows SChannel, which I'm sure
some win32 people would
Peter Eisentraut wrote:
On Monday 11 May 2009 11:02:17 Magnus Hagander wrote:
Another thought: if we were to make ourselves support multiple SSL
libraries (that has been suggested before - at that point, people wanted
GnuTLS), we could also add support for Windows SChannel, which I'm sure
Boszormenyi Zoltan z...@cybertec.at writes:
Would the lock_timeout work for all to be acquired locks individually,
or all of them combined for the statement? The individual application
of the timeout for every locks individually wouldn't be too nice.
I think the way you're describing would be
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Would the lock_timeout work for all to be acquired locks individually,
or all of them combined for the statement? The individual application
of the timeout for every locks individually wouldn't be too nice.
I think the way
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I think the way you're describing would be both harder to implement
and full of its own strange traps.
Why?
Well, for one thing: if I roll back a subtransaction, should the lock
wait time it used now no longer count against the
Hi,
Tom Lane írta:
Hans-Juergen Schoenig postg...@cybertec.at writes:
i would like to propose an extension to our SELECT FOR UPDATE mechanism.
especially in web applications it can be extremely useful to have the
chance to terminate a lock after a given timeframe.
I guess my
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
I think the way you're describing would be both harder to implement
and full of its own strange traps.
Why?
Well, for one thing: if I roll back a subtransaction, should the lock
wait time
2009/5/11 Boszormenyi Zoltan z...@cybertec.at:
Does statement_timeout counts against subtransactions as well? No.
If a statement finishes before statement_timeout, does it also decrease
the possible runtime for the next statement? No. I was talking about
locks acquired during one statement.
hello tom ...
the reason for SELECT FOR UPDATE is very simple:
this is the typical lock obtained by basically every business
application if written properly (updating a product, whatever).
the problem with NOWAIT basically is that if a small transaction holds
a a lock for a subsecond, you
Greg Stark írta:
2009/5/11 Boszormenyi Zoltan z...@cybertec.at:
Does statement_timeout counts against subtransactions as well? No.
If a statement finishes before statement_timeout, does it also decrease
the possible runtime for the next statement? No. I was talking about
locks acquired
2009/5/11 Hans-Jürgen Schönig postg...@cybertec.at:
i agree that a GUC is definitely an option.
however, i would say that adding an extension to SELECT FOR UPDATE, UPDATE
and DELETE would make more sense form a usability point of view (just my
0.02 cents).
I kinda agree with this. I believe
But more generally, what you are proposing seems largely duplicative
with statement_timeout. The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent. Hans
already argued upthread why he wants
Josh Berkus írta:
But more generally, what you are proposing seems largely duplicative
with statement_timeout. The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent. Hans
already argued
Robert Haas robertmh...@gmail.com writes:
I kinda agree with this. I believe Tom was arguing upthread that any
change of this short should touch all of the places where NOWAIT is
accepted now, and I agree with that. But having to issue SET as a
separate statement and then maybe do another
Khee Chin escribió:
Updated with an additional line in the comments for get_indexdef
* if colno == -999, we only want the name of the variables that
make up the index
I don't think this hack is going to fly. I suggest you need to find
some other way to implement this.
--
Alvaro
Tom,
My point is that I don't believe the scenario where you say that you
know exactly how long each different statement in your application
should wait and they should all be different. What I do find credible
is that you want to set a policy for all the lock timeouts. Now
think about what
Alvaro Herrera alvhe...@commandprompt.com writes:
Khee Chin escribió:
Updated with an additional line in the comments for get_indexdef
* if colno == -999, we only want the name of the variables that
make up the index
I don't think this hack is going to fly.
Yeah ... if it were local
On Tue, May 12, 2009 at 12:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Index public.fooi
Column | Type | Definition
-+-+
f1 | integer | f1
pg_expression_2 | integer | (f2+f3)
Is there any reason to expose pg_expression_2
Josh Berkus j...@agliodbs.com writes:
I can see Zoltan's argument: for web applications, it's important to
keep the *total* wait time under 50 seconds for most users (default
browser timeout for most is 60 seconds).
And why is that only about lock wait time and not about total execution
Greg Stark st...@enterprisedb.com writes:
On Tue, May 12, 2009 at 12:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Index public.fooi
Column | Type | Definition
-+-+
f1 | integer | f1
pg_expression_2 | integer | (f2+f3)
Is
On 5/11/09 4:25 PM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
I can see Zoltan's argument: for web applications, it's important to
keep the *total* wait time under 50 seconds for most users (default
browser timeout for most is 60 seconds).
And why is that only about lock wait time
I wrote:
it seems that there is a reasonably simple solution: we could make
find_inheritance_children() and find_all_inheritors() acquire lock
on each child table as they scan pg_inherits, and do try_relation_open()
or equivalent to see if the child still exists. If not, assume the
table
2009/5/11 Pavel Stehule pavel.steh...@gmail.com:
I am thinking so Grouping Sets based on CTE should be more commitable
code. It doesn't mean so your ideas are wrong, but these
optimalization should to work on CTE too.
select * from table group by rollup(a,b,c)
have to have generate same
On Tue, May 12, 2009 at 12:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Index public.fooi
Column | Type | Definition
-+-+
f1 | integer | f1
pg_expression_2 | integer | (f2+f3)
Hi,
I'd agree that the mucking around with
Hi,
FORCE QUOTE option of COPY WITH CSV requires an explicit column list,
but '*' (all columns) would be also useful for typical usages.
I searched the ML archive and found one request before:
| COPY TO with FORCE QUOTE *
| http://archives.postgresql.org/pgsql-sql/2008-08/msg00084.php
The
My sincere apologies for flooding your mailboxes once again, as the
patch attached in the previous post was incorrect. Also, I had failed
to show test-cases of \d index in both 8.4 and 8.3 servers.
Attached are the test cases for psql connecting to 8.4 and 8.3.
psql (8.4beta1)
Type help for
56 matches
Mail list logo
