marking indexes containing the altered type invalid
on a ROLLBACK would be preferable to the current situation.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
a value was
added, and the transaction was rolled back? For the 90% use case, that would
be acceptable, I would expect.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
, then
populating a dimension table for it) would have to be done as two migrations
rather than one, but that is much more doable in most tools than having a
migration run without a transaction at all.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-h
> On Sep 25, 2017, at 07:55, Andrew Dunstan
> wrote:
> Let's ask a couple of users who I think are or have been actually
> hurting on this point. Christophe and David, any opinions?
Since about 90% of what I encounter in this area are automatically-generated
migrations, having a clear set of (
icular, does not have stable field
order.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
: if we were starting over, we wouldn't start by
creating our own proprietary hierarchical type and then making the hierarchical
type everyone else uses depend on it. hstore exists because json didn't. But
json does now, and we shouldn't create a jsonb dependency on h
|| jsonb (and likely the other
combinatorics of json and jsonb), along with the appropriate GIN and GiST
interfaces for jsonb. Why would that not work?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On Feb 27, 2014, at 8:31 PM, Peter Geoghegan wrote:
> On Thu, Feb 27, 2014 at 8:23 PM, Christophe Pettus wrote:
>> Surely, the answer is to define a jsonb || jsonb (and likely the other
>> combinatorics of json and jsonb), along with the appropriate GIN and GiST
>> inter
On Feb 27, 2014, at 9:12 PM, Craig Ringer wrote:
> On 02/28/2014 12:43 PM, Christophe Pettus wrote:
>> My proposal is that we break the dependencies of jsonb (at least, at the
>> user-visible level) on hstore2, thus allowing it in core successfully. jsonb
>> || jsonb r
t understand the resistance to putting jsonb in core.
There are missing operators, yes; that's a very straight-forward hole to plug.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
controversy" is just a way of saying there are people who don't like the
idea, and I get that. But I don't see the basis for the dislike.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ntirely. I am
> attempting to build consensus by reaching a compromise that weighs
> everyone's concerns.
The thing I still haven't heard is why jsonb in core is a bad idea, except that
it is too much code. Is that the objection?
--
-- Christophe Pettus
x...@thebui
ving the implicit cast from jsonb to hstore, and the remaining operators
(if they don't make it into this patch) can be added over time.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ere they don't get to pick what packages are
installed on their server (RDS, for example). Telling them that something is
in -contrib can very well be telling them "You can't have it" in those cases.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers m
ave jsonb even if we don't initially have indexing operations
for it.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 28, 2014, at 1:34 PM, Peter Geoghegan wrote:
> Amazon RDS Postgres has hstore.
Just observing that putting something in -contrib does not mean every
installation can automatically adopt it.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pg
To put it mildly, there's no consensus on that point; indeed, I
think there's consensus that's a non-starter.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Is it reasonable to note in the documentation that ereport does not return if
the error severity is greater than or equal to ERROR?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Aug 19, 2013, at 11:28 PM, Heikki Linnakangas wrote:
> On 19.08.2013 23:40, Christophe Pettus wrote:
>> Is it reasonable to note in the documentation that ereport does not return
>> if the error severity is greater than or equal to ERROR?
>
> Yeah, it probably would be
m
archive",""
All of these are on _vm relations. The recovery completed successfully and the
secondary connected to the primary without issue, so: Are these messages
something to be concerned over?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hacke
e for it, part of which is the acceptance of the
Django license and copyright notice. (I don't have my copy right in front of
me, but I don't think it's a full-on assignment of copyright.)
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-ha
Where in the optimizer code does PostgreSQL decide which of several
possibly-matching partial indexes to use?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Dec 7, 2010, at 2:43 PM, Josh Berkus wrote:
> Because nobody sane uses OSX on the server?
The XServe running 10.5 server and 9.0.1 at the other end of the office takes
your remark personally. :)
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pg
tore == dict standardization. It also suffers from the
problem that it needs to sniff the hstore OID, which is somewhat annoying,
especially in a web environment where the sniff has to happen repeatedly.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> isinstance(10,int)
True
>>> isinstance(1e10,int)
False
--
-- C
ror like, "Object does not support requested
operation." Thanks, computer program: "Swerved off road, hit tree" is about as
useful.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t's "maximum logging").
If this sounds like something worthwhile in general, I can package it up as a
proper patch.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
n that file,
or the 943470*2 = 1886940th bit. So, (counting from the MSB being 0), it's the
4th and 5th bit of byte offset 235867 in that file.
Is that correct?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
se was done via rsync.
P3 and S3 are still operational.
No errors in the log files on either system.
--
Obviously, we're very concerned that a bug was introduced in the latest minor
release. We're happy to gather data as required to assist in diagnosing this.
--
-- Christophe Pettu
On Nov 18, 2013, at 10:58 AM, Christophe Pettus wrote:
> As a note, P1 was created from another system (let's call it P0) using just
> WAL shipping (no streaming replication), and no data corruption was observed.
As another data point, P0 was running 9.0.13, rather
eSQL on S2.
5. PostgreSQL recovers normally (pulling a small number of WAL segments from
WAL-E), and eventually connects to P2.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
ary conninfo?
Correct.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
elsewhere.
2. P1 never had hot_standby = 'on', as it was never intended to be a hot
stand_by.
3. S1 did have hot_standby = 'on.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
On Nov 18, 2013, at 11:47 AM, Andres Freund wrote:
> Without deleting any data, including pg_xlog/, backup.label, anything?
One more correction: After rsync finished and the pg_base_backup() was issued,
the contents of pg_xlog/ on S1 were deleted.
--
-- Christophe Pettus
x...@thebuild.
On Nov 18, 2013, at 12:00 PM, Christophe Pettus wrote:
> One more correction: After rsync finished and the pg_base_backup() was
> issued, the contents of pg_xlog/ on S1 were deleted.
pg_stop_backup(), sorry.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers m
OLTP-style workload. The P1/P2 client
has a very high level of writes; the P3 more read-heavy, but still a fair
number of writes.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
raining & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hack
On Nov 18, 2013, at 2:26 PM, Andres Freund wrote:
> Trying to reproduce the issue with and without hot_standby=on would be
> very helpful, but I guess that's time consuming?
I've been working on it, but I haven't gotten it to fail yet. I'll keep at it.
--
On Nov 19, 2013, at 6:59 AM, Andres Freund wrote:
> Yes. There's less expensive ways to do it, but those seem to complicated
> to suggest.
If this is something that could be built into to a tool, acknowledging the
complexity, I'd be happy to see about building it.
--
-- C
in right now is that we have an unknown number
of silently corrupt secondaries out there which will only be discovered when
someone promotes them to being a primary (possibly because the current primary
died without a backup), I'd say that this is something pretty urgent.
--
-- Christoph
se. What concerns me more is that we don't seem to have a
framework to put in a regression test on the bug you just found (and thank you
for finding it so quickly!).
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Nov 19, 2013, at 10:51 AM, Andres Freund wrote:
> You seem to imply that I/we should do that work?
No, just that it be done. Of course, the more support from the professional PG
community that is given to it, the better.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pg
Hi, Andres,
>From my understanding, the problem only occurs over streaming replication; if
>the secondary was never a hot standby, and only used the archived WAL
>segments, that would be safe. Is that correct?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hacker
ear, any secondary running the affected versions which
is started with hot_standby=on could potentially be corrupted even if it never
connects to a primary?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
buntu SMP Thu
Oct 24 16:28:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux.
Generally, there's no core file (which is currently enable), as the postmaster
just normally exits the backend.
Diagnosis suggestions?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers ma
krb5
-DLINUX_OOM_ADJ=0 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g
CFLAGS_SL = -fpic
LDFLAGS = -L../../../src/common -Wl,-Bsymbolic-fu
rrent? Standby? ...
The workload is not very highly concurrent; actually quite lightly loaded.
There are a very large number (442,000) of user tables. No standby attached.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
o obvious explanation how this could
> happen.
The server was running with shared_buffers=100GB, but the problem has
reoccurred now with shared_buffers=16GB.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
9c742960 in PostgresMain ()
#20 0x7f699c6ff765 in PostmasterMain ()
#21 0x7f699c53bea2 in main ()
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ld/../src/backend/postmaster/postmaster.c:1258
#30 0x00007f699c53bea2 in main (argc=5, argv=0x7f699dd3c1a0)
at /tmp/buildd/postgresql-9.3-9.3.2/build/../src/backend/main/main.c:196
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
./src/backend/postmaster/postmaster.c:1589
#31 PostmasterMain (argc=, argv=)
at
/tmp/buildd/postgresql-9.3-9.3.2/build/../src/backend/postmaster/postmaster.c:1258
#32 0x7fa041b36ea2 in main (argc=5, argv=0x7fa0425e91a0)
at /tmp/buildd/postgresql-9.3-9.3.2/build/../src/backend/main/m
ltiple machines,
so it's unlikely to be hardware) is that there are a relatively large number of
relations (like, 440,000+) distributed over many schemas. Is there anything
that pins a buffer that is O(N) to the number of relations?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pg
On Dec 12, 2013, at 6:15 PM, Tom Lane wrote:
> Are you possibly using any nonstandard extensions?
No, totally stock PostgreSQL.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
0.00 0.00 0.00
dm-2 0.00 0.00 11.003.00 0.22 0.1249.14
0.000.000.000.00 0.00 0.00
sdd 0.00 0.000.000.00 0.00 0.00 0.00
0.000.000.000.00 0.00 0.00
--
-- Christophe Pettus
x...@
meout
-------
0
(1 row)
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the query, rather than specifically related to the
spinlock issue. What this does reveal is that all the spinlock issues have
been on long-running queries, for what it is worth.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
xperiencing this.)
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
cilities like statement_timeout or lock_timeout that cancel a query
asynchronously. I assume pg_cancel_backend() would apply as well.
We've only seen it on one client, and that client had a *lot* (thousands on
thousands) of statement_timeout cancellations.
--
-- Christophe Pettus
On Dec 13, 2013, at 8:52 AM, Tom Lane wrote:
> Please apply commit 478af9b79770da43a2d89fcc5872d09a2d8731f8 and see
> if that doesn't fix it for you.
It appears to fix it. Thanks!
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pg
QCkFy_55kk_8XWcJPs7wsgVWf8vn4=jxe6v4r7h...@mail.gmail.com
Let me know if there's any further information I can provide.
Best,
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Dec 9, 2016, at 22:52, Keith Fiske wrote:
> On Fri, Dec 9, 2016 at 10:01 PM, Robert Haas wrote:
>> One thing that's tricky/annoying about this is that if you have a
>> DEFAULT partition and then add a partition, you have to scan the
>> DEFAULT partition for data that should be moved to the
else?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
can see making that
work is if we specify a scale for timestamptz, and that strikes me as
a big change to its semantics.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
On Oct 16, 2009, at 10:04 AM, decibel wrote:
Out of curiosity, did you look at doing hints as comments in a query?
I don't think that a contrib module could change the grammar.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
spaces.
Thanks in advance for any comments.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote:
Hmmm, hashtext() returns int32. ,
Can you reduce the collision issue if we had hashtext64()?
That would certainly reduce the chance of a collison considerably,
assuming the right algorithm.
--
-- Christophe Pettus
x...@thebuild.com
't a terrible solution, assuming collisions don't become an
issue; a well-designed hashtext64() would help a lot.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
working with other people, because of temperament or work
style, but I'm sure some are. Might this help?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
68 matches
Mail list logo
