g the data and left your master copy of the
index corrupt. If you are worried about that, you can do another re-sync
after you finish the REINDEXing. This is not necessary unless you
experienced at least one crash on 9.2.0.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing li
-]gist indexes. And range types go together well
with exclusion constraints. So, I'm not sure I follow how this is a
reason to use ip4r rather than a range type -- can you clarify?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postg
with greater convenience, even if
it could cause some confusion.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
and upgrade
statistics. However, allowing statistics to be upgraded could be a
challenge if the statistics format changes between releases.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nges did support NULLs; the queries you mention would
have to return NULL, not FALSE.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s just a convenience that passing NULL to a constructor creates an
unbounded range. The alternatives of having extra constructors for
unbounded ranges were discussed, but seemed more awkward.
Note that ranges do not allow either bound to be NULL. That would create
a lot of semantic problems.
Does
enerally for all range types, because the
total order might be different. For instance, we can't cast between a
textrange and int4range, because:
['09','1']
is a valid text range, but:
[9,1]
is not.
Regards,
Jeff Davis
--
Sent via pgsql-general maili
erent types of expressions. Offhand, I don't even know of a
way to preserve the typmod through even a simple function.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
dd Yen and US$?
Why not have various rounding functions that do exactly what you want?
Then you can use them anywhere you want in an expression.
Tying a bunch of magic to the column, I/O function, or type system just
seems like the wrong approach when it comes to real differences (like
precision).
Re
't stored in a column, e.g. literals or the results
of some expression.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
All that being said, there may be some use case for something like what
you are describing, if you get creative.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
n rangetypes.c, like range_union().
I agree it would be nice to make it easier to define new range type
functions with other PLs and not be so reliant on C.
I like the idea of having functions that return a range of the same type
but with some modification. Not quite update-in-place as you sugges
ttp://sigaev.ru/git/gitweb.cgi?p=plantuner.git;a=blob;hb=HEAD;f=README.plantuner
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, 2012-08-03 at 10:42 -0700, Jeff Davis wrote:
> On Fri, 2012-08-03 at 17:06 +0200, Andreas Kretschmer wrote:
> > great feature, but i can't find a TIMERANGE, i want to store time-ranges,
> > for
> > instance [10:00:00,16:00:00), how can i do that?
>
>
nswer. I believe we discussed including this as a
built-in range type at some point, but decided against it. I can't
remember the reason right now.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www
robably crashed, but
> that shouldn't cause the WAL and heap corruption observed by the OP.
Is it possible that the machine has write cache enabled?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
eans that there is no upper bound.
Ranges have their own internal concept of unbounded ranges, so they work
for other data types that don't have a concept of infinity (like
"integer").
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ease help me.
Do you have activity on the database? If so, autovacuum is normal.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ormation?
Yes, these messages are delivered via notice processing (not to be
confused with LISTEN/NOTIFY):
http://www.postgresql.org/docs/9.2/static/libpq-notice-processing.html
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
or rollback required) but I would complain loudly if this were
> to be the default, and I don't see a real need for it.
It's already available in psql. See ON_ERROR_ROLLBACK:
http://www.postgresql.org/docs/9.2/static/app-psql.html
Regards,
Jeff Davis
--
Sent via pgsql-general ma
/static/sql-createsequence.html
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l exactly what problem you're describing, but it
sounds similar to the one solved here:
http://people.planetpostgresql.org/dfetter/index.php?/archives/66-VIEW-triggers-RETURNINGhtml
If I misunderstood, please be more descriptive about what you are trying
to do, what code you wrote, and wha
eference q_base_table, and then
record_rubricator could also reference q_base_table?
Also, I don't understand what you mean about propagating data. What data
do you want to propagate?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make ch
nteresting idea. However, as far as I know, there is no such support.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the exact definitions of
your functions.
Also, as a debugging strategy, I recommend that you look at the pieces
that do work, and slowly build up the fragments until it doesn't work.
That will allow you to see the inputs to each function, and it makes it
easier to see why it doesn't wor
e suggests), and then do a "SELECT oid,* FROM pg_authid" and
send the output along?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> it
> was for.
An additional advantage is that if you issue NOTIFY with exactly the
same message many times in one transaction, the LISTENer only gets the
message once.
In other words, a big update won't case a million rebuilds of the static
pages.
Regards,
Jeff Davis
--
e some
implementation quality differences, however.
> If I'm executing say a PL/Perl procedure, once I've executed it the first
> time, can I take it the interpreter is now resident withing the PG footprint?
Yes.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing li
#x27;m not 100% confident in my response, so please take it
with a grain of salt, but I hope it is helpful anyway.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
up on -hackers, so hopefully it will be resolved.
In the meantime, you're stuck with the messages cluttering your
logfiles.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
erpolation. Hopefully that
answers your question.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
27;re
losing a lot there. How does it help you?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
you know the range of data.
>
> What do you think?
Why not just create the CHECK constraint as NOT VALID, and never
validate it? It will still enforce the constraint, it just won't
validate it against your old data, which sounds like what you want.
Regards,
Jeff Davis
--
S
ilable in 9.2, which is still in beta.
http://www.postgresql.org/docs/9.2/static/sql-altertable.html
CHECK constraints don't use indexes, so CREATE INDEX CONCURRENTLY
doesn't help you.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
ilable to process.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
0 <= x < 20
20 <= x < 30
...
you can use a tree structure. But, obviously, postgres won't know enough
about the conditions to know that a tree structure is appropriate from a
given sequence of WHEN clauses. So, you should use one trigger and code
the condition matching yourself.
R
ybe not too bad depending on
what the rest of the application is doing.
What are you trying to accomplish with so many triggers?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
held for an instant anyway. Some of these optimizations
went in 9.2 (not released yet) but I think the one you need is in 9.1.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
27;s quite useless, isn't it?
I meant a backtrace from the core file. If you don't have a core file,
then you won't have this information.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
if there is still a problem? It might be a problem related to openssl.
If it is a problem with openssl, try to figure out if the library
matches the headers. You should be able to see what's happening during
"make" when it's linking the "psql" or "createuser" b
tting the PANIC afterwards. What can cause a segmentation fault? Is
> there anything to analyse further?
It's clear that they are connected, but it's not clear that it was the
cause. To speculate: it might be that disk corruption caused the
segfault as well as the PANICs.
Do you have any c
first, so you have some room to explore to find
out what happened.
It seems very unlikely that problems on the master would be caused by
the presence of a replication slave.
> Should I check or exchange my hardware? Is it a hardware problem?
It could be.
> Should I still worry about it?
Yes
ts it; then I
do _not_ recommend such a thing for any production system.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
he same. But that seems fragile and I don't
see a good way of doing it, anyway.
We need a way to take a base backup of just the catalogs, essentially,
and leave the user data intact. Probably quite a few details to sort out
though.
Regards,
Jeff Davis
--
Sent via pgsql-general ma
this as a new feature that needs its own
testing and documentation.
It's important though, because as you point out downthread, rsync
doesn't really solve the problem (still takes time proportional to the
user data size).
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ally, they will have
different system IDs, and potentially different on-disk representation
of the catalogs, right?
So how can you resume streaming without rebuilding the slaves?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ery should succeed:
insert into y values ('[2012-01-02,2012-01-04)');
because that range is contained in a value in the table x.
So it's slightly different semantics than a normal foreign key.
But yes, normal foreign keys (based on equality) work fine over range
types.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
NT TRIGGER.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
functions (in various languages), so that will allow you to make use of
the library. It's hard to give more specific advice until you've found
the library you'd like to work with.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
doesn't have
anything under it to prevent/fix torn pages (unless your filesystem
prevents them).
Of course, checksums are used to prevent recovery from attempting to
play a partial or otherwise corrupt WAL record.
What kind of corruption are you trying to detect?
Regards,
Jeff Da
ctions?
Yes, one backend per connection. When you close the connection, the
backend process should go away.
Under some circumstances, that might not always happen immediately if
the backend is in the middle of doing some work.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing
?
If you'd like to know what's happening on your system, the best way is
to start out with (while the pg_dumps are running):
SELECT * FROM pg_stat_activity;
in a separate client connection. If the "waiting" flag is true on one
query for a significant amount of time, it
ION-ISOLATION
http://www.postgresql.org/docs/9.1/static/sql-set-transaction.html
http://www.postgresql.org/docs/9.1/static/transaction-iso.html#XACT-SERIALIZABLE
That will still throw an error, but it protects you from all kinds of
similar problems that might not be caught by a primary key.
Regards,
al would look
like:
'\000'
or perhaps:
'\x00'
I hope this helps. My advice is to just try it in different ways and see
what strings are sent to postgresql (by setting
log_statement_min_duration=0, which will log all the SQL).
Regards,
Jeff Davis
--
Sent via pgsq
hot standby, which is also
recovery mode) to "up" (that is, can accept write queries and operate
normally) is not a reversible process. You have to make a new base
backup of another system to start recovering again.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-g
o a primary, you can't set it to start recovering
from another system again (without taking a new base backup).
Did I understand your question correctly?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ture called Range Types, which will
hopefully be in 9.2.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
slowly for a long time. In the end,
matching the standard syntax should be a net win against SQL injection
(as well as making porting easier).
I hope this helps.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
least as a test. That will give you advance warning of any problems.
However, if you are developing a new application, you might as well
develop against 9.1, because it will stabilize while you develop and do
your own testing.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing li
process.
> There'd be no need to go through full auth or even bother with SSL,
> because it's a one-time random (or hash-based) code. Pooling systems
> could send this to _all_ servers, or it could be prefixed with a server
> identifier that helped poolers route it to th
/archives.postgresql.org/pgsql-general/2009-03/msg00434.php
That means that there is no way to nicely and reliably shut down
postgresql from the client alone, nor from the server alone. The only
way is to send a SIGTERM to the backend *and* terminate the client
connection. Unless someone has a bette
LECT 1 FROM registrations local_reg
WHERE local_reg.id = remote_reg.id);
(disclaimer: I didn't test this query out, it's just for illustrating
the idea).
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
he exact reason it's prohibited, but it seems like there would
be a problem somewhere along these lines.
Interesting idea though.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ostGIS, and you need to recompile them against the new
version of PostGIS.
It might be better to ask on the PostGIS mailing list, they might have
more context that can help you.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
of this code changes again in 9.1. In 9.1, you
probably want to look for the "repeatable read" transaction.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
opy that data back into your empty pg_type.
5. Try to do a logical backup, load that data into a fresh instance, and
you might be OK.
I haven't really thought this plan through, but that's the first thing
I'd try (after doing file-level copies of everything, of course!).
Regards
traverse and different queries using different levels of
qualification, it gets a little more messy and I think a mistake is more
likely.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
we've felt some
pressure to improve the type system from a number of different
projects*.
Regards,
Jeff Davis
* That being said, PostgreSQL's type system is actually very good.
Consider the sophisticated type infrastructure (or at least plumbing
around the type system) requi
some effort (which is an understatement) to go
through the system and figure out which ones should be local and which
ones should be fully-qualified.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
pair (catalog, oid). Even if the end result isn't much more
complex, getting there is not trivial.
> See also how SQLite works; this "mount" being analogous to their "attach".
I'm not sure SQLite is the best example. It has a radically different
architectu
work look more minor
or the benefits look more major ;)
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
d be much harder for you to test.
But it might be worth searching for issues/bugs with your particular
version of the filesystem.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t; HAVING count(*) > 1;
Maybe you could use a self-join as a workaround for now, just to clean
up the data?
SELECT geocode, other_columns from a a1, a a2 where a1.other_columns <>
a2.other_columns and a1.geocode ~= a2.geocode;
Regards,
Jeff Davis
--
Sent via pgsql-gener
sted parties.
If you'd like to submit a patch, I suggest first asking on -hackers
whether improvements to the built-in spatial types would be accepted.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
uring a checkpoint. How long
between checkpoints on this system? Is it possible that you noticed
before postgresql caused an automatic checkpoint?
Also, you can do a manual checkpoint with the CHECKPOINT command.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@
extra information to WAL (where "extra
information" happens to be "full data pages" in this case); not whether
to write the WAL itself in full pages.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> expect them to be.
So, don't trust them to be unique then. Make up your own unique
identifier, and use that.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
. It's also an attribute
of the entity now, because it's printed on the cards you hand to people.
The thing that I think is a mistake is to use generated IDs like an
internal implementation detail (i.e. hide them like pointers); then at
the same time mix them into the data model.
R
On Mon, 2011-05-02 at 20:06 -0600, Rob Sargent wrote:
> Jeff Davis wrote:
> > In particular, I think you are falsely assuming that a natural key must
> > be generated from an outside source (or some source outside of your
> > control), and is therefore not reliably unique.
>
7;s merely an implementation detail and should not be a
part of the model.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ainly active
with meetings every month. The next one is May 10.
Check out the user group mailing list here:
http://archives.postgresql.org/sfpug/
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, 2011-04-29 at 10:25 +0200, Andres Freund wrote:
> On Thursday, April 28, 2011 11:44:37 PM Jeff Davis wrote:
> > On Thu, 2011-04-28 at 07:29 +0200, pasman pasmański wrote:
> > > Hi. Yesterday i have an idea, that sometimes row locks may be skipped,
> > > when t
st people would not
be using row locks if they already have an EXCLUSIVE lock on the table.
Do you have a use-case in mind?
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Mac and Linux have a different notion of what
en_US collation means (I couldn't find any standard anywhere to say that
one was right and the other was wrong). So, that risks index corruption.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
s
maintains the integrity of the FK, then it's usually more readable and
understandable. So using immediate constraints may encourage a more
readable style.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
of constraint perform well,
unfortunately. But that may not be a problem in your case -- try it and
see if the performance is acceptable.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
mem setting. However
> I'm now getting further out of memory issues during the same stage of plpgsql
> function as mentioned before.
>
> The function itself is run as part of larger transaction which does the
> following:
Where is the source to the function?
Regards,
RACT(YEAR FROM invoice_date),
> innvoice_number);
CREATE UNIQUE INDEX invoices_constraint_idx ON invoices
(EXTRACT(YEAR FROM invoice_date), invoice_number);
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
No, reinstalling the extension should fix it.
Also, there is a mailing list for this extension as well:
http://lists.pgfoundry.org/pipermail/temporal-general/
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
r perhaps earlier, if I can find the time), I'll do some
clean up of the existing pgsql-temporal PERIOD type, and do a release of
that.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
lose any meaningful OIDs. So what do you have? Something else.
Therefore, you've lost closure.
Now, maybe there is a good reason to sacrifice closure and other nice
properties of the relational model. But there is a perception among many
people (like Andy) that the case has not been made.
Regards
ndex, and an index can only
have one index access method (btree, gist, etc.). So you need to have
one index access method that works for both "=" on integers and "&&" on
boxes.
There's no hope of making a btree work for "&&" on boxes, so w
can see, none of these are ideal. But, if you run into a specific
problem, you can usually pick one of these approaches and make it work
with careful determination. Exclusion constraints are much easier,
however ;)
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-genera
mend locking. In fact, the primary reason that exclusion
constraints exist is to prevent unnecessary locking for problems exactly
like this.
I included some links in my other reply that demonstrate how to avoid
that excessive locking while still being safe from race conditions.
Regards,
Jeff
t; CHECK(overlap_at_dest(destination_id, starts, ends));
As Tomas said, that's an unsafe thing to do. I do not recommend using a
table-reading function in a check constraint.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
o be very
similar to your problem, see:
http://thoughts.j-davis.com/2009/11/08/temporal-keys-part-2/
http://thoughts.j-davis.com/2010/09/25/exclusion-constraints-are-generalized-sql-unique/
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
es:
http://www.postgresql.org/support/professional_support
where someone experienced with WAL recovery can help you personally.
Some of these organizations employ people who have done extensive
development on the WAL recovery system and know it _very_ well.
Regards,
Jeff Davis
--
Sent via pgs
se the CREATE UNIQUE
INDEX syntax you showed above.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
g that happened after 9.0.1. It's up to you whether you
consider those serious or not, but I don't think there are any major
issues that should prevent deployment.
Regards,
Jeff Davis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your su
ck was deemed worthwhile for the first release of
the feature, but will be lifted in version 9.1.
Also, "<>" doesn't work (yet) with btree, but in principle there is no
reason why not. Perhaps for 9.1 as well.
Can you please share your use case for this particular c
1 - 100 of 606 matches
Mail list logo
