egard to trailing
spaces, and I'm concerned that this might cause subtle and hard to find
problems within the application.
Thanks
Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ng on the list, where it will compete
with other possible enhancements on a cost/benefit basis. Thanks
for raising the issue!
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
at
this point I'm inclined to recommend the workaround of using a
separate cluster; but if we get other reports it might be worth
adding to the list of enhancements that SSI could use.
Thanks!
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
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, Jan 20, 2017 at 11:27 AM, Rob Sargent wrote:
> On 01/20/2017 10:05 AM, Kevin Grittner wrote:
>> https://www.postgresql.org/message-id/flat/d8joa0eh9yw@dalvik.ping.uio.no#d8joa0eh9yw@dalvik.ping.uio.no
> Configurable or dynamic? Wouldn't something related to tup
ed to make that configurable.
https://www.postgresql.org/message-id/flat/d8joa0eh9yw@dalvik.ping.uio.no#d8joa0eh9yw@dalvik.ping.uio.no
If you are able to build from source, you might want to test the
efficacy of the patch for your situation.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The E
epeatable read:
https://wiki.postgresql.org/wiki/SSI
And of course, if you haven't already read the fine manual on the
topic:
https://www.postgresql.org/docs/current/static/mvcc.html
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (p
by default) if we get stored procedures which can
return a complex result stream like TDS does. The series of literals
and results sets of different types is something which can be quite
useful to DBAs.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
S
onnection pooler connect to the server with a login with rights to
do the appropriate SET ROLE (preferably without requiring superuser
rights).
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@po
rg/wiki/Jargon :
"A main driving force in the creation of technical jargon is
precision and efficiency of communication when a discussion must
easily range from general themes to specific, finely differentiated
details without circumlocution."
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
but to try to keep terminology
clear, to facilitate efficient communication. There are some terms
we have been unable to avoid using with different meanings in
different contexts (e.g., "serialization"); that's unfortunate, but
hard to avoid. I want to keep it to the minimum neces
ed text suggests, a materialized view is
essentially a cache of the results of the specified query. While,
in rare cases, this may be captured to provide the query results as
of some particular moment in time, the overwhelming reason for
creating a materialized view is to improve performance over a
non-m
hint bits may be another part
of it. The first access to each page after the bulk load would
require some extra work for visibility checking and would cause a
page rewrite for the hint bits.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-gen
tamp > '2016-12-19T20:34:22.315Z'
OR (e.sequenceNumber >= 0
AND (e.sequenceNumber > 0
OR (e.aggregateIdentifier >
'dev:642e1953-2562-4768-80d9-0c3af9b0ff84')
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Dec 16, 2016 at 3:54 PM, Guyren Howe wrote:
> What I need to do is turn this into something similar to the equivalent
> Rails-side constraint failure, which is a nicely formatted error message on
> the model object.
Can you show what the text in such a message looks like?
On Tue, Dec 13, 2016 at 7:37 PM, Melvin Davidson wrote:
> On Tue, Dec 13, 2016 at 7:36 PM, Kevin Grittner wrote:
>> On Tue, Dec 13, 2016 at 5:57 PM, Jonathan Vanasco wrote:
>>
>>> Is there a way to find out when a materialized view was
>>> created/refreshed?
t currently tracked in the system catalogs.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
where most DBAs understood the point
of being able to set a client_encoding that is different from the
server_encoding, I think I would need to pop the cork on some
champagne.
Hm. Maybe a topic for a blog post
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
last
snapshot is completes) to take a PITR-style recovery.
Be sure to follow all the rules for PITR-style backup and recovery,
like deleting the postmaster.pid file and all files under pg_xlog
before starting the recovery. And of course, do NOT delete the
backup_label file created by pg_start_
On Wed, Nov 23, 2016 at 4:43 AM, Charles Clavadetscher
wrote:
> From: Kevin Grittner [mailto:kgri...@gmail.com]
>> Is it possible to upgrade? You are missing over a year's worth
>> of fixes for serious bugs and security vulnerabilities.
>
> Yes. Actually it is fo
ions on the configuration
> of work_mem (if I remember well)
Each connection can allocate one work_mem allocation per node which
requires a sort, hash, CTE, etc.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pg
On Mon, Nov 21, 2016 at 11:34 AM, dhaval jaiswal wrote:
> Due to business impact auto vacuum is off.
You have now discovered some of the the negative business impact of
turning it off. If you leave it off, much worse is likely to
follow.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
uld probably need to raise autovacuum_vacuum_cost limit. And if
autovacuum somehow got turned *off* you are likely to have all
kinds of problems with bloat, and may need to schedule some down
time to get it cleaned up.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL C
te)
and cursors (supported by most database products, including the
three you mention).
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgres
On Wed, Oct 26, 2016 at 3:20 PM, Peter Geoghegan wrote:
> On Mon, Oct 24, 2016 at 8:07 AM, Kevin Grittner wrote:
>> My initial thought is that since reducing the false positive rate
>> would only help when there was a high rate of conflicts under the
>> existing patch,
application code), which will cause a write conflict if two
transactions try to update the same total at the same time, or by
using explicit locking controlled from the application.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mai
lse positive serialization failures is a
worthy goal, but it's gotta make sense from a cost/benefit
perspective.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
p_label file things look exactly
like a crash recovery, which is why it just goes to the last usable
checkpoint; that's the correct behavior for crash recovery.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-ge
On Thu, Oct 20, 2016 at 8:21 AM, wrote:
> Version : 9.2.13
You are missing over a year's worth of bug fixes.
https://www.postgresql.org/support/versioning/
> - remove a file called backup_label
http://tbeitr.blogspot.com/2015/07/deleting-backuplabel-on-restore-will.htm
On Thu, Oct 13, 2016 at 5:26 PM, Thomas Munro
wrote:
> On Fri, Oct 14, 2016 at 2:04 AM, Kevin Grittner wrote:
>> Where do you see a problem if REPEATABLE READ handles INSERT/ON
>> CONFLICT without error?
> I think the ON CONFLICT
> equivalent might be something like
On Thu, Oct 13, 2016 at 3:16 PM, Kevin Grittner wrote:
> On Thu, Oct 13, 2016 at 2:16 PM, Peter Geoghegan wrote:
>> We must still determine if a fix along the lines of the one proposed
>> by Thomas is basically acceptable (that is, that it does not clearly
>> break any
On Thu, Oct 13, 2016 at 2:16 PM, Peter Geoghegan wrote:
> On Thu, Oct 13, 2016 at 6:19 AM, Kevin Grittner wrote:
>> Every situation that generates a false positive hurts performance;
>> we went to great lengths to minimize those cases.
>> To generate a
>> serial
set had successfully committed, and
that it was a transaction which had done writes. To generate a
serialization failure on a single transaction has to be considered
a bug, because a retry *CAN NOT SUCCEED*! This is likely to break
many frameworks designed to work with serializ
On Wed, Oct 12, 2016 at 8:06 PM, Thomas Munro
wrote:
> On Thu, Oct 13, 2016 at 10:06 AM, Kevin Grittner wrote:
>> On Wed, Oct 12, 2016 at 3:02 PM, Peter Geoghegan wrote:
>>
>>> I agree that the multi-value case is a bug.
>>
>>> I think that it should
On Wed, Oct 12, 2016 at 5:21 PM, Peter Geoghegan wrote:
> On Wed, Oct 12, 2016 at 2:06 PM, Kevin Grittner wrote:
>> If the "proper" fix is impossible (or just too freaking ugly) we
>> might fall back on the fix Thomas suggested, but I would like to
>> take advan
On Wed, Oct 12, 2016 at 3:55 PM, Peter Geoghegan wrote:
> On Wed, Oct 12, 2016 at 1:41 PM, Kevin Grittner wrote:
>> Aren't these two completely separate and independent bugs?
>
> Technically they are, but they are both isolated to the same small
> function. Surely it'
On Wed, Oct 12, 2016 at 3:02 PM, Peter Geoghegan wrote:
> I agree that the multi-value case is a bug.
> I think that it should be pretty obvious to you why the check exists
> at all, Kevin. It exists because it would be improper to decide to
> take the DO NOTHING path on the basis o
on-failure strategies will be befuddle by this
>> doomed transaction. And as you and Vitaly have said, there is
>> literally no concurrent update.
>
> I think that you have the right idea, but we still need to fix that
> buffer lock bug I mentioned...
Aren't these two completely
On Wed, Oct 12, 2016 at 10:06 AM, Kevin Grittner wrote:
> The test in ExecCheckHeapTupleVisible() seems wrong to me. It's
> not immediately obvious what the proper fix is.
To identify what cases ExecCheckHeapTupleVisible() was meant to
cover I commented out the body of the func
onstraint" and doesn't run to
> "ExecCheckHeapTupleVisible" check.
> The "ExecInsert" handles constraint checks but not later checks like
> ExecCheckHeapTupleVisible.
The test in ExecCheckHeapTupleVisible() seems wrong to me. It's
not immediately obvious what the proper fix is. Peter, do you have
any ideas on this?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Oct 12, 2016 at 2:50 AM, Albe Laurenz wrote:
> Kevin Grittner wrote:
>> I don't see that on development HEAD. What version are you
>> running? What is your setting for default_transaction_isolation?
>
> The subject says SERIALIZABLE, and I can see it on my
ess due to concurrent update
> =# END;
> ROLLBACK
I don't see that on development HEAD. What version are you
running? What is your setting for default_transaction_isolation?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-gen
reate table ddl_test(id int);
> ERROR: duplicate key value violates unique constraint
> "pg_type_typname_nsp_index"
> DETAIL: Key (typname, typnamespace)=(ddl_test, 2200) already exists.
> test=# commit ;
> ROLLBACK
I recommend using a transactional advisory lock to seriali
ble without warning...
> How is it possible for the WAL file to be accessed BEFORE it was
> created?
Perhaps renaming it counts as "creation" without affecting access
time.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-
LL
does not evaluate to TRUE.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ationship intact all the way through -- perhaps by
adding name_last to table_1.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
lue of 124312. Effectively
the database is complaining that it can only store one value, not a
set of values. I can only guess at what you might be intending to
ask the database to do. Can you explain what you are trying to do?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
27;)))
then
'RPG_INV'
when
((("s"."Funding_Date") is null
or ("s"."Funding_Date" <> ''))
and (("s"."Actual_Close_Date" = '
alternative
for how to go about that, although operating a row at a time you
probably won't approach the speed of statement-level set logic for
statements that affect very many rows. :-(
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
= delta.dst)
UNION ALL
SELECT after.src, delta.dst, 1 * delta."count(t)"
FROM hop2 after
JOIN "Δ(link)" delta ON (delta.src = after.dst)
) x(src, dst, "count(t)")
GROUP BY src, dst
HAVING sum("count(t
ype=pdf
The first step in using either of those techniques (counting or
DRed) is to capture a delta relation to feed into the relational
algebra used by these techniques. As a first step in that
direction I have been floating a patch to implement the
SQL-standard "transition tables" f
o zero on customer insert, and which you increment to
get values for the second key column in the contact table.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s between PSS and USS == total shared memory.) RSS has
the usual meaning.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
er
can stand behind it and feel as good as possible about
circumstances should that happen.
You might want to keep a copy of the email or memo in which you
point this out, in case anyone's memory gets foggy during such a
crisis.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enter
e even with SET TRANSACTION SERIALIZEABLE mode.
> I am specifically interested in the 3rd condition (- Writers do not
> block readers.)
Yes.
https://wiki.postgresql.org/wiki/SSI
http://vldb.org/pvldb/vol5/p1850_danrkports_vldb2012.pdf
--
Kevin Grittner
EDB: http://www.enterprisedb.com
On Mon, Aug 8, 2016 at 5:59 PM, Craig Boucher
wrote:
> Thanks Kevin for your response. I've Googled and debated natural
> vs surrogate keys and I just find surrogate keys easier to work
> with (maybe I'm just being lazy). It just seems that a
> description or name is most
s more immediate issues for
particular end users; but I expect to get back to it Real Soon Now.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
large scale, by modifying one column
of one row. That is, of course, a double-edged sword -- in
discussing design alternatives with the CPAs who were going to be
auditing financial data stored in a database, they didn't tend to
see that as nearly as much of a plus as some programmers do.
--
K
D and just returned NULL if none has yet
been assigned. I'm not sure what the best name would be for such a
function when we already have a function called txid_current()
which does something different from that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
kes a restart
after a crash less problematic and it is generally better from a
security standpoint, so you might want to look for a way to allow
it.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postg
tabase objects, that might be a hard
one to overcome, but it might be something with an easy solution in
the pg_upgrade options or server configuration.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-genera
symptoms you report are a little
thin to diagnose the actual cause.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
he parser commiters share some lights on how the documentation
> process interacts with the parser commits ?
There is no automated interaction there -- it depends on human
attention. On the other hand, try connecting to a database with
psql and typing:
\h create index
... (or any other command
t the cluster
under the new version* you can fall back to the old version. I
remember a couple times that we saw something during a pg_upgrade
--link run that we weren't expecting, and did exactly that so we
could investigate and try again later.
--
Kevin Grittner
EDB: http://www.enterprise
ng advantage of the available
features.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I can't do much about
>> the data model itself right now, I need to protect the integrity
>> of the data.
Rather than unique constraints, you could add a unique index on the
COALESCE of each column with some impossible value.
--
Kevin Grittner
EDB: http://www.enterprisedb
to the proper dir and life
is good again. Obviously, that's something that must be changed in the
automated upgrade script.
While it might be nice if the server warned of an "empty" dir for that config
value, the problem was totally mine.
Thanks so very much to each of you!
Kevi
e "runuser -l postgres -c..." line to be what
I have that works with pg_ctl, but I'm concerned that the error is an
indication that I've screwed up something important that will bite me later if
I don't figure it out now. This is on a test system, so no real data is
t I’m concerned that the error is an indication
that I’ve screwed up something important that will bite me later if I don’t
figure it out now. This is on a test system, so no real data is endangered; but
I really need to figure this out as we automate the upgrade so it can go to
real data
ze a;
vacuum analyze b;
vacuum analyze c;
select id, b1_name from v;
explain (analyze, buffers, verbose) select id, b1_name from v;
I'm seeing the unreferenced tables pruned from the plan, and a 1ms
execution time for the select from the view.
--
Kevin Grittner
EDB: http://www.enterprisedb.
important enough to you you could submit a patch or fund
development of such a feature; but since it would add at least some
small amount of planning time to every inner join just to avoid
specifying that the join is an optional one when writing the query,
it seems to me unlikely to be accepted.
--
0 width=278) (actual
time=0.006..0.006 rows=3 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Seq Scan on b b1 (cost=0.00..12.60 rows=260 width=278)
(actual time=0.002..0.003 rows=3 loops=1)
Planning time: 0.177 ms
Execution time: 0.044 ms
(8 rows)
No
id/E1VYMqi-0001P4-P4%40wrigleys.postgresql.org,
but the discussion petered out prematurely.
Thanks,
Kevin
assigned in the apparent order of
execution of the serializable transactions, I'm afraid that I don't
know of any good solution for that right now. There has been some
occasional talk of providing a way to read the AOoE, but nothing
has come of it so far.
--
Kevin Grittner
EDB: http://www
mal setup (like the above) helps in getting
good answers quickly.
>> do note, this is whats known as an 'anti-join', and these can be pretty
>> expensive on large tables.
>
> +1
*Can* be. Proper indexing can make them very reasonable.
--
Kevin Grittner
EDB: http:
On Tue, May 31, 2016 at 4:18 PM, wrote:
> ERROR: el operador no existe: character varying == character varying
> LINE 1: SELECT OLD.Peticionario == NEW.Peticionario or OLD.interlocc...
Perhaps you want the = operator?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Ente
ector ?
I very much doubt that full text search is going to be helpful here
-- perhaps trigrams with an appropriate gist or gin index could
help. Depending on table sizes and data present, picking out rows
based on the OR of scanning for a sequence of characters in a
couple character string
00:00:00+02
> -[ RECORD 7 ]---+---
> expiration_date | 2015-11-27 00:00:00+01
>
> Shouldn't all value be converted to the same timezone ?
Perhaps your local time zone ends Daylight Saving Time between
those dates, so the offset from UTC is different on those dates?
--
Kevin Gri
sparent huge pages. Yeah, be sure those are
configured to be disabled in a way that "sticks" on your OS. When
you get to version 9.4 you will notice that we support huge pages
directly. That would be expected to work without problems even
though TRANSPARENT huge pages are debilitating.
to predict exactly.
You might want to go over this page:
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
... and then read the documentation of any setting you are thinking of
adjusting.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
ther
you have actually solved the flaws in your process or have just
been lucky so far.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
in temporary files and workspace, with just the delta applied
to the table and index in permanent storage.
It's hard to guess which way will be faster for the use case you
describe -- it will probably depend on what percentage of rows
remain unchanged on each REFRESH.
--
Kevin Grittner
from people;
id | name
+--
1 | Fred
2 | Bob
(2 rows)
test=# \d
List of relations
Schema | Name | Type | Owner
++---+-----
public | people | table | kgrittn
(1 row)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compa
o the
point of developing a proposed patch. That and the fact that there
is no guarantee that the community as a whole would feel that the
feature "carried its own weight" in terms of benefit / maintenance
cost, so it might not make it in anyway.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e, with no other queries being generated during that time,
could take 23 seconds to complete? The server is running Postgres 9.4.6.
What other information do I/you need to figure out what's going on?
Thanks,
Kevin
On Thu, Apr 7, 2016 at 1:26 AM, Alexey Bashtanov
wrote:
> Hello Kevin,
&g
On Wed, Apr 13, 2016 at 5:54 PM, Kevin Grittner wrote:
> See this example, and imagine that
> the transaction generating the list of receipts for the closed
> batch is run on the standby before the transaction adding the last
> receipt commits. Or test it.
https://wiki.postgresql.
et/mediawiki/index.php/Bug_tracking_system
>
> Filed http://www.pgpool.net/mantisbt/view.php?id=191
As the entry stands at the moment, the suggestions for fixes will
allow incorrect query results. See this example, and imagine that
the transaction generating the list of receipts for the closed
transaction and issue a ROLLBACK at the
end, unfortunately our ORM
<https://kev.inburke.com/kevin/dont-use-sails-or-waterline/> does not
support transactions.
We observed that when we pushed tests to a third-party CI service, maybe 1
in 100 test runs fails with a mysterious timeout (set to 18 seco
1, 1/0);
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Mar 25, 2016 at 4:15 PM, Jernigan, Kevin wrote:
> On 3/25/16, 4:37 AM, "pgsql-general-ow...@postgresql.org on behalf of Mark
> Morgan Lloyd" markmll.pgsql-gene...@telemetry.co.uk> wrote:
>> Just because a corporate has a hundred sites cooperating for invent
On 3/25/16, 4:37 AM, "pgsql-general-ow...@postgresql.org on behalf of Mark
Morgan Lloyd" wrote:
>Jernigan, Kevin wrote:
>> On 3/22/16, 8:07 AM, "Bruce Momjian" wrote:
>
>>>
>>> HA Scaling Upgrade Add/Remove
>&
On 3/22/16, 8:07 AM, "Bruce Momjian" wrote:
>On Mon, Mar 21, 2016 at 04:46:51PM +0000, Jernigan, Kevin wrote:
>> Disk is only a single point of failure in RAC if you configure
>> non-redundant storage. In general, Oracle recommends triple mirroring
>> to protect
On 3/24/16, 3:09 PM, "Albe Laurenz" wrote:
>Jernigan, Kevin wrote:
>> Disk is only a single point of failure in RAC if you configure non-redundant
>> storage.
>> In general, Oracle recommends triple mirroring to protect against disk
>> failures,
>>
On 3/21/16, 9:10 AM, "pgsql-general-ow...@postgresql.org on behalf of Rakesh
Kumar" wrote:
>On 03/21/2016 10:57 AM, Thomas Kellerer wrote:
>
>> So - at least as far as I can tell - it's usually only used where
>> high-availability is really important, e.g. where zero-downtime is required.
>> I
ng such behavior is not one I would
consider to be mature enough for "prime time" -- although others
might feel differently.
Kevin Grittner
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t * from foo where mynum < 100;
id | mynum
+---
1 |10
2 |10
3 |10
4 |10
5 |10
(5 rows)
mydb=# update foo set mynum = 20 where id < 100;
UPDATE 5
mydb=# select * from foo;
id | mynum
+---
1 |20
2 |20
3 |20
4 |20
5 |20
(
estimate the
amount of random storage I/O needed to use an indexed plan. If you
tell it that you only have 64MB between those two types of cache,
it will assume that the index (particularly if it is deep and/or
wide) will be very expensive.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The
I do not understand why I am getting this error.
I have joined the table correctly, is this not sufficient?
forge=> select * FROM generate_series('2016-01-22', '2017-12-31', '1
day'::interval) AS day
LEFT JOIN (
select *, generate_series(c.start_time,
c.end_time, '2 wee
I am creating a small booking system, and need to generate a series of
dates, for the year, with each booking. Using generate_series I can create
the dates, and fill them with a booking date based on the lower tsrange for
the booking.
I need to extend this to also fetch ALL the dates in the tsrange
in. Problems should be resolved in
a way that minimizes the chance of escalation, recognizing that
there could be miscommunication.[2]
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
[1] https://en.wikipedia.org/wiki/Golden_Rule
[2]
http://www.khou.com/stor
So far this is what I have.. (see below).
How can I have recurring bookings for a call?
Eg: if the call_frequency is weekly, how can I see a list of dates which
this account will be called upon?
Kind regards
Kevin
CREATE TABLE call_frequency (
id SERIAL PRIMARY KEY NOT NULL
1 - 100 of 963 matches
Mail list logo
