easy enough to
remove complexity later if it makes sense to do so.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the WAL-before-data invariant on every
new feature[1].
I'm not proposing anything in specific, just a potential re-framing of
the problem.
Regards,
Jeff Davis
[1] If we obey WAL-before-data everywhere WAL is required, the
correctness can be reasonably understood by mere mortals. But when we
themselves. We're talking
about adding another feature that breaks the rule, in a more complex way
than hint bits.
I just wanted to step back for a second and consider the problem from a
different angle before we committed to that.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
truncating the clog, we need to make sure
that there are no references to any transaction IDs that would be cut
off.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
When I build HEAD using just make -s install, everything works fine.
But when I add -j12, it appears to cause problems. This problem
appeared very recently. Output below.
I can get it to work simply by running make -s -j12 install over and
over, and eventually it succeeds.
Regards,
Jeff
On Wed, 2010-12-01 at 22:16 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
When I build HEAD using just make -s install, everything works fine.
But when I add -j12, it appears to cause problems. This problem
appeared very recently. Output below.
Platform?
Oops, sorry
On Wed, 2010-12-01 at 23:34 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I can't see any place that cachedFetchXid is ever invalidated.
Shouldn't it be invalidated before transaction ID wraparound?
The assumption is that the value won't sit there (in a particular
session
; and at that point it's
already too late.
Also, assuming LIMIT K, MergeAppend will have N children, meaning N
limits, meaning an effective limit of K*N rather than K.
Can you be a little more specific about what you mean?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
On Tue, 2010-11-30 at 15:52 -0500, Robert Haas wrote:
On Tue, Nov 30, 2010 at 2:45 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2010-11-30 at 11:12 -0500, Robert Haas wrote:
Could you possibly have ModifyTable - Limit - MergeAppend?
Before MergeAppend knows which tuple to produce
in Java or type class in haskell). A real subtyping system
might also be nice.
That being said, a few details are left to be decided (an
understatement).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
() to be consistent with the rest of the
code, which doesn't MAXALIGN the t_len.
Regards,
Jeff Davis
create table foo(i int4 unique);
insert into foo values(1);
insert into foo values(2);
checkpoint;
select relfilenode from pg_class where relname = 'foo';
relfilenode
without
everyone making their own subtle tweaks.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
representation function.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
always ask the user to
specify everything when creating a Range Type, and then we can make them
default to use the interface functions later. Some, like plus might be
constant, but people certainly might want to specify alternate
comparators.
Regards,
Jeff Davis
--
Sent via pgsql-hackers
now see why you would be hesitant to try to support that.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis pg...@j-davis.com wrote:
I think that's easier when the PK must contain the FK, because then you
only need to lock one record. Even when you need to lock multiple
records, it seems feasible
On Sun, 2010-10-24 at 18:59 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Last development cycle, one of the questions that was unresolved was
whether to handle ranges like a discrete set (that is, [1,5) = [1,4] )
or continuous or both.
Put me in the camp that says you need
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
representation optimizations that certain range types may be able to
exploit. Either approach seems reasonable to me.
I know the wiki page isn't very formal about the approaches yet, but as
we start to coalesce around a basic idea I'll write it up in more
detail.
Regards,
Jeff Davis
--
Sent via
On Mon, 2010-10-25 at 14:11 -0400, Robert Haas wrote:
On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
It would be very useful to be able to specify a granularity -- for
example timestamps with a five minute
On Mon, 2010-10-25 at 13:54 -0400, James Cloos wrote:
JD == Jeff Davis pg...@j-davis.com writes:
JD 2. Fix the input/output functions in a special mode for dump/reload,
JDto make them true inverses.
That can be done by supporting the %A printf(3)/scanf(3) format.
I don't happen
a part of the type system itself.
There may be some utility in a pseudo-type like anyrange, but I think
that's a separate issue.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
alignment might make a 17-byte type look like 24 bytes,
which seems pretty wasteful to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a particular problem?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
? Has anyone done more research into the
necessary details?
Yes, I think so. #3 and #4 are very feasible. #1 and #2 are, as well,
unless I'm missing something.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, and how is the GiST
code supposed to result in that state?
I know some of these questions are answered in the relevant research,
but I'd like to discuss this concrete example specifically.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Sun, 2010-10-17 at 22:53 -0700, Jeff Davis wrote:
2. I think there's a GiST bug (illustrating with PERIOD type):
create table foo(p period);
create index foo_idx on foo using gist (p);
insert into foo select period(
'2009-01-01'::timestamptz + g * '1 microsecond'::interval
for a transaction that you
know will be long-running. Maybe a timeout or something?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
time already, it's nothing new.
With Exclusion Constraints, it's slightly less academic, and it's a new
addition. Still pretty far-fetched; but at least plausible, which is why
I brought it up.
However, I won't argue with the don't do anything approach to
float-timestamps.
Regards,
Jeff
all over my application codebase, even on a moderate
scale.
It's a complexity-reducing and correctness-increasing feature, which is
generally good.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
a special
escape that is really an encoded binary representation, or maybe
resembling float8.
3. Somehow deprecate floating point timestamps or make them unusable in
conjunction with Range Types. I'm not sure if there is demand to keep
them alive or not.
Thoughts?
Regards,
Jeff Davis
--
Sent
like the
determining factor for when we can deprecate floating-point timestamps.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
important.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
).
Both logical and physical replication have a place, and I don't believe
either is the wrong path. If we'd like to add logical replication, we
may be better of starting with Slony (or Londiste) and working from
there.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
the complexity.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
up in time to be a part
of the quorum.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
until you have less than N standbys available. But then it's
no surprise that RAID-5 won't work with 4 drives either.
Now I'm more confused. I assume that was a typo (because a RAID-5 does
work with 4 drives), but I think it obscured your point.
Regards,
Jeff Davis
--
Sent via pgsql
-values.html
The doc for INSERT is a little less clear:
http://www.postgresql.org/docs/9.0/static/sql-insert.html
It explicitly makes room in the INSERT grammar for VALUES, but in that
branch of the grammar it doesn't make room for the ORDER BY, etc.
Regards,
Jeff Davis
--
Sent via pgsql-hackers
Doing git log tags/REL8_3_6 I see two commits after the one labeled
tag for 8.3.6.
The other tags I checked all seem to match what I would expect. I'm not
suggesting that anything be done, I just wanted to point this out in
case something strange happened.
Regards,
Jeff Davis
--
Sent
. If you SPI_connect() without an SPI_finish(), that sounds like
a potential problem (as would anything else that requires cleanup).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
something better?
Perfect. I was just slightly confused reading it the first time, and I
think that would have cleared it up.
Thanks,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
to
properly own a shared latch?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
redundant, and only there for asserts because it doesn't do
anything else. That seems a little strange to me, as well, so (at
minimum) it should be documented that the functions really have no
effect on execution and are required only to support debugging.
Regards,
Jeff Davis
--
Sent via pgsql
On Sun, 2010-09-12 at 10:13 -0700, Jeff Davis wrote:
I'm not too picky about whether it's Assert, ERROR, or PANIC (Asserts
aren't available in production systems, which I assume is why elog was
used); but we should be consistent and document that:
(a) it shouldn't happen
(b) that it's just
the signal, of course.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
. In particular,
that feature only affects existing objects, and you are trying to create
some kind of permissions mask which will affect new objects, as well.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
.
There are still arguments for making it DCL-ish, in the sense that it
is, at least in this case, viewable as a data control issue.
I would be more open to it if it didn't rely on GUCs at all.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
a single use case.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Compiling with RELCACHE_FORCE_RELEASE doesn't pass make check on my
machine.
Is it supposed to pass?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
you for the quick response.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for unimportant things (if it was important, I included
the date as a safeguard) -- so I assume a few other people did, as well.
Would it be worth keeping the old git repository around in a read-only
mode, just in case people have links/SHA1s floating around for it?
Regards,
Jeff Davis
to have a place to turn to if you have an old SHA1
and no other information; even if it's slightly inconvenient.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, 2010-08-01 at 21:57 -0400, Robert Haas wrote:
On Fri, Jul 16, 2010 at 1:19 AM, Jeff Davis pg...@j-davis.com wrote:
Thank you for the review.
On Mon, 2010-07-12 at 17:17 +0900, Itagaki Takahiro wrote:
(1) Exclusion constraints support for operators where x operator x
is false
On Mon, 2010-08-02 at 12:27 -0400, Robert Haas wrote:
I was also wondering if it would be worth adding some additional
regression testing to contrib/btree_gist exercising this new
functionality. Thoughts?
Sure. I attached two tests.
Regards,
Jeff Davis
*** a/contrib/btree_gist
in 8.2 and prior, but ISTM it's
vulnerable to the same issue. Don't we need a modified version of
this patch for the 8.0 - 8.2 branches?
That sounds right. I just saw that the code in question was introduced
in 8.3.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
On Wed, 2010-07-28 at 12:36 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
However, when Simon said We definitely shouldn't do anything that
leaves standby different to primary. you said obviously. Fix2 can
leave a difference between the two, because zeroed pages at the end
about it only in the specific context of ALTER TABLE .. SET
TABLESPACE seems backwards; if there are any bugs there, we're in for
it.
That's a very good point. Now I'm leaning more toward your fix.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
information onto the page. That
seems like it would be a cleaner design, but back-patching a change to
the interpretation of WAL records that might already be on someone's
disk seems dicey at best.
How do you set the LSN before XLogInsert()?
Regards,
Jeff Davis
--
Sent via pgsql
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
as an argument to the function. If the argument
changes, an immutable function can return a different result.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to clean up zero
pages; and (b) it could be an index with different special size, etc.,
and it doesn't seem like a good place to figure that out.
Comments?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
(), so I think it's safe.
I'll test it and submit a patch.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
more confident that it is
correct.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
think they should be used
for both arguments (or neither). Using $$ for one and then shifting to
' for the second argument with no whitespace at all seems like the
least readable option.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, 2010-07-27 at 15:23 -0700, Jeff Davis wrote:
On Tue, 2010-07-27 at 17:18 -0400, Robert Haas wrote:
My first concern with that idea was that it may create an inconsistency
between the primary and the standby. The primary could have a bunch of
zero pages that never make
system getting confused with a NULL result, and then
failing mysteriously with no error message.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
documentation, no users find the usages.
Good idea, new patch attached.
Regards,
Jeff Davis
*** a/contrib/btree_gist/btree_gist.h
--- b/contrib/btree_gist/btree_gist.h
***
*** 9,14
--- 9,16
#include access/itup.h
#include access/nbtree.h
+ #define
On Sat, 2010-05-22 at 01:02 +0300, Marko Tiikkaja wrote:
On 5/21/10 11:47 PM +0300, Jeff Davis wrote:
It also allows you to enforce the constraint that only one tuple exists
in a table by doing something like:
create table a
(
i int,
exclude using gist (i
.
This patch simply removes that sanity check, and leaves a comment in
place.
Regards,
Jeff Davis
*** a/src/backend/executor/execUtils.c
--- b/src/backend/executor/execUtils.c
***
*** 1309,1323 retry:
index_endscan(index_scan);
/*
! * We should have found our tuple
,
exclude using gist (i with ),
unique (i)
);
Regards,
Jeff Davis
*** a/contrib/btree_gist/btree_gist.h
--- b/contrib/btree_gist/btree_gist.h
***
*** 9,14
--- 9,16
#include access/itup.h
#include access/nbtree.h
+ #define BTNotEqualStrategyNumber 6
://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
http://archives.postgresql.org/pgsql-hackers/2010-04/msg00443.php
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
, it wouldn't reuse the
existing MERGES property.
Sorry for the spam on the list.
Not at all, it's an interesting point.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
same
type can conform to two different interfaces.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of the result of a function call, so typmod is not really a part of
the type at all -- it's more a property of the column.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
to define windows over a range of values
defined by the underlying data type. To do this, we need to define
what addition and subtraction mean for a particular data type.
3. Jeff Davis is interested in implementing range types. When the
underlying base type is discrete, e.g. integers, you can
sort of community buy-in, but from a
technical standpoint I don't see a problem here.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and comparison algorithms.
That would probably be an ongoing effort after the GSoC project is
complete.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
there are a lot of issues like this, which would
make storing the visibility information separate from the heap a huge
undertaking. Still worth thinking about, though.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
+1..
The visibility map itself is already an example of compression. If
visibility information were randomly distributed among tuples, the
visibility map would be nearly useless.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
be unset or you will get
wrong results.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be possible to use some structure that is significantly
smaller than holding xmin/xmax for every tuple in the heap, and at the
same time may be acceptably fast to update.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
for the index-only scans.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2010-03-18 at 14:48 -0700, Jeff Davis wrote:
On Thu, 2010-03-18 at 17:17 -0400, Tom Lane wrote:
The VM cause wrong results if a bit is set that's not supposed to be --
right? Am I missing something? How does a seq scan skip visibility
checks and still produce right results
it possible to move to 64-bit xids, if we wanted to.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2010-03-17 at 17:20 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
There are all kinds of challenges there, but it might be worth thinking
about. Visibility information is highly compressible, and requires
constant maintenance (updates, deletes, freezing, etc.). It also
an index rebuild (btree,
gist, and gin are safe against this by using the WAL).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(f3 WITH =) DEFERRABLE INITIALLY
DEFERRED
Any objections?
Looks good to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, of course.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
above the DBMS, you need to invalidate it
when a part of the database is updated. It makes sense that every reader
would want to know about the update, not just those connected to the
master.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, 2010-02-16 at 10:38 -0500, Tom Lane wrote:
2. Add an extra lock to serialize writers to the queue, so that messages
are guaranteed to be added to the queue in commit order.
I assume this is a heavyweight lock, correct?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
. When does the client receive the
error? Might the client code confuse it with an error for something
synchronous, like a command execution?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
the notifications from the master?
Cache invalidation seems to be the driving use case for LISTEN/NOTIFY.
Only the master can invalidate the cache (as Tom points out downthread);
and users on the slave system want to know about that invalidation if
they are explicitly listening for it.
Regards,
Jeff
operation, it's not apparent to me why we should
single out NOTIFY as being so fragile it has to have an ASCII-only
restriction.
Ok, it sounds reasonable to lift the restriction.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
the optional type conversion convenience
functions. As long as it's explicit that the conversion is happening, I
think it's OK.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
the results are in.
The result object already saves the client_encoding. Should an accessor
be provided?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
801 - 900 of 1608 matches
Mail list logo
