On Tue, Oct 25, 2016 at 08:36:22AM +0200, hubert depesz lubaczewski wrote:
> Same here. feed url is https://www.depesz.com/tag/postgresql/feed/ and
> as far as I can tell, it works OK.
Magnus is looking into the problem now. Seems to be something related to
networking in the box that hosts
On Tue, Oct 25, 2016 at 08:28:00AM +0200, Pavel Stehule wrote:
> Hi
>
> I got a email about issues with reading feed URL.
>
> I checked manually URL and it looks well. http://okbob.blogspot.com/
> feeds/posts/default
Same here. feed url is https://www.depesz.com/tag/postgresql/feed/ and
as far
On Sat, Nov 22, 2014 at 3:29 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I won't push this right away because I want to add the cross-type stuff
to the tests, to ensure I haven't bollixed anything; I ran a few quick
manual tests and everything seems to work. But if Depesz wants to test
I tried to add BRIN index on very simple table, to test it for Waiting
for blogpost, btu I can't get it to work.
I got newest git head, and ran:
$ create table t (id int8);
CREATE TABLE
(depesz@[local]:5930) 20:56:22 [depesz]
$ insert into t select generate_series(1,100);
INSERT 0 100
The minmax operator families don't include any cross-type operators. I'm
not exactly sure why not.. Alvaro?
Anyway, try select * from t where id = 1224::int8
It works that way, but it would be great to have it working with non-casted
values too.
depesz
Hi,
In September 2013, there was patch sent by Stas Kelvich (
http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com)
that adds indexable kNN searches to cube contrib module.
What is needed so that it could get committed?
Regards,
depesz
Hi,
before I'll go any further - this is only thought-experiment. I do not
plan to use such queries in real-life applications. I was just presented
with a question that I can't answer in any logical way.
There are two simple queries:
#v+
with rok2005 (miesiac,wynik) as (VALUES (1,1),(2,2)
On Wed, Dec 11, 2013 at 03:34:38PM +0530, Ashutosh Bapat wrote:
Hi deepesz,
You might want to see their EXPLAIN VERBOSE outputs. Having one of them
(2004 one) lesser number of rows, might be getting picked up as first
relation being union and thus ends up having it's rows before the second
Hi,
when working on fixing the bug related to vacuum freeze, I found out
that there is something called MultiXactId.
Searching docs showed that it is mentioned only once, in release notes
to 9.3.2:
http://www.postgresql.org/search/?u=%2Fdocs%2F9.3%2Fq=multixactid
What's more - I found that Peter
On Mon, Dec 09, 2013 at 07:59:10PM +0100, Andreas Karlsson wrote:
As you can see from Peter's message it is explained in
README.tuplock[1]. Basically it is used whenever more than one lock
is acquired on the same tuples as a reference to where the locks are
stored. It can store updated/deleted
On Tue, Jul 30, 2013 at 09:23:19AM +0100, Dean Rasheed wrote:
create table some_data (id int4 primary key, payload text);
create view first as select * from some_data where 0 = id % 2 with
local check option;
create view second as select * from first where 0 = id with local
On Tue, Jul 30, 2013 at 11:45:47AM +0100, Dean Rasheed wrote:
Quoting the manual:
LOCAL:
New rows are only checked against the conditions defined directly in
the view itself. Any conditions defined on underlying base views are
not checked (unless they also specify the CHECK OPTION).
On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
depesz,
moved to -hackers..
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
create table some_data (id int4 primary key, payload text);
create view first as select * from some_data where 0 = id % 2 with local
check
In current 9.3, I see:
$ select p.proname, p.provolatile from pg_proc p join pg_namespace n on
p.pronamespace = n.oid where n.nspname = 'pg_catalog' and p.proname ~ 'json';
proname | provolatile
---+-
json_in | s
On Mon, Apr 15, 2013 at 11:31:39AM -0400, Andrew Dunstan wrote:
Me either. It's an oversight, really. Unless there is any objection
I'll change them toot sweet. What about the existing (as of 9.2)
functions?
I don't think that 9.2 functions are that interesting, since these are
to build json
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
While I generally like the idea, please note that safe reading output
from queries is possible, with COPY, and proper IFS, like:
On Sun, Mar 04, 2012 at 12:34:22PM -0500, Tom Lane wrote:
Well, that's just an arbitrary example. The cases I remember people
complaining about in practice were the other way round: greedy
quantifier followed by non-greedy, and they were unhappy that the
non-greediness was effectively not
On Sun, Feb 26, 2012 at 03:04:28PM +0100, Pavel Stehule wrote:
Hello
I rechecked Depesz's article -
http://www.depesz.com/2011/07/01/waiting-for-9-2-not-valid-checks/
The behave of current HEAD is different than behave described in article.
alter table a validate constraint a_a_check
On Wed, Feb 01, 2012 at 10:02:14PM +0100, Dimitri Fontaine wrote:
The case for a table that is partly user data and partly extension data
is very thin, I think that if I had this need I would use inheritance
and a CHECK(user_data is true/false) constraint to filter the data.
definitely agree.
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user table would
On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
anyway - the point is that in \df date_part(, timestamp) says it's
immutable, while it is not.
Hmm, you're right. I thought we'd fixed that way back when, but
obviously
On Mon, Jan 30, 2012 at 10:35:21AM -0800, Josh Berkus wrote:
preferably I would see extract( epoch from timestamp ) to be really
immutable, i.e. (in my opinion) it should treat incoming data as UTC
- for epoch calculation.
Alternatively - perhaps epoch extraction should be moved to
On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
Any chance of getting the fix in patch format so we could test it on
this system?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
that. And that they are the only rows that, in addition to the above
conditions, contain data fields wide enough to require out-of-line
toasting.
checked lengths of the text/varchar columns in database.
there are 16 such columns in
On Tue, Sep 06, 2011 at 09:21:02PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
Worked a bit to get the ltree problem down to smallest possible,
repeatable, situation.
I looked at this again and verified that indeed, commit
On Mon, Sep 05, 2011 at 05:26:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Odd it is dying in the memory freeing at executor close --- not in the
ltree code.
Doesn't seem odd. The glibc complaint previously shown already
indicates this is a memory stomp problem.
Hi,
Worked a bit to get the ltree problem down to smallest possible, repeatable,
situation.
Initial setup:
1. PostgreSQL 8.3.11, configured with:
./configure\
--prefix=/opt/pgsql-8.3.11-int \
--disable-rpath\
--without-perl
On Thu, Sep 01, 2011 at 08:05:51AM +0200, hubert depesz lubaczewski wrote:
On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
Working with depesz, I have found the cause. The code I added to fix
pg_upgrade in 9.0.4 and earlier releases didn't handle old 8.3 servers
properly. I
On Mon, Sep 05, 2011 at 05:48:50PM +0200, hubert depesz lubaczewski wrote:
On Thu, Sep 01, 2011 at 08:05:51AM +0200, hubert depesz lubaczewski wrote:
On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
Working with depesz, I have found the cause. The code I added to fix
On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
I'm not sure if it's upgrade thing, or is it because of error in
ltree/compilation, but it looks bad.
Is there any more info I could show/gather to help debug the issue?
I am confused
On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
I'm not sure if it's upgrade thing, or is it because of error in
ltree/compilation
On Mon, Sep 05, 2011 at 04:43:47PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski
On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
Working with depesz, I have found the cause. The code I added to fix
pg_upgrade in 9.0.4 and earlier releases didn't handle old 8.3 servers
properly. I mistakenly processed toast table with the same pg_dump
query as used for
On Wed, Aug 31, 2011 at 12:16:03PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X, and HEAD that I introduced recently when
On Wed, Aug 31, 2011 at 01:23:05PM -0400, Bruce Momjian wrote:
Can you get me the 9.0.X pg_class.relfrozenxid for the toast and heap
tables involved?
Sure:
=# select oid::regclass, relfrozenxid from pg_class where relname in
('transactions', 'pg_toast_106668498');
oid
On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X, and HEAD that I introduced recently when I excluded temp
tables
On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X, and HEAD that I introduced recently when I excluded temp
tables. (The bug is not in any released version of pg_upgrade.) The
attached, applied
On Thu, Aug 25, 2011 at 04:33:07PM -0400, Bruce Momjian wrote:
The problem appears to be that the Postgres catalogs think there is a
toast table for 'actions', while the file system doesn't seem to have
such a file. I can you look in pg_class and verify that?
SELECT reltoastrelid FROM
On Thu, Aug 25, 2011 at 04:43:02PM -0400, Bruce Momjian wrote:
Please check the old cluster.
Sure:
=# SELECT reltoastrelid FROM pg_class WHERE relname = 'actions';
hi,
would it be possible to incorporate
http://www.postgres.cz/index.php/Enhanced-psql in core PostgreSQL/psql?
This patch adds lots of nice functionalities, which we could definitely
use.
Best regards,
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
I have a theory. Can you try it in what would be the failure case,
but run an explicit a CHECKPOINT on the master, wait for
pg_controldata to show that checkpoint on the slave, and (as soon as
you see that) try to trigger the
On Tue, Mar 29, 2011 at 11:20:48AM +0900, Fujii Masao wrote:
On Tue, Mar 29, 2011 at 12:11 AM, hubert depesz lubaczewski
dep...@depesz.com wrote:
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
In 9.0, recovery doesn't read a backup history file. That FATAL error
happens
On Tue, Mar 29, 2011 at 11:13:07AM +0900, Fujii Masao wrote:
Yes, it's intentional. In streaming replication, at first the master must
stream
a backup history file to the standby in order to let it know the recovery
ending
position. But streaming replication doesn't have ability to send a
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
In 9.0, recovery doesn't read a backup history file. That FATAL error happens
if recovery ends before it reads the WAL record which was generated by
pg_stop_backup(). IOW, recovery gets the recovery ending location from WAL
record
On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote:
In 9.0, recovery doesn't read a backup history file. That FATAL error happens
if recovery ends before it reads the WAL record which was generated by
pg_stop_backup(). IOW, recovery gets the recovery ending location from WAL
record
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
how come that I can use this backup to make standalone pg, and it
starts without any problem, but when I start it as sr slave, let
it run for some time, and then promote
On Mon, Mar 28, 2011 at 04:53:37PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
how come that I can use this backup to make standalone pg
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
have you seen this mail -
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
Ah, OK.
I have a theory. Can you try it in what would be the failure case
On Mon, Mar 28, 2011 at 05:43:15PM -0500, Kevin Grittner wrote:
hubert depesz lubaczewski dep...@depesz.com wrote:
have you seen this mail -
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01490.php
One more thing: Am I correct in understanding that you are trying to
do a PITR
hi,
So, I hit a strange problem with Streaming Replication, that I cannot explain.
Executive summary:
when using hot backup made on straming replication slave, sometimes
(depending on load) generated backup is created in such a way, that while it
can be brough back as standalone Pg, and it can
On Thu, Jan 20, 2011 at 02:48:59PM -0500, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
How much has that code been updated from one release to the next?
Just an FYI, I talked to depesz on IRC (please chime in if you disagree
with any of this) and he indicated that he's
On Fri, May 14, 2010 at 02:07:27PM -0500, Kenneth Marshall wrote:
Hi Peter,
All you need to do is define your own sequence with an
increment of 500. Look at:
http://www.postgresql.org/docs/8.4/static/sql-createsequence.html
This is often not enough. For example - I want standard increment
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By dynamic I mean that the field name
is a variable in the trigger context.
I've been told it's easy to do
On Sun, Jun 14, 2009 at 08:15:55AM +0200, Pavel Stehule wrote:
postgres=# select '10' ~ '[0..9]+$';
?column?
--
t
(1 row)
regexp '[0..9]+$' tests is given strings containst at the end substring
containing only characters 0, 9 and ..
and yes, it does - the last character is 0, so it
On Sun, May 17, 2009 at 01:38:35PM -0300, Dickson S. Guedes wrote:
I suggested him to use LIMIT.
interesting. I just tested (on beta1), that while limit works in this
query:
SELECT generate_series(now(), CAST('infinity'::date AS timestamp), interval '1
hour') limit 3;
i.e. it returns 3 rows
On Wed, Mar 25, 2009 at 06:08:43PM +0900, Tatsuhito Kasahara wrote:
So, I sometimes want to know what query (main cause) was done before
transaction which have been practiced for a long time.
Thoughts?
I would love to get it, but when I suggested it some time in the past
Tom shot it down as
is it going to stay that way? i find it actually worse than 8.3
behaviour:
(dep...@[local]:5840) 11:43:40 [depesz]
# \l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access privileges
--- repost to hackers as suggested by RhodiumToad ---
hi,
i tried to test new visibility map feature.
to do so i:
1. fetched postgresql sources from cvs
2. compiled
3. turned autovacuum off
4. started pg
5. ran this queries:
- CREATE TABLE test_1 (i INT4);
- CREATE TABLE test_2 (i INT4);
-
while reading documentation for pg_freespacemap contrib module i found a
small mistake - the functions are names pg_freespace and not
pg_freespacemap.
attached patch changes the sgml file with documentation.
best regards,
depesz
--
Linkedin: http://www.linkedin.com/in/depesz / blog:
On Mon, Sep 08, 2008 at 11:20:18AM -0400, Chris Browne wrote:
I've got a case where I need to reverse strings, and find that, oddly
enough, there isn't a C-based reverse() function.
A search turns up pl/pgsql and SQL implementations:
just for completenes - there is also pl/perl and c versions
On Thu, Nov 29, 2007 at 12:39:30AM -0500, Andrew Dunstan wrote:
The attached patch works for me to eliminate the errors. Please test ASAP.
tested, works for me:
#v+
# CREATE OR REPLACE FUNCTION test(TEXT) RETURNS bool language plperl as $$
return (shift =~ /[a-ząćęłńóśźżĄĆĘŁŃŚÓŹŻ0-9_-]+/i) || 0;
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
http://www.postgresql.org/docs/current/interactive/release-8-2-4.html
...
Prevent the
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
functionality.
i'm quite worried about all setting.
all operators are
On Thu, Aug 09, 2007 at 03:39:06PM +0200, Hans-Juergen Schoenig wrote:
so the idea we had to add one more column to pg_proc telling us whether
prosrc is encrypted or not. people could chose then whether to crypt codes
there or not (speed of decryption can be an issue).
should not
On 7/7/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Why is this better than using the service file?service file is not well described in manual. quick grep showed that we have PGSERVICE variable, and pg_service.conf.sample, which doesn't even include all possible parameter names.
and - comments in
hisome time ago i was told on postgresql-general about existence of hstore package for postgresql.as i understand it is being developed by the same guys that are behind tsearch2, gin and (at least) recent changes in gist.
would it be possible to include this software in main postgresql tarball? it
On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
forgot to mention that this is 8.1.3 compiled from source. Further
testing shows that not only CREATE INDEX has some issue with large
maintenance_work_mem settings :
what does it show:
cat /proc/sys/kernel/shmmax
?
depesz
hii was really more than happy when i saw table partitioning in release info for 8.1.then i tried to use it, and hit some serious problem (described on pgsql-general).basically the question is - is anybody at the moment working on improving partitioning capabilities? like improving queries to
On 12/6/05, Michael Fuhr [EMAIL PROTECTED] wrote:
How about:CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$use Socket;return unpack(N, inet_aton($_[0]));$$ LANGUAGE plperlu IMMUTABLE STRICT;
you can use this one:
... AS $$
return unpack(N, pack(C4, split(/\./, $_[0])));
$$ language plperl
70 matches
Mail list logo
