dimensions is actually worse than
the lower-bound problem. So *if* we ever remove support for arbitrary
lower bounds, we should also add distinct types for different dimensions.
That'd probably required some extension of the type system though...
best regards,
Florian Pflug
--
Sent via pgsql-
pe(myarray, NULL);
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
's peers, I think we'd use the inverse transfer
function to fully un-add the old frame, and then add back the new frame.
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
enable. I'm sure you'll
come up with more unsafe coding practices to warn about in the future - for
example, consistent_into immediately comes to mind ;-)
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 Jan15, 2014, at 10:08 , Marko Tiikkaja wrote:
> On 1/15/14 7:07 AM, Florian Pflug wrote:
>> On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote:
>>> It's me again, trying to find a solution to the most common mistakes I
>>> make. This time it's accident
On Jan15, 2014, at 11:20 , Pavel Stehule wrote:
> 2014/1/15 Marko Tiikkaja
> On 1/15/14 7:07 AM, Florian Pflug wrote:
> On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote:
> It's me again, trying to find a solution to the most common mistakes I make.
> This time it'
On Jan15, 2014, at 13:08 , Pavel Stehule wrote:
> 2014/1/15 Florian Pflug
>> On Jan15, 2014, at 11:20 , Pavel Stehule wrote:
>> > 2014/1/15 Marko Tiikkaja
>> > plpgsql.warnings = 'all' # enable all warnings, defauls to the empty
>> > list, i.e.
On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote:
> On 1/15/14 1:23 PM, Florian Pflug wrote:
>> The fact that it's named plpgsql.warnings already clearly documents that
>> this only affects plpgsql. But whether a particular warning is emitted
>> during compilation or d
outside of the frame. Which, I guess,
is a box that best stays closed...
I'm currently thinking the best way forward is to get a basic patch
without any NUMERIC stuff committed, and to revisit this after that's done.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing lis
On Jan14, 2014, at 17:39 , Florian Pflug wrote:
> On Jan14, 2014, at 11:06 , David Rowley wrote:
>> Here's a patch which removes sum(numeric) and changes the documents a little
>> to remove a reference to using sum(numeric) to workaround the fact that
>> there's
On Jan16, 2014, at 02:32 , Florian Pflug wrote:
> On Jan14, 2014, at 17:39 , Florian Pflug wrote:
>> On Jan14, 2014, at 11:06 , David Rowley wrote:
>>> Here's a patch which removes sum(numeric) and changes the documents a
>>> little to remove a reference to usin
On Jan16, 2014, at 09:07 , David Rowley wrote:
> On Wed, Jan 15, 2014 at 5:39 AM, Florian Pflug wrote:
>> The notnullcount machinery seems to apply to both STRICT and non-STRICT
>> transfer function pairs. Shouldn't that be constrained to STRICT transfer
>> function p
I had some more fun with this, the result is v2.5 of the patch (attached).
Changes are explained below.
On Jan16, 2014, at 19:10 , Florian Pflug wrote:
> On Jan16, 2014, at 09:07 , David Rowley wrote:
>> On Wed, Jan 15, 2014 at 5:39 AM, Florian Pflug wrote:
>>> The notn
floating around. Could you push your latest version?
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 Jan17, 2014, at 20:34 , David Rowley wrote:
> On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug wrote:
>
>> I've now shuffled things around so that we can use inverse transition
>> functions
>> even if only some aggregates provide them, and to allow inverse trans
in the
regression tests which simply concatenates all the calls into a string, e.g.
you might get "F:1 F:2 F:3 I:1" if we aggregated 1,2,3 and then removed 1.
I think that should be possible with an SQL-language forward and inverse
transfer function, but I haven't tried. I can try, if you want.
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 Jan18, 2014, at 06:15 , David Rowley wrote:
>> On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote:
>> On Jan17, 2014, at 23:34 , David Rowley wrote:
>>> The test turned out to become:
>>> if (state->expectedScale == -1)
>>> stat
ows=1 loops=1)
-> Index Only Scan using boolvals_v_idx on boolvals
(cost=0.29..474.41 rows=9950 width=1) (actual time=0.061..0.061 rows=1 loops=1)
Index Cond: (v IS NOT NULL)
Heap Fetches: 1
Total runtime: 0.100 ms
which looks fine, no?
best
to
do that tomorrow. Otherwise, things look good as far as I'm concerned.
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 tomorrow. Otherwise, things look good as far as I'm concerned.
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 Jan20, 2014, at 08:42 , David Rowley wrote:
>> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>> * An assert that the frame end doesn't move backwards - I realized that
>> it is after all easy to do that, if it's done after the loop which adds
>
ular warning then we
ought not warn about it anyway, I guess, because that would indicate that there
are genuine reasons for doing whatever it is the warning complains about.
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
allowing aggregates to have 2 forward transition functions and if the 2nd
> one exists then it could be used in windowing functions where the frame
> does not have "unbounded following".
I don't think adding yet another type of aggregation function is the
solution here.
be
On Jan20, 2014, at 15:20 , Florian Pflug wrote:
> * In CREATE AGGREGATE, we should state the precise axioms we assume about
> forward
> and inverse transition functions. The last time I read the text there, it was
> a bit ambiguous about whether inverse transition func
th GCC's desire to check format strings.
>
> That last is a deal-breaker. It's not just whether "gcc desires" to check
> this --- we *need* that checking, because people get it wrong without it.
There's an attribute that enables this check for arbitrary func
On Jan23, 2014, at 01:17 , David Rowley wrote:
> On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
>> If you want to play with
>> this, I think the first step has to be to find a set of guarantees that
>> SUM(float) is supposed to meet. Currently, SUM(float) g
;s final function doesn't take an
argument of type anyelement, even though it returns anyarray.
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 Jan23, 2014, at 01:07 , David Rowley wrote:
> On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug wrote:
>> On Jan20, 2014, at 08:42 , David Rowley wrote:
>> >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>> >> * I've also renamed INVFUNC to INV
number of rows
smaller than the hypothetical row, AFAICS.
Another example (that we don't currently provide, but still) would be a
histogram aggregate which receives an array of buckets as direct args and
returns a similarly shaped array of counters.
best regards,
Florian Pflug
--
Sent vi
On Jan23, 2014, at 17:20 , Tom Lane wrote:
> Florian Pflug writes:
>> Is there a particular reason why the "direct" arguments of ordered-set
>> aggregates are not passed to the transition function too?
>
> Because they have to be evaluated only once.
>
> I
t can be applied to so many aggregates, but let's not try to do
> it all at once.
Working on that now, will post individual patches later today.
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
like
ALTER SYSTEM SET synchronous_commit='local';
Doing that seems unlikely to meet much resistant on grounds of principle,
so it seems to me that working on that would be the best way forward for
the submitter. I don't know how hard it would be to pull this off,
though.
best
On Jan25, 2014, at 09:50 , David Rowley wrote:
> On Thu, Jan 23, 2014 at 1:57 PM, Florian Pflug wrote:
>> On Jan23, 2014, at 01:17 , David Rowley wrote:
>> > On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
>> >> If you want to play with
>> >>
aranteed by the C standard - it says overflows of signed integral types
produce undefined results. We currently depend on wrapping semantics for
these types in more places, and therefore need GCC's "-fwrapv" anway, but
I still wonder if adding more of these kinds of checks is a good ide
gt; even knows that is being proposed and would likely cause more
> discussion if they did. So I wish to push back the # syntax to a later
> release when it has had more discussion. It would be good if you could
> lead that discussion in later releases.
+1
best regards,
Florian Pflug
On Jan26, 2014, at 00:24 , David Rowley wrote:
>> On Sat, Jan 25, 2014 at 3:21 PM, Florian Pflug wrote:
>> On Jan24, 2014, at 08:47 , Dean Rasheed wrote:
>> The invtrans_minmax patch doesn't contain any patches yet - David, could
>> you provide some for these fun
with" for want of a
> better name. And with it I can do:
>
> $ make check-with TESTS="json jsonb"
>
> and have it do the temp install etc and then run just those two tests.
+1 for the feature (+Inf, actually), but will this work if the tests
depend on stuff crea
simply do what
normal functions calls do and pretend they return NULL for NULL inputs.
Not sure how the rule that forward transition functions may not return
NULL if there's an inverse transition function would fit in if we do
the latter, though.
The question is - is it worth it the effort
the connection" if it responds to a SYN packet with RST...
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 Jan29, 2014, at 09:59 , Dean Rasheed wrote:
> On 28 January 2014 20:16, Florian Pflug wrote:
>> On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
>>> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
>>> executor. To me, that seems overly re
0x10(%rcx),%rdi
0x00647f4b : movq $0x0,0x48(%rcx)
0x00647f53 : movb $0x0,0x41(%rcx)
0x00647f57 : callq 0x606210
I haven't checked the offsets, but since lwWaitLink is an 8-byte quantity
and lwWaiting a single-byte quantity, it's pretty much certain that the
fi
ind it to block indefinitely.
I wonder whether LWLockRelease really needs to update lwWaitLink at all.
We take the backends we awake off the queue by updating the queue's head and
tail, so the contents of lwWaitLink should only matter once the backend is
re-inserted into some wait queue. But w
On Feb14, 2014, at 11:45 , Andres Freund wrote:
> On 2014-02-13 15:34:09 +0100, Florian Pflug wrote:
>> On Feb10, 2014, at 17:38 , Andres Freund wrote:
>>> On 2014-02-10 11:11:28 -0500, Tom Lane wrote:
>>>> Andres Freund writes:
>>>>> So what we nee
On Feb14, 2014, at 13:36 , Andres Freund wrote:
> On 2014-02-14 13:28:47 +0100, Florian Pflug wrote:
>>> I don't think that can actually happen because the head of the wait list
>>> isn't the lock holder's lwWaitLink, but LWLock->head. I thought the same
On Feb14, 2014, at 14:07 , Andres Freund wrote:
> On 2014-02-14 13:52:45 +0100, Florian Pflug wrote:
>>> I agree we should do that, but imo not in the backbranches. Anything
>>> more than than the minimal fix in that code should be avoided in the
>>> stable b
On Feb14, 2014, at 16:32 , Andres Freund wrote:
> On 2014-02-14 10:26:07 -0500, Tom Lane wrote:
>> Florian Pflug writes:
>>> Another idea for a fix would be to conflate lwWaiting and lwWaitLink into
>>> one
>>> field. We could replace "lwWaiting
On Feb14, 2014, at 16:51 , Andres Freund wrote:
> On 2014-02-14 15:03:16 +0100, Florian Pflug wrote:
>> On Feb14, 2014, at 14:07 , Andres Freund wrote:
>>> On 2014-02-14 13:52:45 +0100, Florian Pflug wrote:
>>>>> I agree we should do that, but imo not in the
On Feb14, 2014, at 19:21 , Andres Freund wrote:
> On 2014-02-14 18:49:33 +0100, Florian Pflug wrote:
>> Well, the assumption isn't all that new. We already have the situation that
>> a PGPROC may be not on any wait queue, yet its lwWaitLink may be non-NULL.
>> Currentl
's a patch in the current
CF, I believe, which adds support for inheritance to foreign tables, so all
you'd
have to do is to make the foreign table's inheritance structure match the remote
table's.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-
EG$((?:[^'"$;]+|"[^"]*"|'(?:[^']*|'')*'|(\$[^$]*\$).*\2)+)$REG$, 'g');
Time: 696.137 ms
postgres=# select regexp_matches(' $a$b$c$d$e$f$g$h$i$',
$REG$((?:[^'"$;]+|"[^"]*"|'(?:[^']
On Feb21, 2014, at 13:44 , John Williams wrote:
> I'm writing a pgsql extension in C, which is multithreaded. The SPI
> connection is global, so do I have to implement a lock to make sql
> queries in each thread, or can I make a connection on a per-thread basis?
Postgres backends aren't multi-thr
27;]*|'')*'|(\$[^$]*\$).*\2)+)$REG$, 'g');
regexp_matches
-
{" ",NULL}
{a,NULL}
{b,NULL}
{c,NULL}
{d,NULL}
{e,NULL}
{f,NULL}
{g,NULL}
{h,NULL}
{i,NULL}
{j,NULL}
(11 rows)
Time: 4787.239 ms
Aha! Since we go
On Feb24, 2014, at 17:50 , Dean Rasheed wrote:
> On 20 February 2014 01:48, Florian Pflug wrote:
>> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
>>> In fact, I'm
>>> currently leaning towards just forbidding non-strict forward transition
>>> function
If so, can't we just make pg_dump always spell out the operator class
explicitly? Then changing the default will never change the meaning of
database dumps, so upgraded clusters will simply continue to use the
old (now non-default) opclass, no?
best regards,
Florian Pflug
--
Sent via pgs
On Feb27, 2014, at 17:56 , Tom Lane wrote:
> Florian Pflug writes:
>> Maybe I'm missing something, but isn't the gist of the problem here that
>> pg_dump won't explicitly state the operator class if it's the default?
>
> That's not a bug, it'
t least version
x.y before inet_gist can be installed". That would avoid failing with a rather
cryptic error later.
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
SPLITTER my_xml_splitter;
As far as I can tell, the idea is to allow a datatype to influence how
it's split into chunks for TOASTing so that functions can fetch only
the required slices more easily. To judge whether that is worthwhile or
not, you'd have to provide a concrete example of
On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
> On 3 March 2014 23:00, Florian Pflug wrote:
>>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>>
>>> double tperrow = winaggstate->aggfwdtrans /
>>> (inst->nlo
formance characteristics depends on the input data,
so we IMHO need some way for users to check what's actually happening.
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 Mar5, 2014, at 18:27 , Dean Rasheed wrote:
> On 5 March 2014 14:35, Florian Pflug wrote:
>> When I added the EXPLAIN stuff, I initially simply reported the number
>> of times nodeWindowAgg has to restart the aggregation. The problem with
>> that approach is that not a
ak things, so why do it if there's no clear benefit?
In the EPERM case (or, rather the non-ENOENT case), I agree with Amit
that "4" (meaning "program or service status is unknown") fits much better
than "1" (meaning "program is dead and /var/run pid file exists&quo
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday use
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday use
can be found here:
https://github.com/fgp/lockbench.
The different LWLock implementations live in the various pg_lwlock_* subfolders.
Here's a pointer into the relevant thread:
http://www.postgresql.org/message-id/651002c1-2ec1-4731-9b29-99217cb36...@phlo.org
best regards,
Florian Pflug
that, PL/pgSQL is about as appealing as BASIC
as a programming language...
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
p name, whereas a quoted "+" would simply become part of
the user name (or group name, if there's an additional unquoted
"+" before it).
So +foo would refer to the group , +"FOO" to the group ,
and +"+A" to the group <+A>.
I haven't checked if such an approach would be sufficiently
backwards-compatible, 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
.
>>
>> It’s the default. When you run `launchctl load -w` it overrides it to false
>> in
>> its database. I’m fine to have it be less opaque, though.
>
> Yes, AFAICT it’s conventional to specify Disabled=true in a launchd plist and
> use launchctl to enable the item.
- but as you say, that set doesn't necessarily the set of columns in the
FK constraint at all.
So currently, it seems that the lock only prevent concurrent DELETES, but
not necessarily concurrent UPDATEs, even if such an UPDATE changes the parent
that a child row refers to.
Independent from
Florian Pflug wrote:
> So in conclusion, the lock avoids raising constraint violation errors in
> a few cases in READ COMMITTED mode. In REPEATABLE READ mode, it converts some
> constraint violation errors into serialization failures. Or at least that's
> how it looks to me.
I
PK constraint is broken. I don't think that's acceptable in any isolation
level.
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
why we want another mechanism unless it's needed in some
> other context.
I've wanted to name the field of rows created with ROW() on more than
one occasion, quite independent from whether the resulting row is converted
to JSON or not. And quite apart from usefulness, this is a matte
aker lock level with SELECT FOR
NO KEY UPDATE.
The attached patch updated README.tuplock accordingly.
best regards,
Florian Pflug
README.tuplock.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
e of doing that over fixing the crosscheck logic would be
that it'd make it possible to write concurrency-safe FK triggers in any
procedural language.
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
e corresponding out-file which shows that SSI permits the concurrent
schedule. Since SSI doesn't concern itself with RI enforcement queries,
it would also permit that schedule if we extended the cross-check, I think.
(I used REL9_4_STABLE as of today to try this, commit
1cf54b00ba2100083
that I'd but the burden on the session
that attempts to remove a parent row, instead of on the sessions which
add or remove children.
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 Oct24, 2014, at 19:32 , Robert Haas wrote:
> On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug wrote:
>> The only other option I see would be so teach the executor to check
>> whether *any* snapshot between the transaction's snapshot and a current
>> snapshot would s
On Oct24, 2014, at 20:24 , Robert Haas wrote:
> On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug wrote:
>>> What about doing one scan using SnapshotAny and then testing each
>>> returned row for visibility under both relevant snapshots? See
>>> whether there is any
ASCADE instead of RESTRICT. So even a full UPDATE or DELETE
of the child rows doesn't help.
But maybe I miss-understood what you proposed.
best regards,
Florian Pflug
fk-consistency2.spec
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
field contained in
some unique index
.) A DELETE conflicts always conflicts with a SHARE or UPDATE lock since it, in
a way, touches all fields
.) A UPDATE lock always conflicts with a SHARE lock, since there are no two
non-overlapping sets of fields that we could lock.
.) SHARE locks never confl
x where specified, and a share lock otherwise).
The only difference is that instead of presenting this to the user as an
entirely new lock type, we instead present it as a generalization of SHARE
locks. The advantage being that *if* we ever figure out a way to support more
fine-grained locking o
ight be other obstacles as well...
BTW, my "serializable_lock_consisteny" patch would allow you to do this purely
within pl/pgsql in a race-condition free way. So if that patch should get
applied you might want to consider this as a workaround. Whether it will get
applied is yet to be s
only a certain subset of columns are to be
prevented from being updated.
So I figured we could do the check while executing the query, probably when
we're about to lock the first tuple. The result could be cached then, so we'd
only incur the overhead once. I'd also expect t
On Dec1, 2010, at 17:11 , Kevin Grittner wrote:
> Florian Pflug wrote:
>
>> BTW, my "serializable_lock_consisteny" patch would allow you to do
>> this purely within pl/pgsql in a race-condition free way. So if
>> that patch should get applied you might want t
On Dec1, 2010, at 17:17 , Tom Lane wrote:
> Florian Pflug writes:
>> The validity wouldn't change, only the kind of lock taken. If all columns to
>> be locked are part of some unique index, we'd record that fact in the locked
>> tuple's infomask, and thu
On Dec1, 2010, at 18:44 , Tom Lane wrote:
> Florian Pflug writes:
>> On Dec1, 2010, at 17:17 , Tom Lane wrote:
>>> There's not enough space in the infomask to record which columns (or
>>> which unique index) are involved. And if you're talking about data tha
On Dec2, 2010, at 00:59 , Jim Nasby wrote:
> On Dec 1, 2010, at 11:09 AM, Florian Pflug wrote:
>> An UPDATE on such a SHARE locked row would be allowed despite the lock if it
>> only changed columns not mentioned by any unique index.
>
> On a side-note, by "change
on-READ ONLY
transactions. Then a flag in the proc array that marks non-READ ONLY
transactions should be sufficient, plus a wait-and-retry loop to take snapshots
for SERIALIZABLE READ ONLY DEFERRABLE transactions.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hacke
s stream of overlapping READ
WRITE transactions.
I have to admit though that I didn't really think this through thoroughly yet,
it was more of a quick idea I got after pondering this for a bit before I went
to bed yesterday.
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 from
regtype to cstring that happens when the result is transferred to the client.
For further information, you might want to check out the documentation of the
various reg* types provided by postgres).
Hope that helps,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
#x27;d both
document that fact it is correct only for SERIALIZABLE transactions *and*
prevent corruption should the isolation level be something else due to a pilot
error. Nice, simply and quite effective.
BTW, I hope to find some time this evening to review your more detailed
proposal fo
here? I certain would *love* to see
something like this either as a contrib module or in core.
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 Dec11, 2010, at 16:03 , Pavel Stehule wrote:
> 2010/12/11 Florian Pflug :
>> On Dec11, 2010, at 06:20 , Pavel Stehule wrote:
>>> I wrote a few functions for record type - record_expand,
>>> record_get_fields, record_get_field, record_set_fields.
>>
>> Jus
CAST() to be skipped for
assignment to variables. Then, you could write
v_value := fieldvalue(myrec, 'f1', true)
That'd at least free you from having to specify the type in some cases. But
still, even this seems to be a lot of effort for quite little gain...
best reg
ented, then this function will be changed to
> polymorphic, but from user's perspective, there isn't a change.
I don't really understand why you resist the idea of a dummy parameter so much.
It might not be pretty, but is it bad enough to rectify putting in all this
work? Plus, the w
y consistent, I believe
most users will expect pg_upgrade (and to a lesser extent also pg_dump and
pg_restore) to be unaffected by such settings.
Should we provide a way (for super-users only, of course) to skip
per-database/per-role settings when connecting?
best regards
Florian Pflug
--
Se
h on scholar.google.com for "estimate conditional
probability" didn't turn up anything useful, but it's hard to believe that
there isn't at least some literature on the subject.
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 Dec12, 2010, at 17:01 , Tom Lane wrote:
> Florian Pflug writes:
>> pg_upgrade aborted during the step "Adding support functions to new cluster"
>> with "ERROR: permission denied for language c" error. Unfortunately, the
>> log didn't include the
to to something else either per-database, per-user or both.
Actually, I'd like to provide an option for pg_dump and pg_restore to do that
too (not by default, though). If people think this is a good idea, I could come
up with a patch.
best regards,
Florian Pflug
--
Sent via pgsql-hackers maili
On Dec13, 2010, at 16:40 , Tom Lane wrote:
> Florian Pflug writes:
>> On Dec13, 2010, at 00:16 , Robert Haas wrote:
>>> And in fact it strikes me that we might not have much choice about how
>>> to fix this. I think we are not going to retroactively change the
>
tting this together!
> - serializable lock consistency - I am fairly certain this needs
> rebasing. I don't have time to deal with it right away. That sucks,
> because I think this is a really important change.
I can try to find some time to update the patch if it suffers from bit-rot.
Would
1 - 100 of 759 matches
Mail list logo
