thin that ring buffer.
Where as currently, the snapshot's xip array resides in process-local
memory. (Granted, often enough, the proc array also is a point of
contention.)
> At this point I don't see any major issues with this approach. If the
> ensuing discussion doesn&#x
Ants,
the more I think about this, the more I start to like it.
On 06/07/2013 02:50 PM, Ants Aasma wrote:
> On Fri, Jun 7, 2013 at 2:59 PM, Markus Wanner wrote:
>> Agreed. Postgres-R uses a CommitOrderId, which is very similar in
>> concept, for example.
>
> Do you think
x27;s a bit longer, but sounds more like a full sentence, no?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
covers any combination of a username/password
> being wrong and obviously password expired covers the other.
Works for me. Considering the password to be the thing that expires
(rather than the account) is probably more accurate as well.
Regards
Markus Wanner
--
Sent via pgsql-hackers mail
ht be hard to figure out which
> row in pg_hba.conf was the one that PostgreSQL glommed onto to use for
> authentication.
As argued before, that should go into the logs for diagnosis by the
sysadmin, but should not be revealed to an attacker.
Regards
Markus Wanner
--
Sent via pgsql-hacker
don't we also have to include "auth server unreachable" as a
possible cause for authentication failure for methods that use an
external server?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n of the new
> interface. With this patch, you can CREATE EXTENSION worker_spi and
> then call worker_spi_launch(int4) to launch a new background worker,
> or combine it with generate_series() to launch a bunch at once. Then
> you can kill them off with pg_terminate_backend() and start some new
mple room for paranoia about postmaster interaction
> with shared memory, but all it's doing is setting a flag, which is no
> different from what CheckPostmasterSignal() already does.
Sounds good to me.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
imization is one. (It's more like giving the system
a hint. And we all dislike hints, don't we? *ducks*)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on large portions of a relation, IMO.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
urpose of parallel query execution,
yes. But I see no reason for that not to work equally well for
unpartitioned tables.
Disk I/O is already pretty well optimized and parallelized, I think.
Trying to parallelize a seq scan on the Postgres side is likely to yield
far inferior performance.
Regards
Mark
nor quality work with a "prize". Maybe a price
for the best reviewer per CF? Maybe even based on votes from the general
public on who's been the best, so reviews gain attention that way...
"Click here to vote for my review." ... Maybe a crazy idea.
Regards
Markus Wanner
o a normal, fully
sequential scan and only fan out after the scan and distribute the
incoming pages (or even tuples) to the multiple cores to process.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
ets pretty close,
I think. Though, I don't consider this to be related to how the tuples
of the relation are laid out on disk.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
A single index
performs better in that case, because it has lower overhead.
I take your point that in case you *can* define a hot partition and
apply partitioning, the hot(test) index(es) are more likely to be cached
and thus require less disk I/O.
Regards
Markus Wanner
--
Sent via pgs
don't know the
total amount of work or the size of each piece in advance, it gets a bit
harder. Choosing chunks that turn out to be too big certainly hurts.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
e.
I didn't look too deep into the code, but it seems Jaime and Hitoshi
raised some valid points.
Assorted very minor nit-picks:
In catalog/objectaddress.c, get_object_address_unqualified(): the case
OBJECT_TABLESPACE is being moved down. That looks like an like an
unintended change. Please rev
ind shift for how binary extensions work.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/05/2013 09:05 PM, Markus Wanner wrote:
> The patch has already
> been marked as 'returned with feedback', and I can support that
> resolution (for this CF).
Oops.. I just realize it's only set to "waiting on author", now. I guess
I confused the two states.
h. ]
> It's just something I forgot to cleanup when completing the feature set.
> Cleaned up in my git branch.
Great!
>> src/backend/commands/event_trigger.c, definition of
>> event_trigger_support: several unnecessary whitespaces added. These make
>> it hard(er) than
t;templates", those should be applicable to all databases, no?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/07/2013 02:55 PM, Markus Wanner wrote:
> If you want to just upload extensions to a database via libpq..
Let's rephrase this in a (hopefully) more constructive way: I get the
impression you are trying to satisfy many different needs. Way more that
you need to scratch your own itch
Hello Dimitri,
On 07/07/2013 09:51 PM, Dimitri Fontaine wrote:
> Markus Wanner writes:
>> Oh, I just realize that pg_extension_{template,control,uptmpl} are not
>> SHARED catalogs, but you need to install the template per-database and
>> then need to enable it - per-database
s why
"template" is a misnomer (with the proposed implementation). "Extension"
is not.
(I still think "template" would be a good mental model. See my other
thread...
http://archives.postgresql.org/message-id/51d72c1d.7010...@bluegap.ch)
Regards
Markus Wanner
--
Sent
te
> the extensions your dump depends on in that new database, now pg_restore
> your backup manually filtering away the extensions' objects or ignoring
> the errors when pg_restore tries to duplicate functions you already
> installed in the previous step. No fun.
Definitel
Hello Dimitri,
On 07/08/2013 11:49 AM, Dimitri Fontaine wrote:
> Please find attached to this mail version 9 of the Extension Templates
> patch with fixes for the review up to now.
Thanks, cool.
> Markus Wanner writes:
>>> I still think that we shouldn't allow cre
On 07/08/2013 08:31 PM, ivan babrou wrote:
> Seriously, I don't get why running 150 poolers is easier.
Did you consider running pgbouncer on the database servers?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
And if you're setting timeouts that low, you probably know what you're
doing (or at least care about latency a lot). Or is gettimeofday() still
considerably slower on certain architectures or in certain scenarios?
Where's the complexity?
Regards
Markus Wanner
--
Sent via pgsql-hackers
usec is
unsigned. (And the cited commit above indicates there are such platforms.)
On 07/09/2013 02:25 PM, ivan babrou wrote:
> There's no complexity here :)
Not so fast, cowboy... :-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
te model).
Another thing that surprised me is the inability to have an upgrade
script *and* a full version (for the same extension target version).
Even if that's intended behavior, the error message could be improved:
> db1=# CREATE TEMPLATE FOR EXTENSION foo VERSION '0.0' AS
Salut Dimitri,
On 07/09/2013 12:40 PM, Dimitri Fontaine wrote:
> Markus Wanner writes:
>> Or how do you think would pg_restore fail, if you followed the mental
>> model of the template?
>
> # create template for extension foo version 'x' as '';
>
gs that live entirely
inside the database" do you have in mind.
> There would be value to inside-the-database package management, but it
> should be a separate concept.
Anything that's incompatible to extensions is not gonna fly. There are
too many of them available, already. We need
bly check the permissions on the extension directory and at least
emit a warning, if it's world-writable. Or refuse to create (or even
load) an extension, right away.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ave the power.
> Now, I don't think Markus proposal is a good idea on *other* grounds
> though... but that's for another email.
Separation of concerns, huh? Good thing, thanks :-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On 07/15/2013 12:19 PM, Andres Freund wrote:
> On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
>> Granted, the "internalization" of the DSO is somewhat critical to
>> implement. Running as a non-root user, Postgres has less power than that
>> and can certainly n
Robert,
On 07/15/2013 12:12 PM, Markus Wanner wrote:
> On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
>> There is a lot of
>> (well-founded, IMHO) resistance to the idea of letting users install C
>> code via an SQL connection.
>
> Nowhere d
quite so bad if we write the bits to a file first and
> then dynamically load the file. That way at least noexec or similar
> can provide protection. But it still seems like a pretty dangerous
> direction.
I agree now. Thanks for elaborating.
Regards
Markus Wanner
--
t on the server's, but only on the (libpq)
client's file-system. No threat to the server.
> Yes it's dangerous. It's also solving real world problems that I see no
> other way to solve apart from bypassing the need to ever load a DSO
> file, that is embedding a retargetable C compiler in the backend.
If the sysadmin wants to disallow arbitrary execution of native code to
postgres (the process), any kind of embedded compiler likely is equally
unwelcome.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Salut Dimitri,
On 07/20/2013 01:23 AM, Dimitri Fontaine wrote:
> Markus Wanner writes:
>>> - per-installation (not even per-cluster) DSO availability
>>>
>>> If you install PostGIS 1.5 on a system, then it's just impossible to
>>> bring a
y the case with a "security conscious sysadmin" - they very
> seldom want to install anything.
Exactly. That's why I'm favoring solutions that don't require any
extension and keep the guarantee of preventing arbitrary native code.
Regards
Markus Wanner
-
Dimitri,
On 07/22/2013 08:44 PM, Dimitri Fontaine wrote:
> That's the trade-off we currently need to make to be able to ship with
> the current security protections we're talking about.
Anything wrong with shipping postgis-1.5.so and postgis-2.0.so, as I we
for Debian?
> Ok, here's the full work
g and providing
examples.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ummary, I'd say that Postgres-R is an approach specifically
targeting and optimized for multi-master replication between Postgres
nodes, where as the proposed patches are kept more general.
I hope you found this to be an insightful and fair comparison.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Postgres
>> nodes, where as the proposed patches are kept more general.
>
> One major aim definitely was optionally be able to replicate into just
> about any target system, so yes, I certainly agree.
I'm glad I got that correct ;-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ary key without problems.
It's the xmin of the old tuple that Postgres-R needs to get the COID.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
KEY without breaking legacy
applications that rely on SELECT * not returning that primary key.
Are there other reasons to want tables without primary keys that I'm
missing?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hannu,
On 11/17/2012 03:40 PM, Hannu Krosing wrote:
> On 11/17/2012 03:00 PM, Markus Wanner wrote:
>> On 11/17/2012 02:30 PM, Hannu Krosing wrote:
>>> Is it possible to replicate UPDATEs and DELETEs without a primary key in
>>> PostgreSQL-R
>> No. There must be s
ter thesises befor me.
Care to elaborate a bit? Can (part of) that code be released under an
open license?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hing and the kitchen sink.)
# Tests
No additional automated tests are included - hard to see how that could
be tested automatically, given the lack of a proper test harness.
I hope this review provides useful input.
Regards
Markus Wanner
[1]: That was during commit fest 2010-09. Back then,
its log line upon request, i.e. show how to use SIGUSR1.
>
> KaiGai proposed that we remove auth_counter. I don't see why not; I
> mean, worker_spi is already doing most of what auth_counter is doing, so
> why not?
Agreed.
> However, as you say, maybe we need more codi
On 11/30/2012 11:09 AM, Dimitri Fontaine wrote:
> Markus Wanner writes:
>>> However, as you say, maybe we need more coding examples.
>>
>> Maybe a minimally usable extra daemon example? Showing how to avoid
>> common pitfalls? Use cases, anybody? :-)
>
libpq. But so can external processes. So that's
no benefit of running under the postmaster.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
us stuff separate (and
advice developers to do so as well, instead of offering them a foot
gun). So that our postmaster can do its job. And do it reliably, without
trying to be a general purpose start/stop daemon. There are better and
well established tools for that.
Regards
Markus Wanner
--
Sent
s long as things like pgbouncer, pgqd, etc.. keep to be available as
separate daemons, I'm happy, though.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ostmaster's duration is a strong
indication that it better not be a bgworker, I think.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
se duration wants to
> be tied with duration of postmaster, its author can consider to implement
> it as background worker.
I personally don't count that as a real need. There are better tools for
this job; while there clearly are dangers in (ab)using the postmaster to
do it.
Regar
out that guc.c obtains the
> count of workers before workers have actually registered. So this
> necessitates some reshuffling.
Okay, thanks.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
egards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;s a net loss in robustness of the autovac implementation.
Agreed.
That's only one aspect of it, though. From the other point of view, it
would be a proof of stability for the bgworker implementation if
autovacuum worked on top of it.
Regards
Markus Wanner
--
Sent via pgsql-hackers mail
t likely later this week,
> or early next week; I would like to commit this patch before that. When
> I'm back we can discuss other improvements. That will give us several
> weeks before the end of the 9.3 development period to get these in. Of
> course, other committers are we
On 12/03/2012 10:35 PM, Alvaro Herrera wrote:
> So here's version 8. This fixes a couple of bugs and most notably
> creates a separate PGPROC list for bgworkers, so that they don't
> interfere with client-connected backends.
Nice, thanks. I'll try to review this again, s
ess" operator could
then be implemented by simply comparing two value's send() outputs.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gt;
> postgres=# SELECT length(textsend(NULL));
> length
>
>
> (1 row)
>
> postgres=# SELECT length(textsend(NULL) || '\000'::bytea);
> length
>
>
> (1 row)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
cess it?
You have to ship it from the SAN to the node, so I definitely don't
think so, but see this as an argument against it. Each having a local
copy and only exchange locking information and transactional changes
sounds like much less traffic overall.
Regards
Markus Wanner
[1]: The Da
n.
So it seems most people are used to that hammer, no?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
from WAL, the
record is logged correctly:
LOG: REDO @ 0/16F3270; LSN 0/16F329C: prev 0/16F3234; xid 688; len 16:
Transaction - commit: 2012-10-11 09:31:17.790368-07; subxacts: 689
Attached is a possible fix.
Regards
Markus Wanner
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access
Tom,
On 10/11/2012 03:11 PM, Tom Lane wrote:
> The original design intention was that rm_desc should not attempt to
> print any such data, but obviously some folks didn't get the word.
FWIW: in case the source code contains comments explaining that
intention, I certainly missed them so far.
Rega
On 10/11/2012 04:06 PM, Tom Lane wrote:
> Yeah, if we decide to stick with the limitation, some documentation
> would be called for. I remember having run into this and having removed
> functionality from an rm_desc function rather than question the premise.
> But maybe the extra functionality is
eally need an API that allows
for implementations of options 1) and 2)?
What I'd appreciate more is a common implementation for option 3) with
an API to plug in different solutions to the underlying consensus problem.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hac
r benefit).
> which means its not going to be possible to provide
> such a thing initially without slowing it down to the point we don't
> actually get it at all.
Sorry, I don't quite understand what you are trying to say, here.
Overall, thanks for bringing this up. I'm g
buted database as a transparent equivalent of a
single-node system, I'd say the SQL standard applies to the entire
distributed system. From that point of view, I'd rather argue that any
"local-only" behavior violates the standard.
Regards
Markus Wanner
--
Sent via pgsql-h
and re-set an initial value, as a starting point for the
next bulk of numbers that nextval() will return.
currval() doesn't need to be changed or "hooked" at all, because it's a
read-only operation.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/29/2012 12:05 PM, Robert Haas wrote:
> OK, I'll stop babbling now...
Not perceived as babbling here. Thanks for that nice round-up of options
and ideas around the torn page problem.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
d you never know what
the committee is coming up with next.
Apart from that, I'd like something more descriptive that just
"checksums". Block checksums? Heap checksums? Data checksums?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ge (provided you haven't ever turned
checksumming on before). Maybe you want to save that step and still get
the additional safety for newly dirtied pages, right?
A use case worth supporting?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
ds to a prolonged migration and
with time, the remaining VACUUM step becomes less and less frightening.
Do you see any real foot-guns or other show-stoppers for permanently
allowing that in-between-state?
Or do we have other viable options that prolong the migration and thus
spread the load better
, I'd argue that
prolonging the migration to spread the load would allow even big shops
to go through this without much of an impact on performance.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
own to both
> have a valid checksum on it and have its checksum bits set, *then* any
> page that doesn't have both set bits and a matching checksum is garbage.
>From that point in time on, we'd theoretically better use that bit as an
additional checksum bit rather than requirin
cause that bitmap may well
become a bottleneck itself. Plus there's the problem of making sure
those pages are safe against corruptions, so you'd need to checksum the
checksum bitmap... doesn't sound like a nice solution to me.
This has certainly been discussed before.
Regards
Marku
abling)
state, where pages with old data may or may not have a checksum, yet. So
I think it was an argument against staying in that state any longer than
necessary.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
outline an alternative that I think is viable and less intrusive.
> This is why I think any good solution to this problem needs to
> incorporate restartable conversion.
I fully agree to that.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t or rollback independently.
The timeout is nice, but is it really required? Isn't the normal query
cancellation infrastructure sufficient?
Hope that helps. Thanks for working on this issue.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
ndby accepts read-only queries and can be
configured to not loose data on master failure.
Do we want to call the feature "hot standby"? Is a read-only standby a
"standby" or a "slave"?
I think hot standby is pretty much the term, now.
Regards
Markus W
is a pragmatic and quick
solution for pg_dump and similar but we might want to have a more
general snapshot cloning procedure instead. Not having a delay for
other activities at all and not requiring superuser privileges would
be a big advantage over what I have proposed.
Agreed.
Regards
Mar
op of
dtester, I'm more than willing to support you with that. If you keep
your code in a git repository, I could even provide patches, in case I
need (or want) to change the dtester interface.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
tures per backend (plus
NUM_AUXILIARY_PROCS). What am I missing?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
://www.bluegap.ch/projects/dtester/
A git repository for dtester as well as some integration code for
testing Postgres based projects is available at:
http://git.postgres-r.org/
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
se that instead (especially if http
continues to pose problems).
Kind Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.2F_Parser_as_an_independent_module
Is this what you (or David) have in mind?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hould be named
TODISCUSS, IDEAS, or something. But the current file name implies consensus.
Wouldn't renaming solve that kind of misunderstanding? (..in the vain of
"address(ing) real problems in the simplest way"..)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgs
tion gets overridden immediately, in which case it
certainly doesn't matter. I don't know nor did I check whether or not it
can ever be NULL. So this might not be a real issue at all.
Regards
Markus Wanner
# InvalidBlockNumber is -1 (or rather 0x), while
# the currently used
nor its contract. The only correct exit points are the "return"s
> in the middle.
I came to the same conclusion, yes. Looks like the additional asserts in
the attached patch all hold true.
As another minor improvement, it doesn't seem necessary to repeatedly
set the rootBl
On 07/13/2012 11:33 AM, Markus Wanner wrote:
> As another minor improvement, it doesn't seem necessary to repeatedly
> set the rootBlkno.
Sorry, my mail program delivered an older version of the patch, which
didn't reflect that change. Here's what I intended to send.
R
Hi,
On 09/06/2010 06:27 PM, Heikki Linnakangas wrote:
Here's an updated patch, with all the issues reported this far fixed,
except for that naming issue, and Fujii's suggestion to use poll()
instead of select() where available. I've also polished it quite a bit,
improving comments etc. Magnus, c
On 09/06/2010 08:46 PM, Tom Lane wrote:
Well, it's not defined in the Single Unix Spec, which is our customary
reference for portability.
FWIW, I bet the self-pipe trick isn't mentioned there, either... any
good precedence that it actually works as expected on all of the target
platforms? Exi
a client
that can't tell if its transaction committed or not.
So why do we care what to do first internally? Ideally, these two tasks
should happen concurrently, IMO.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 09/07/2010 09:06 AM, Heikki Linnakangas wrote:
Setting a latch that's already set is very fast, so you want to keep it
set until the last moment. See the coding in walsender for example, it
goes to some lengths to avoid clearing the latch until it's very sure
there's no more work for it to do.
eing the max of the two operations. And that for normal operation.
While at best it saves an un-confirmed transaction in the failure case.
It might be harder to implement, yes.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
#x27;ll get there eventually.
Understood. Thanks.
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/07/2010 04:47 PM, Ron Mayer wrote:
In that situation, wouldn't it be possible that a different client
queried the slave and already saw the result of that transaction
which would later be rolled back?
Good point, yes.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (
1 - 100 of 500 matches
Mail list logo
