'll help with that, even though the leading column might be
low cardinality.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
hing in particular gets faster, because there are many
performance enhancements added to a release.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, Nov 13, 2017 at 12:40 PM, Peter Geoghegan wrote:
>> Do I have to explicitly specify collation when using ORDER by on that column
>> for index and abbreviated keys to be used?
>
> Only if you didn't define the column with a per-column collation initially.
BTW, if y
specify collation when using ORDER by on that column
> for index and abbreviated keys to be used?
Only if you didn't define the column with a per-column collation initially.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
antage of abbreviated keys?
You need to use an ICU collation. It must be a per-column collation,
as you cannot currently use ICU for an entire database. (This
limitation should be removed in the next release or two.)
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsq
rruption, though.)
Of course, what I'd much prefer is a self-contained test case. But if
you can't manage that, or if reproducing the issue takes hours, then
this simpler experiment might be worthwhile.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ndex, but will that help?
> Is there a way to see what the ‘different type’ is?
> Is it caught/clean-up by vacuum analyse or some such?
Is there a lot of churn on this table? Do you either heavily update or
heavily delete rows in the table? Does vacuum tend to run on the table
rather fr
cient, and that we now continue to see the same mix
of symptoms for what is essentially the same bug.
[1]
https://postgr.es/m/CAH2-WzmtLXbs8+c19t1T=rj0kyp7vk9q8hqjulgdldvmuee...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chan
e most
important check here.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
gt; backup/source data, instead of restoring the whole table?
You might find the latest version of amcheck helpful here:
https://github.com/petergeoghegan/amcheck
It's not really written with repair in mind, since that's such a can
of worms, but it might still help you.
--
Peter Geoghegan
--
ty apt and yum repos to get packages for
the new version (both have 1.0 versions as of right now, though).
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nstead of VALUES with ON CONFLICT DO NOTHING/ON
CONFLICT DO UPDATE. They don't impose any restriction on the INSERT
statement at all, unlike MERGE, which is fussy about the use of
subqueries.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
On Mon, Oct 9, 2017 at 12:08 PM, Christophe Pettus wrote:
> Suggestions on further diagnosis?
What's the hot_standy_feedback setting? How about
max_standby_archive_delay/max_standby_streaming_delay?
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
s much CPU as the master's backend.
>
> What am I missing to reproduce the problem?
Just a guess, but do you disable autovacuum on your dev machine? (I know I do.)
It's possible that this is relevant:
https://postgr.es/m/CAB-EU3RawZx8-OzMfvswFf6z+Y7GOZf03TZ=bez+pbqx+a4...@ma
e a pattern
> related to application business processes but we are at a loss as to how
> this could happen.
You've given no details at all. What business pattern? What does the
index and table look like?
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@post
?
That's quite possible. An ON CONFLICT's UPDATE accepts a WHERE clause,
which can reference both existing and excluded tuples. That WHERE clause
can back out of the UPDATE based on whatever criteria you like.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgs
ture you describe. Subtleties like this could easily be
missed.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Jul 26, 2017 at 2:05 PM, Peter Geoghegan wrote:
> On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
>> We've added duplicate indexes and analyzing, however the new indexes are
>> still ignored unless we force using enable_seqscan=no or reduce
>> random
break down, in terms of how much each individual
index grows in size?
You say that the problem is with both indexes and tables. How much of
this is table bloat, and how much is index bloat?
Thanks
[1]
https://postgr.es/m/CAH2-Wz=sfakvmv1x9jh19ej8am8tzn9f-yecips9hrrrqss...@mail.gmail.com
--
Pet
hile? Are these unique indexes or not? Do you have a
workload with many UPDATEs?
I ask all these questions because I think it's possible that this is
explained by a regression in 9.5's handling of index bloat, described
here:
http://postgr.es/m/CAH2-Wz=sfakvmv1x9jh19ej8am8tzn9f-yecips
ent to SQL, and so wouldn't help with this general problem. Quel
wasn't successful because it was only somewhat better than SQL was at
the time.
This is a conversation that I had a few times when I worked for
Heroku, with coworkers that weren't on the database team. They asked
simil
ation in the joined-on column with
MERGE). But, MERGE would be faster for bulk loading, which is what
MERGE is good for.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, Jun 19, 2017 at 4:51 PM, Peter Geoghegan wrote:
> This would make only the first lookup for each distinct value on the
> outer side actually do an index scan on the inner side. I can imagine
> the optimization saving certain queries from consuming a lot of memory
> bandwidth
imagine
the optimization saving certain queries from consuming a lot of memory
bandwidth, as well as saving them from pinning and locking the same
buffers repeatedly.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
prefetching heap pages mattering a lot less for a
primary key index, where there is a strong preexisting correlation
between physical and logical order, while also mattering a lot more
than what I describe in other cases. I suppose that you need both.
--
Peter Geoghegan
--
Sent via pgsql-gene
lemented. Index scans will on average have a much more random
access pattern than what is typical for bitmap heap scans, making this
optimization more compelling, so hopefully someone will get around to
this.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
t; and found all tables’ id were reset to 1.
I've heard of this happening before. I never determined what the cause was.
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
f an UPDATE than it is to back out of an
INSERT. If you're really interested, search through the -hackers
archives from around April of 2015.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postg
ardinality leading attribute, so
this habit works against tuplesort. (Assuming a leading attribute of
pass-by-value type, or with abbreviated key support.)
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rmine
that it would be just fine to use the C locale, since the user isn't
entitled to assume anything about the exact sort order. There are of
course cases where this can make a huge difference.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
erspective.
What are your thoughts on the back-and-forth between myself and Tom
concerning predicate locks within heap_fetch_tuple() path last
weekend? I now think that there might be an outstanding concern about
ON CONFLICT DO NOTHING + SSI here.
--
Peter Geoghegan
--
Sent via pgsql-
27;m still not even clear on
whether you are actually arguing that they are special. (Except, of
course, the multi-value case -- that's clearly not okay.)
So, with the fix proposed by Thomas applied, will there be any
remaining false positives that are qualitatively different to existing
false p
ult.
I was under the impression that false positives of this kind are
allowed by SSI. Why focus on this false positive scenario in
particular?
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
T DO NOTHING code to avoid false positives where we can.
Do you intend to propose a patch to do that?
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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's better to fix them both at once?
--
Peter Geoghegan
--
Sent via pgsql-ge
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...
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
here is a similar consideration for DO UPDATE. I'm
slightly surprised that you're contemplating just ripping the check
out. Did I miss something?
[1] https://www.postgresql.org/message-id/57ee93c8.8080...@postgrespro.ru
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgs
is far weaker. What specifically do you say is wrong about his
> current claims, and on what facts to you base it?
I'm not the one making overarching conclusions. I'm not trying to
convince you of anything.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@
e that made that untrue in
1981, if only barely [1], but the lesson for me was to take his claims
in this area with a generous pinch of salt.
[1] https://www.cs.cmu.edu/~pavlo/static/papers/stonebraker-ic2e2014.pdf
(See his citation 11)
--
Peter Geoghegan
--
Sent via pgsql-general maili
re
complicated than it first appears, if you expect UPSERT to worry about
lock starvation, "unprincipled deadlocks" [1], and other problems like
that.
[1]
https://wiki.postgresql.org/wiki/Value_locking#.22Unprincipled_Deadlocking.22_and_value_locking
--
Peter Geoghegan
--
Se
ase replication and backup processes.
This belongs on the pgsql-jobs mailing list, not pgsql-general.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s no unique or exclusion constraint matching the ON CONFLICT
> specification
>
> If anyone knows what I'm doing wrong and how to get this to work, or knows
> that this is not possible to achieve, I'm all ears.
That should work. Are you sure you haven't spelled it "...
scheme-like syntax, and the storage model would be properly relational (eg no
> duplicate rows).
Have you heard of QUEL?
See https://en.wikipedia.org/wiki/QUEL_query_languages
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your sub
er way. Maybe ON CONFLICT DO SELECT where the select
> operates over the target row.
Seems reasonable.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, Mar 14, 2016 at 12:28 PM, Peter Devoy wrote:
> Is there a reason DO NOTHING was not developed for use with RETURNING?
I don't know what you mean. It should work fine with RETURNING.
--
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
r are their collations graven on stone tablets, unlike
> anyone else's?
See my response to Thomas.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
so that the collations simply never
go away, but if that does happen (or if you decide that the changes to
a collation matter for cultural or correctness reasons) then you can
at least detect the change and recover from it reliably.
ICU has some other really nice features, too, but that's ano
rst
version that happens to have ICU support). I don't like suggesting a
solution that I myself am unlikely to find the time to work on, but in
the long run that's the only sensible approach IMV.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@post
as carrying on, because there
is no reason to think that the locale thing can easily be rolled back.
That was my point, in fact.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
was superseded by a new version.
[1]
http://www.postgresql.org/message-id/CAEYLb_UTMgM2V_pP7qnuKZYmTYXoym-zNYVbwoU79=tup8h...@mail.gmail.com
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I think it would be really handy if temp_tablespaces were made resilient
against everything going away in the event of a hard crash.
--
Regards,
Peter Geoghegan
, based on what you say here, I
think you should actually "ORDER BY name_last, name_first".
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ordering by anyway, so you can
just not concatenate the ', ' string (so name_last || name_first), and
it will work as you expect, I believe.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ation isn't acceptable. ON CONFLICT DO UPDATE
should be preferred once 9.5 is released.
[1]
http://www.postgresql.org/docs/9.4/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgres
indexes.
[1]
http://pgeoghegan.blogspot.com/2015/01/abbreviated-keys-exploiting-locality-to.html
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
fixed in PostgreSQL 9.4, so that query texts can be of
virtually unlimited size and still be stored. Otherwise, it depends on
your track_activity_query_size setting.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscript
On Tue, Dec 9, 2014 at 5:46 PM, Peter Geoghegan
wrote:
> I'm currently trying to fix this across the board [1], but my first
> suggestion is to try enabling log_temp_files to see if external sorts
> can be correlated with these stalls.
See also:
http://www.postgresql.
esql.org/action/patch_view?id=1462
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Sep 24, 2014 at 2:01 PM, Paul Ramsey wrote:
> If I build an index on the same table using the internal quad-tree ops, and
> use their operator, I do get an index scan.
What about when enable_seqscan = off?
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list
possibly a quite complex expression. However, it's
not clear what behavior is expected here, since multiple SKUs may
appear per row. If you had a table with "products", with a jsonb
column, and one row per product, you could then usefully extract at
most one SKU per row, and tha
using 64-bit xid values is that they
require more storage than 32-bit values. There is a patch floating
around that makes it safe to not forcibly safety shutdown the server
where currently it is necessary, but it doesn't work by making xids
64-bit.
--
Regards,
Peter Geoghegan
--
S
ing opclass can support. But, why
should it be supported? That's a very fuzzy criteria to search on.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sun, Aug 24, 2014 at 7:05 PM, Huang, Suya wrote:
> It’s my test DB, the version is PostgreSQL 9.4beta2. I’m testing with nested
> hstore feature.
Really? Nested hstore only made it into that version as jsonb, which
you're clearly not using here.
--
Regards,
Peter Geoghegan
-
On Wed, Aug 20, 2014 at 1:53 PM, Larry White wrote:
> Is there anyway to index a subset of the data in a JSONB column? I'm
> thinking of something like declaring certain paths to be indexed?
Yes. See the expression index example in the jsonb documentation.
--
Regards,
Pete
erly fix the
problem. This is a problem that is well understood, and anticipated by
the Unicode consortium.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ound B-Tree indexes on text.
[1] https://wiki.postgresql.org/wiki/Todo:ICU
[2] http://userguide.icu-project.org/collation/architecture#TOC-Versioning
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
h
is the nature of these things. If it was something that came up a lot,
it would surely have been settled by standardization years ago.
If OS vendors are not going to give us a standard API for versioning,
we're hosed. I thought about suggesting that we hash a strxfrm() blob
for about 2 m
ch as statements executed within functions are
tracked.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sun, Feb 9, 2014 at 10:02 PM, Adarsh Sharma wrote:
> I need to use xlogdump to analyse my xlog files in postgresql to understand
> why there are so much xlog generation on Master.
Only PostgreSQL is supported. EDB's product is not.
--
Regards,
Peter Geoghegan
--
Sent via pg
things look like
back when the delay was passed to pg_usleep(), which was the case in
9.1.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sat, Feb 1, 2014 at 3:48 PM, Peter Geoghegan
wrote:
> What Postgres version? The WAL Writer will hibernate on Postgres 9.2+.
Of course, it will still write things out at a steady rate if they're
there to write. However, there is no reason to think you couldn't
change things in
BERNATE_FACTOR25
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
bench you are eminently
qualified to judge this. I think that in general I prefer a uniform
distribution, because most often I look to pgbench to satisfy myself
that certain types of regressions have not occurred. That's quite a
different thing to a representative workload, obviously.
--
Regard
On Wed, Nov 13, 2013 at 4:39 PM, Michael Paquier
wrote:
> CRC16 is used.
Actually, subsequently another algorithm was introduced - see commit
43e7a668499b8a69a62cc539a0fbe6983384339c .
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To m
that we define ourselves
in terms of what others do and don't do. I hope that isn't true, but
if it is I think that MySQL is much less relevant now.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
h
Now it's time to design
> something new.
Maybe this is a silly thing to say, but no more frosted glass cups,
please. They tended to quickly stain when I drank tea from them, in a
way that was particularly hard to clean. The black psql cups, on the
other hand, are generally really nice to
ion or limit to do it.?
I am not a lawyer and this isn't legal advice. That said, I have ever
reason to believe that the licensing is the most liberal practically
possible. Distributing Postgres with your proprietary application
should not be a problem.
--
Regards,
Peter Geoghegan
--
Sent
https://github.com/snaga/xlogdump
--
Regards,
Peter Geoghegan
--
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, Jun 14, 2013 at 11:55 AM, Andreas wrote:
> How can I get more memory for PG on openSUSE 12.3 ?
http://www.postgresql.org/docs/9.2/static/kernel-resources.html
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
ally, I think the version on pgfoundry is unmainted.
I'd look here instead:
https://github.com/snaga/xlogdump/commits/master
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 2 January 2013 16:55, AI Rumman wrote:
> Is there any plugin for Nagios, which sends Postgresql ERROR information
> with SQL query in mail?
It has nothing to do with Nagious, but tail_n_mail may do what you want here.
--
Peter Geoghegan http://www.2ndQuadrant.com/
Post
s to use clever tricks to get away
with only having a new row version in tables, and not in each index,
if and only if the UPDATE statement only affects non-indexed columns.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
S
ture example of
wrapping a C++ library that is liable to throw C++ exceptions within
Postgres backend code, in a sane way (that is, avoiding unwinding the
stack via longjmp() over a part of the stack where a destructor needs
to be called, which is undefined in C++).
--
Peter Geoghegan ht
general the need to do so left me with a very low opinion of pl/java
as a project.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
rmatch? I think that you
should be able to install it by installing the package
postgresql-contrib or similar.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
[1] http://en.wikipedia.org/wiki/Snapshot_isolation
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
preprocess_expression() during planning, not execution proper. All
that appears within the plan tree is a simple Const node in each case,
so in that sense the plans are identical. Again, this is a little bit
academic for the most part.
I highly recommend pretending that the rules system do
ns.
The WaitLatch() thing is purely concerned with keeping the number of
wake-ups low. As long as your database server does not idle, the logic
is effectively exactly the same as what you'll see in 9.1, where the
event loop is much simpler, and merely sleeps exactly bgwriter_delay
ms every iteratio
consider turning off
synchronous_commit. Note that this is something that you can do at the
transaction granularity, so, for example, if there are financial
transactions, they need not make this trade-off.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
7;re missing here is
the reason for PageAddItem() returning InvalidOffsetNumber. That is
usually, though not necessarily, separately available within a WARNING
log message, which you haven't included here. Could you please let us
know if there is a WARNING that you didn't include just
ghtful:
http://thoughts.j-davis.com/2009/08/02/what-is-the-deal-with-nulls/
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
know what is the problem here?
Maybe they're not valid Bengali characters? Did you do an
encoding-naive truncation at some point?
My mail client cannot display the latter few characters before the
ellipsis, but can display the first few fine.
--
Peter Geoghegan http://www.2ndQuadran
make.git;a=tree;h=refs/heads/f16;hb=f16
> It's not immediately obvious which of those might be related, but
> I think this was a bug in gmake and the fix is in there somewhere.
Agreed. Since Fedora 14 is now EOL, I'm not inclined to worry about it.
--
Peter Geoghegan http:
27;t always happen. If you can't find the commit
based on that, try the original reporter's name. We ordinarily credit
bug reporters in commit messages that fix the bug.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
tool could
automagically deduce encoding (albeit often inconclusively) in much
the same manor as modern web browsers attempt to when they have no
alternative. I don't see much demand for that though.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, T
e include
> any (human) language which you are familiar with. There will be a small icon
> with the language on your badge.
I expect to be manning the booth. I speak English.
See you there
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and
ire just that when
calculating interest, for example.
If you require exactly 4 digits of precision, it's possible to use this syntax:
NUMERIC(precision, scale)
That isn't going to affect the rounding behaviour though.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Devel
irus vendor?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
re you
> referring specifically to one of these implementations?
I refer specifically to the synchronous replication feature that was
introduced into PostgreSQL itself, in the current 9.1 release:
http://www.postgresql.org/docs/9.1/static/warm-standby.html#SYNCHRONOUS-REPLICATION
--
Peter Geog
it for a small though
critical subset of transactions, like financial transactions.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
1 - 100 of 226 matches
Mail list logo
