through the
thesis for an hour or so.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18.12.09 16:42 , Florian Weimer wrote:
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbiernicolas.barb...@gmail.com wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due
of the SIREAD-lock
approach has nothing to do with the SIREAD locks per se. They are
introduced by the approximate way in which circles contained in the
transaction's dependency graph are detected (the inConflict, outConflict
business).
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list
a configurable shell script in that
case, for example. You could then use that to rsync the data directory
from the server (after a pg_start_backup() of course).
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
. Anway, once the
slave is down, it won't come up until you manage to get the master up
and running again. And this limitation is pretty surprising, since one
would assume that if the slave survives a *crash* of the master, it'd
certainly survive a simple *shutdown*.
best regards,
Florian Pflug
On 22.12.09 13:21 , Simon Riggs wrote:
On Tue, 2009-12-22 at 12:32 +0100, Florian Pflug wrote:
Image a reporting database where all transactions but a few daily
bulk imports are read-only. To spread the load, you do your bulk
loads on the master, but run the reporting queries against a
read
On 22.12.09 16:45 , Simon Riggs wrote:
On Tue, 2009-12-22 at 16:32 +0100, Florian Pflug wrote:
But you are of course free to work on whatever you feel like, and
probably need to satisfy your client's needs first.
Alluding to me as whimsical or mercenary isn't likely to change my
mind.
Simon
zero responses though...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
machinery might make it
possible to invalidate those plans should the CAST definitions change,
but I haven't really looked into that yet.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
no need to actually execute 2^31 transactions to trigger this
bug (if it actually exists), it'd be sufficient to increment the xid counter by
more than one each time a xid is assigned, no?
Or would that trip snapshot creation on the standby?
best regards,
Florian Pflug
smime.p7s
Description: S/MIME
,
Florian Pflug
smime.p7s
Description: S/MIME cryptographic signature
. This, together with the backup label of the last backup should be
enough to compute the list of changed files I think.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
own solution is the ability to use LSNs
instead of timestamps I'd say.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in place the
rest amounts to the removal of ONLY from the constraint check queries plus some
code to propagate constraint triggers to child tables.
best regards,
Florian Pflug
smime.p7s
Description: S/MIME cryptographic signature
backends as needed, no?
That would allow people to experiment with different cancellation policies, and
maybe shed some light on what the useful policies are in practice.
best regards,
Florian Pflug
smime.p7s
Description: S/MIME cryptographic signature
On May 6, 2010, at 12:48 , Simon Riggs wrote:
On Thu, 2010-05-06 at 11:36 +0200, Florian Pflug wrote:
If there was an additional SQL-callable function that returned the backends
the recovery process is currently waiting for, plus one that reported that
last timestamp seen in the WAL, than
On May 6, 2010, at 16:38 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
What lies at the heart of this problem is the lack of multi-table
indices and hence multi-table unique constraints in postgres. AFAIK
with those in place the rest amounts to the removal of ONLY from the
constraint
The only remaining option is to continue applying WAL until you reach a point
where no locks are held, then pause. But from a user's POV that is nearly
indistinguishable from simply setting hot_standby_conflict_winner to in the
first place I think.
best regards,
Florian Pflug
smime.p7s
On May 9, 2010, at 21:04 , Simon Riggs wrote:
On Sun, 2010-05-09 at 16:10 +0200, Florian Pflug wrote:
Adding pause/resume seems to introduce some non-trivial locking
problems, though. How would you handle a pause request if the recovery
process currently held a lock?
(We are only talking
On May 9, 2010, at 22:01 , Robert Haas wrote:
On Sun, May 9, 2010 at 3:09 PM, Dimitri Fontaine dfonta...@hi-media.com
wrote:
Florian Pflug f...@phlo.org writes:
The only remaining option is to continue applying WAL until you reach
a point where no locks are held, then pause. But from
be correct.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that the system
reacts in a sane way.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an example that proves it necessary?
best regards,
Florian Pflug
Here are the table definitions and trigger functions I used:
CREATE TABLE parent (parent_id SERIAL NOT NULL PRIMARY KEY);
CREATE TABLE child (child_id SERIAL NOT NULL PRIMARY KEY, parent_id INTEGER NOT
NULL);
CREATE FUNCTION
On May 11, 2010, at 17:04 , Robert Haas wrote:
2010/5/11 Florian Pflug f...@phlo.org:
C1: BEGIN
C1: INSERT INTO child (parent_id) VALUES (0)
C2: BEGIN
C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
C2: SELECT TRUE -- Take snapshot *before* C1 commits
C1: COMMIT
C2: DELETE FROM parent
behave that way would be a good idea. But if my assertion is in
fact true it would allow for robust user-level referential constraints by
either modifying SHARE-lock behavior or adding a new row-lock type.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
. For beta1, however, no branch
seems to exist, and hence there is no trace of it on the GIT mirror.
Why is there a branch plus a tag for alphas, but only a tag for betas? I'd have
assumed that both would just be tags, but obviously I'm missing something
there...
best regards,
Florian Pflug
--
Sent
git.postgresql.org? I
might give it a shot.
I can't promise anything, though - my ruby-fu is OK, but my cvs-fu is badly
lacking...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12.05.2010, at 22:22, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
Yeah, but CVS has tags for the alphas and betas. Those are missing
from the GIT mirror as the CVS-to-GIT converter apparently ignores
tags completely :-(. Since there are no branches
in.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 13, 2010, at 23:39 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
All in all, I believe that SHARE and UPDATE row-level locks should be
changed to cause concurrent UPDATEs to fail with a serialization
error.
I don't see an argument for doing that for FOR SHARE locks
On May 13, 2010, at 23:51 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org wrote:
All in all, I believe that SHARE and UPDATE row-level locks should
be changed to cause concurrent UPDATEs to fail with a
serialization error. I can come up with a patch that does that,
but I wanted to get
On May 14, 2010, at 2:37 , Greg Stark wrote:
On Thu, May 13, 2010 at 10:25 PM, Florian Pflug f...@phlo.org wrote:
C1: BEGIN
C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
C2: BEGIN
C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
C2: SELECT * FROM t -- Take snapshot before C1 commits
C1
versions (everything = 7.0 I think) that use UTF16 on-wire, where those
characters can be transmitted just fine.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
that useful with serializable transactions...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 14, 2010, at 15:54 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org wrote:
On May 14, 2010, at 12:56 , Kevin Grittner wrote:
unless your patch completely removes support for snapshot
isolation (what is current called SERIALIZABLE)
Both SERIALIZABLE and REPEATABLE READ currently
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
All in all, I believe that SHARE and UPDATE row-level locks should be
changed to cause concurrent UPDATEs to fail with a serialization
error
On May 14, 2010, at 16:32 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org wrote:
I must admit that I wasn't able to find an explicit reference to
Oracle's behavior in their docs, so I had to resort to
experiments. They do have examples showing how to do FK-like
constraints
On May 17, 2010, at 3:30 , Robert Haas wrote:
On Sun, May 16, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
All in all, I believe
advantage either.
So +1 for flipping both with the release of 9.1, and warning people well ahead
of time. Maybe there could even be a warning in the 9.0 release notes about the
scheduled change?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On May 19, 2010, at 2:15 , Florian Pflug wrote:
On May 17, 2010, at 3:30 , Robert Haas wrote:
On Sun, May 16, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f
On May 21, 2010, at 4:20 , Florian Pflug wrote:
On May 19, 2010, at 2:15 , Florian Pflug wrote:
On May 17, 2010, at 3:30 , Robert Haas wrote:
On Sun, May 16, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom
with ON
SELECT rules from views seem rather AI-complete. The same holds for
materialized views vs. tables and materialized views vs. views.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
for the *absence* of features, which seems hard...
I suggest the following definition of trusted PL.
While potentially preventing excruciating pain, saving tons of sweat and
allowing code reuse, actually adds nothing in terms of features over pl/pgsql.
best regards,
Florian Pflug
--
Sent via pgsql
On May 21, 2010, at 23:57 , Josh Berkus wrote:
From a discussion at dinner at pgcon, I wanted to send this to the list for
people to poke holes in it:
Problem: currently, if your database has a large amount of cold data, such
as 350GB of 3-year-old sales transactions, in 8.4 vacuum no
be renamed to RESET ALL STATE.
greetings, Florian Pflug
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
be impossible to archive without some
really bad hacks. So maybe just finding a way to disable ident auth for
connections made via dblink is sufficient.
greetings, Florian Pflug
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
Stephen Frost wrote:
* Florian Pflug ([EMAIL PROTECTED]) wrote:
Gregory Stark wrote:
All that really has to happen is that dblink should by default not be
callable
by any user other than Postgres. DBAs should be required to manually run
GRANT EXECUTE ON dblink_connect(text) TO public
' on the shell,
you see my/test in the Finder.
Thats another argument for staying away from : in filenames.
greetings, Florian Pflug
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
to use the binary format,
despite it's benefits for moving around large amounts of data.
regards, Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for wanting to store the original statement in the first
place, no? I have no idea how hard I'd be to carry that information from
the lexer into the parser, and then into whatever representation we use
for storing a view, though...
regards, Florian Pflug
--
Sent via pgsql-hackers mailing list
to do
currently. Still, storing the original SQL is not the right thing to do
IMHO - the only viable option I can see is trying to store plain-text
nodes with the parse tree which get reinserted when the parse tree is
converted back into a query.
regards,
Florian Pflug
--
Sent via pgsql-hackers
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote:
It's my understanding that the philosophy of the PGDG in the past has
been to avoid putting any kind of hints into the system, focusing
rather an improving the planning of queries.
shows that we ought to support
ALTER TYPE for composite types ;-)
Is there anything fundamental standing in the way of that, or is it just
that nobody yet cared enough about this?
regrads, Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
could keep the snapshot around for txid,
but still update our published xmin - which seems to be the main reason we care
about getting rid of old snapshots at all.
greetings, Florian Pflug
---(end of broadcast)---
TIP 7: You can help support
Tom Lane wrote:
Florian Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think txid_current_snapshot should read ActiveSnapshot. If the user
wants to get a beginning-of-xact rather than beginning-of-statement
snapshot from it, he should be required to call it in a serializable
transaction
exec diff ... fails,
because diff seems to exit with a nonzero exitcode if the files differ, and git
diff aborts in that case...
regards, Florian Pflug
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
-lastmerged
git tag -f pgsql-upstream-git-lastmerged pgsql-upstream-git/master \
|| exit 1
--
regards, Florian Pflug
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
to find changesets on the GIT mirror
which are not in my local tree.
Is there any chance that these mirrors can be updated in a way that
doesn't change the past?
regards, Florian Pflug
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
to the freeze_age?
regards, Florian Pflug
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
accessible to ROLLBACK TO SAVEPOINT and
RELEASE SAVEPOINT implies that you *will* walk backwards through all the
savepoints named a if you repeatedly issue ROLLBACK TO SAVEPOINT a, no? If
that is not how it actually works, then this whole paragraph is wrong, I'd say.
best regards,
Florian Pflug
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
On 25/05/10 13:03, Florian Pflug wrote:
On May 25, 2010, at 6:08 , Sam Vilain wrote:
http://www.postgresql.org/docs/8.4/static/sql-savepoint.html
Lead us to believe that if you roll back to the same savepoint name
twice in a row
On May 25, 2010, at 3:21 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
The subtle point here is whether you consider the view from the outside
(in the sense of what a read-only transaction started at an arbitrary time
can or cannot observe), or from the inside (what updating
that conflicts are always
between a reader and a writer or between two writers. So how can a read-only
transaction have incoming and outgoing edges?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On May 25, 2010, at 20:48 , Dan Ports wrote:
On Tue, May 25, 2010 at 08:35:44PM +0200, Florian Pflug wrote:
Hm, so in fact SSI sometimes allows the database to be inconsistent, but
only as long as nobody tries to observe it?
Yes. Note that even while it's in an inconsistent state, you can
to be effective than so will this
probably, so maybe my fear is unjustified.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 27, 2010, at 0:58 , Heikki Linnakangas wrote:
On 26/05/10 02:00, Sam Vilain wrote:
Florian Pflug wrote:
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as the doc says, but rolling back
of migration...
For text = text and text[] = text[] I'd propose '||' as an alternative,
since they both combine their arguments, kind of a like a concatenation.
For hstore = text[] I'd suggest '' since the result's set of keys is the
intersection of both argument's key-sets.
best regards,
Florian
with
larger nestlevel shall be invoked earlier than others.
Wouldn't the information leak go away if you stuck OFFSET 0 at the end of the
view? IIRC, that is the semi-offical way to create barriers for subquery
flattening and such.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing
recovery target
for the PITR case.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 3, 2010, at 3:31 , Robert Haas wrote:
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On Jun 3, 2010, at 0:58 , Robert Haas wrote:
But maybe the message isn't right the first time either. After all
the point of having a write-ahead log in the first place is that we
either need to teach your
restore_command to fetch them from there. Note that you cannot recover in
reverse. To recover up to a certain point in time you always need to start
from a base backup taken *before* that time.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql
is that that hint is pretty alarming.
Maybe we should just get rid of the hint.
FYI, Robert Haas suggested the same in the thread that lead to this patch being
applied. The arguments against doing that is that a real crash during recovery
*is* something to be quite alarmed about.
best regards,
Florian
work.
You might want to re-ead the section on the recovery process in the PTITR
documentation, at
http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html#BACKUP-PITR-RECOVERY
If you have further questions, please take this discussion to pgsql-general.
best regards,
Florian Pflug
On Jun 3, 2010, at 5:25 , Robert Haas wrote:
On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug f...@phlo.org wrote:
Oh. Well, if that's the case, then I guess I lean toward applying the
patch as-is. Then there's no need for the caveat and without manual
intervention.
That still leaves
.
pg_upgrade for example shouldn't care.
RFC3385 compares different checksumming methods for use in iSCSI, and CRC32c
(which uses the same polynomial as the SSE4.2 instruction) wins. Here's
a link: http://www.faqs.org/rfcs/rfc3385.html
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list
, not the (much slower) generic implementation based
on semaphores.
BTW, last time I tried compiling with clang basically worked on OSX, despite
triggering a helluva lot of warnings.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
: walsender does *not* wait
for an fsync to occur.
Hm, but then Robert's failure case is real, and streaming replication might
break due to an OS-level crash of the master. Or am I missing something?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
to retrieve it to be on disk by the time the system call
returns.
If that is true, I believe we should default to open_sync, not fdatasync if
open_datasync isn't available, at least on linux.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
if set of keys subset of
array)
I suggest
hstore text[]
as a replacement.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
finds to the Command struct, elapsed and cnt, which
accumulate the total time spent on each statement and the number of times it
was executed. printResults essentially prings elapsed/cnt for each statement,
followed by the statement itself.
Patch is attached.
best regards,
Florian Pflug
to the latest LSN
found on any one of the nodes.
Option (b) requires some additional thought, though. Controlled removal of
slave nodes and concurrent crashes of more than one node are the most difficult
areas to handle gracefully, it seems.
best regards,
Florian Pflug
--
Sent via pgsql
() with zero as the second
argument.
The internal representation wouldn't change, it's just the type's OID in the
catalog that'd be different.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
. Pick the best-matching candidate and start by copying what it
does.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 14, 2010, at 2:22 , Greg Smith wrote:
Florian Pflug wrote:
To be able to asses the performance characteristics of the different
wal-related options, I patched pgbench to show the average latency of each
individual statement. The idea is to be able to compare the latency
.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an operation on hstores.
How about turning it into a function
hstore hstore(hstore, text[])
instead?
Could also be hstore_restrict if people think naming it just hstore is
ambiguous.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
by
the receiving end, the TCP stack can (and does) detect a broken connection.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 20, 2010, at 7:18 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Jun 19, 2010, at 21:13 , Tom Lane wrote:
This is nonsense --- the slave's kernel *will* eventually notice that
the TCP connection is dead, and tell walreceiver so. I don't doubt
that the standard TCP timeout
connections.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
always require manual intervention and cause all sorts of performance
and disk-space issues, while the latter won't even be an issue for well-written
clients who just reconnect and retry.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
are. Since we've trusted keepalives to prevent the former
for 10 years now, I think we can risk trusting keepalives to prevent the latter
too.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
to tcp_client_keepalives,
tcp_client_keepalives_idle, tcp_client_keepalives_count and
tcp_client_keepalives_interval? Or do we expect people who fiddle with those
parameters to understand the subtle difference?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
, like in the following shell
snippet.
COMMANDS=DO (arg int) $$ ... $$
(for a in arg1, arg2, arg3, arg4; do
echo $COMMANDS USING $a;
done) | psql
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Jul4, 2010, at 11:59 , Pavel Stehule wrote:
2010/7/4 Florian Pflug f...@phlo.org:
On Jul4, 2010, at 08:41 , Pavel Stehule wrote:
I enhanced DO statement syntax to allowing a parameters. Syntax is
relative simple:
do ([varname] vartype := value, ...) $$ ... $$
I think it'd be more
try to avoid that by encoding value=$VALUE in double
quotes, but I doubt that it's 100% safe even then.
The point is that interpolating the value into the command is always risky,
independent from whether it's a shell command or an sql command.
best regards,
Florian Pflug
--
Sent via pgsql
not within the next few days though,
since I'm unfortunately quite busy at the moment, trying to finally complete my
master's thesis.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
skipping logic, which my
patch moves to process_command.
Updated patch is attached.
Thanks for your extensive review
best regards,
Florian Pflug
pgbench_statementlatency.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
on
git://github.com/fgp/postgres.git and also attached a patch.
best regards,
Florian Pflug
serializable_row_locks.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
1 - 100 of 757 matches
Mail list logo
