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 a
On Wed, May 27, 2015 at 01:55:24PM +0300, Jordan Gigov wrote:
> Updating a materialized view in my case. It should only update when 2-3 of
> our 30+ tables get new data, which for those is kind of rare. Not having
> such a trigger means I will have to call it in each usage in the code and
> hope fu
On Tue, May 12, 2015 at 09:25:50AM +0200, Pavel Stehule wrote:
> create type scheduled_time as (second int[], minute int[], hour int[], dow
> int[], month int[]);
> (,"{1,10,20,30,40,50}",,,) .. run every 10 minutes.
> (,"{5}",,,) .. run once per hour
> Comments, notices?
First, please note that
On Sat, Nov 22, 2014 at 3:29 AM, Alvaro Herrera
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
> the behavior, be my
> 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
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
(
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
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,
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 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/dele
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%2F&q=multixactid
What's more - I found that Pet
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 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 = i
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
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
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
json_out
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_
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
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
On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski 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
On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski 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=23998fe99c1220ba3a9eefe
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 writes:
> > > Worked a bit to get the ltree problem down to smallest possible,
> > > repeatable, situation.
> >
> > I looked at this
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 Mon, Sep 05, 2011 at 05:26:00PM -0400, Tom Lane wrote:
> Bruce Momjian 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.
>
> --enabl
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
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
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/gath
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 c
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 ha
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 p
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 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.
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
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
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, app
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';
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
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 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
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
> 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 e
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 Mon, Mar 28, 2011 at 05:43:15PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski 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 try
On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski 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 wo
On Mon, Mar 28, 2011 at 04:53:37PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski wrote:
> > On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
> >> hubert depesz lubaczewski wrote:
> >>
> >>> how come that I can use this backup to
On Mon, Mar 28, 2011 at 04:24:23PM -0500, Kevin Grittner wrote:
> hubert depesz lubaczewski 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 t
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
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 b
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
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 incr
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
> 2010/3/9 strk :
> > 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 wi
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 i
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 in
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: http
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 version
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 statisti
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 a
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 no
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? i
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 parti
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 plp
y to insert something i got:
ERROR: newses_seq.nextval: bad magic ()
i know it's my fault. but what should i look for to trace the problem, and kill
the bug?
i would really appreciate quick answers or suggestions (i'm running out of time
...)
depesz
--
hubert
73 matches
Mail list logo
