Daniel Farina wrote:
> On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda wrote:
>> On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane wrote:
>>> The real difficulty is that there may be more than one storable value
>>> that corresponds to "1.23456" to six decimal digits. To be certain that
>>> we can reprod
On 3 March 2013 23:39, Tom Lane wrote:
> Nicolas Barbier writes:
>> 2013/3/3 Kevin Grittner :
>>> Nicolas Barbier wrote:
I think that automatically using materialized views even when the
query doesn’t mention them directly, is akin to automatically
using indexes without having to
On 5 March 2013 01:04, Daniel Farina wrote:
> Corruption has easily occupied more than one person-month of time last
> year for us. This year to date I've burned two weeks, although
> admittedly this was probably the result of statistical clustering.
> Other colleagues of mine have probably put
Hello, I could cause the behavior and might understand the cause.
The head of origin/REL9_2_STABLE shows the behavior I metioned in
the last message when using the shell script attached. 9.3dev
runs as expected.
In XLogPageRead, when RecPtr goes beyond the last page, the
current xlog file is rele
On 04.03.2013 09:11, Simon Riggs wrote:
On 3 March 2013 18:24, Greg Smith wrote:
The 16-bit checksum feature seems functional, with two sources of overhead.
There's some CPU time burned to compute checksums when pages enter the
system. And there's extra overhead for WAL logging hint bits. I'
Hi,
Have you benchmarked the toastrelidx removal stuff in any way? If not,
thats fine, but if yes I'd be interested.
On 2013-03-04 22:33:53 +0900, Michael Paquier wrote:
> --- a/src/backend/access/heap/tuptoaster.c
> +++ b/src/backend/access/heap/tuptoaster.c
> @@ -1238,7 +1238,7 @@ toast_save_da
Hello,
> > I think that the only other behavioural glitch I spotted was that it
> > fails to catch one overflow case, which should generate an "out of
> > ranger" error:
> >
> > select format('|%*s|', -2147483648, 'foo');
> > Result: |foo|
> >
> > because -(-2147483648) = 0 in signed 32-bit integ
Sorry, I sent wrong script.
> The head of origin/REL9_2_STABLE shows the behavior I metioned in
> the last message when using the shell script attached. 9.3dev
> runs as expected.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
#! /bin/sh
pgpath="$HOME/bin/pgsql_924b"
echo $PATH |
Hi,
Horiguch's patch does not seem to record minRecoveryPoint in ReadRecord();
Attempt patch records minRecoveryPoint.
[crash recovery -> record minRecoveryPoint in control file -> archive recovery]
I think that this is an original intention of Heikki's patch.
I also found a bug in latest 9.2_st
Simon Riggs wrote:
> On 3 March 2013 23:39, Tom Lane wrote:
>> Nicolas Barbier writes:
>>> 2013/3/3 Kevin Grittner :
Nicolas Barbier wrote:
> I think that automatically using materialized views even when
> the query doesn’t mention them directly, is akin to
> automatically usin
I'm getting an assertion failure in HEAD with materialized views, see
below for backtrace.
To reproduce, just run make installcheck, dump the regression database
and then restore it, the server crashes during restore.
(gdb) bt
#0 0x7f283a366425 in raise () from /lib/x86_64-linux-gnu/libc.so.
On Tue, Mar 5, 2013 at 7:36 AM, Kevin Grittner wrote:
> Fujii Masao wrote:
>
>> When I accessed the materialized view in the standby server,
>
>> I got the following ERROR message. Looks odd to me. Is this a bug?
>>
>>ERROR: materialized view "hogeview" has not been populated
>>HINT: Us
On Mon, Mar 4, 2013 at 11:13 AM, Alvaro Herrera
wrote:
> Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need
> to fire an event trigger for the dropped column? Right now we don't,
> ISTM we should. And if we want that, then the above set of three
> properties doesn't cut it.
On Mon, Mar 4, 2013 at 4:59 PM, Alvaro Herrera wrote:
> Alvaro Herrera escribió:
>
>> I think this is mostly ready to go in. I'll look at your docs, and
>> unless there are more objections will commit later or early tomorrow.
>
> Actually it still needs a bit more work: the error messages in
> pg
I spent some more time on this, and came up with the attached patch. It
includes the changes I posted earlier, to use indexes instead of
pointers in the hash table. In addition, it makes the hash table size
variable, depending on the length of the input. This further reduces the
startup cost on
On Sun, Mar 3, 2013 at 5:32 PM, Tom Lane wrote:
> Maybe this is acceptable collateral damage. I don't know. But we
> definitely stand a chance of breaking applications if we change
> pgstatindex like this. It might be better to invent a differently-named
> function to replace pgstatindex.
If t
2013/3/5 Kyotaro HORIGUCHI :
> Hello,
>
>> > I think that the only other behavioural glitch I spotted was that it
>> > fails to catch one overflow case, which should generate an "out of
>> > ranger" error:
>> >
>> > select format('|%*s|', -2147483648, 'foo');
>> > Result: |foo|
>> >
>> > because -(
Daniel Farina wrote:
> This kind of change may have many practical problems that may
> make it un-pragmatic to alter at this time (considering the
> workaround is to set the extra float digits), but I can't quite
> grasp the rationale for "well, the only program that cares about
> the most precis
On Mon, Mar 4, 2013 at 11:50 PM, Jeff Janes wrote:
> Is that true of all commitfests, or only the last one in a cycle? If the
> former, I think the existence of the "waiting on author" category belies
> this point.
The original point of "Waiting on Author" was that a patch might need
minor adjus
Fujii Masao wrote:
> And I found another problem. When I ran the following SQLs in the
> master, PANIC error occurred in the standby.
>
> CREATE TABLE hoge (i int);
> INSERT INTO hoge VALUES (generate_series(1,100));
> CREATE MATERIALIZED VIEW hogeview AS SELECT * FROM hoge;
> VAC
Joachim Wieland wrote:
> I'm getting an assertion failure in HEAD with materialized views, see
> below for backtrace.
>
> To reproduce, just run make installcheck, dump the regression database
> and then restore it, the server crashes during restore.
> #2 0x00888429 in ExceptionalCondit
On 5 March 2013 13:46, Pavel Stehule wrote:
> 2013/3/5 Kyotaro HORIGUCHI :
>> Hello,
>>
>>> > I think that the only other behavioural glitch I spotted was that it
>>> > fails to catch one overflow case, which should generate an "out of
>>> > ranger" error:
>>> >
>>> > select format('|%*s|', -21474
On Tue, Mar 5, 2013 at 10:35 PM, Michael Paquier
wrote:
> Thanks for the review. All your comments are addressed and updated patches
> are attached.
I got the compile warnings:
tuptoaster.c:1539: warning: format '%s' expects type 'char *', but
argument 3 has type 'Oid'
tuptoaster.c:1539: warning:
On 05.03.2013 15:59, Kevin Grittner wrote:
Daniel Farina wrote:
This kind of change may have many practical problems that may
make it un-pragmatic to alter at this time (considering the
workaround is to set the extra float digits), but I can't quite
grasp the rationale for "well, the only prog
On 5 March 2013 12:15, Kevin Grittner wrote:
> I don't think I disagree with any of what Simon says other than his
> feelings about the planning cost. Imagine that there are ten MVs
> that might apply to a complex query, but some of them are mutually
> exclusive, so there are a large number of p
On 4 March 2013 18:59, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus wrote:
>>> Except that the implication of "waiting on author" is that, if there's
>>> no updates in a couple weeks, we bounce it. And the author doesn't
>>> necessarily control a bikeshed
2013/3/5 Dean Rasheed :
> On 5 March 2013 13:46, Pavel Stehule wrote:
>> 2013/3/5 Kyotaro HORIGUCHI :
>>> Hello,
>>>
> I think that the only other behavioural glitch I spotted was that it
> fails to catch one overflow case, which should generate an "out of
> ranger" error:
>
>>
Kyotaro HORIGUCHI escribió:
> Umm. sorry,
>
> > If you have no problem with this, I'll send this to committer.
>
> I just found that this patch already has a revewer. I've seen
> only Status field in patch list..
Patches can be reviewed by more than one people. It's particularly
useful if they
Robert Haas escribió:
> On Mon, Mar 4, 2013 at 4:59 PM, Alvaro Herrera
> wrote:
> > Alvaro Herrera escribió:
> >
> >> I think this is mostly ready to go in. I'll look at your docs, and
> >> unless there are more objections will commit later or early tomorrow.
> >
> > Actually it still needs a bi
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz wrote:
> I don't think that it is about looking nice.
> C doesn't promise you more than FLT_DIG or DBL_DIG digits of
> precision, so PostgreSQL cannot either.
>
> If you allow more, that would mean that if you store the same
> number on different platf
On 2013-03-05 22:35:16 +0900, Michael Paquier wrote:
> Thanks for the review. All your comments are addressed and updated patches
> are attached.
> Please see below for the details, and if you find anything else just let me
> know.
>
> On Tue, Mar 5, 2013 at 6:27 PM, Andres Freund wrote:
>
> > Ha
> "HL" == Heikki Linnakangas writes:
HL> It would be nice to have a base-2 text format to represent floats.
HL> It wouldn't be as human-friendly as base-10, but it could be used
HL> when you don't want to lose precision. pg_dump in particular.
hexidecimal notation for floats exists. The pri
> Robert Haas escribió:
> > Or at least move the save/restore logic into something inside the
> > deletion machinery itself so that new callers don't have to worry
> > about it?
I don't think that works well; precisely the point of the
initialize/finalize pair of functions is to bracket the drop
Thank you for the review.
On Tue, 2013-03-05 at 11:35 +0200, Heikki Linnakangas wrote:
> If you enable checksums, the free space map never gets updated in a
> standby. It will slowly drift to be completely out of sync with reality,
> which could lead to significant slowdown and bloat after fail
Maciek Sakrejda writes:
> Thank you: I think this is what I was missing, and what wasn't clear
> from the proposed doc patch. But then how can pg_dump assume that it's
> always safe to set extra_float_digits = 3?
It's been proven (don't have a link handy, but the paper is at least
a dozen years o
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane wrote:
>> Why the discrepancy between
>> default behavior and what pg_dump gets?
>
> Basically, the default behavior is tuned to the expectations of people
> who think that what they put in is what they should get back, ie we
> don't want the system doing
Maciek Sakrejda writes:
> On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane wrote:
>> Basically, the default behavior is tuned to the expectations of people
>> who think that what they put in is what they should get back, ie we
>> don't want the system doing this by default:
>>
>> regression=# set extra
On 13-03-03 08:13 PM, Josh Berkus wrote:
This (creating the extensions) works fine for me on a Ubuntu 10.x system
Now if only we can work out the combinatorics issue ...
The plpython2u extensions worked fine but I haven't been able to get
this to work with plpython3u (python 3.1).
crea
This conversation has moved beyond my ability to be useful but I want to remind
everyone of my original issues in case it helps you improve the docs:
1) Data shown in psql did not match data retrieved by JDBC. I had to debug
pretty deep into the JDBC code to confirm that a value I was staring at
> Peter mentioned in the submission that the unit tests don't pass with
> python3, it doesn't work for meoutside the tests either.
Also, note that the feature is the concept of Transforms, not the
individual transforms which Peter provides. The idea is to enable a new
kind of extension.
--
Jo
Simon, Kevin, all:
Actually, there was already an attempt at automated MV query planning as
a prior university project. We could mine that for ideas.
Hmmm. I thought it was on pgfoundry, but it's not. Does anyone have
access to ACM databases etc. so they could search for this?
--
Josh Berku
Robert Haas writes:
> On Thu, Feb 28, 2013 at 3:03 PM, Tom Lane wrote:
>> Whichever way we go, the resulting patch is likely to be too large and
>> invasive for me to feel terribly comfortable about back-patching it into
>> 9.2. AFAICT this issue only arises for indexquals extracted out of
>> la
Dmitry Koterov wrote:
> LOG: server process (PID 18705) was terminated by signal 7: Bus error
So far I have only heard of this sort of error when PostgreSQL is
running in a virtual machine and the VM software is buggy. If you
are not running in a VM, my next two suspects would be
hardware/BIOS
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner wrote:
> I don't think I disagree with any of what Simon says other than his
> feelings about the planning cost. Imagine that there are ten MVs
> that might apply to a complex query, but some of them are mutually
> exclusive, so there are a large num
Josh Berkus wrote:
There is no shortage of literature on the topic, although any
papers from the ACM could certainly be of interest due to the
general high quality of papers published there. Adding anything
like this to 9.3 is clearly out of the question, though, so I
really don't want to spend
Alvaro Herrera escribió:
> Hmm, maybe I should be considering a pair of macros instead --
> UTILITY_START_DROP and UTILITY_END_DROP. I'll give this a try. Other
> ideas are welcome.
This seems to work. See attached; I like the result because there's no
clutter and it supports all three cases w
Robert Haas wrote:
> All that having been said, it's hard for me to imagine that
> anyone really cares about any of this until we have an
> incremental update feature, which right now we don't.
These are actually independent of one another, as long as we nail
down how we're determining "freshnes
2013/3/5 Robert Haas :
> All that having been said, it's hard for me to imagine that anyone
> really cares about any of this until we have an incremental update
> feature, which right now we don't. Actually, I'm betting that's going
> to be significantly harder than automatic-query-rewrite, when
Robert Haas writes:
> On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner wrote:
>> I don't think I disagree with any of what Simon says other than his
>> feelings about the planning cost.
> I'm not sure I agree. Suppose you have a query like SELECT * FROM a
> INNER JOIN b ON a.x = b.x INNER JOIN c
2013/3/5 Kevin Grittner :
> Exactly. I predict that we will eventually have some special sort
> of trigger for maintaining MVs based on base table changes to
> handle the ones that are just too expensive (in developer time or
> run time) to fully automate. But there is a lot of low-hanging
> fru
Nicolas Barbier wrote:
> PS. Sorry for having fired off this discussion that obviously
> doesn’t really relate to the current patch.
I know it's hard to resist. While I think there will be a number
of people for whom the current patch will be a convenience and will
therefore use it, it is hard
On 3/3/13 6:14 PM, Josh Berkus wrote:
> Currently Peter is punting (as is proper in a new patch) by having a
> separate extension for each combination (hstore/plperl, hstore/plpython,
> ltree/plpython, etc.). This is obviously not a maintainable approach in
> the long run.
There is also a {Perl,
Peter,
> There is also a {Perl, Python, Ruby, etc.} binding for {libpq, libmysql,
> libpng, libyaml, libssl, libgmp, etc.}, each as a separately
> downloadable and buildable package. I don't think anyone has ever
> seriously considered a system by which if, say, you have Python and
> libyaml inst
On 03/05/2013 01:09 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>
> There is no shortage of literature on the topic, although any
> papers from the ACM could certainly be of interest due to the
> general high quality of papers published there. Adding anything
> like this to 9.3 is clearly out
Okay, I added a couple of lines to skip reporting dropped temp schemas,
and to skip any objects belonging to any temp schema (not just my own,
note). Not posting a new version because the change is pretty trivial.
Now, one last thing that comes up is what about objects that don't have
straight na
Peter,
I'm still getting intermittent linking failures:
postgres=# drop extension plperl cascade;
NOTICE: drop cascades to extension hstore_plperl
DROP EXTENSION
postgres=# create extension plperl;
CREATE EXTENSION
postgres=# create extension hstore_plperl;
ERROR: could not load library
"/home
> postgres=# create extension plperl;
> CREATE EXTENSION
> postgres=# create extension hstore_plperl;
> ERROR: could not load library
> "/home/josh/pg93/lib/postgresql/hstore_plperl.so":
> /home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
> hstoreUniquePairs
> STATEMENT: create
On 03/05/2013 02:52 PM, Josh Berkus wrote:
plperlh=# \c postgres
You are now connected to database "postgres" as user "josh".
postgres=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl
> What happens if you set your LD_LIBRARY_PATH to reflect each
> installation before you start the database?
No change, at least not setting it to $PGHOME/lib.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Tue, Mar 5, 2013 at 11:22 PM, Fujii Masao wrote:
> On Tue, Mar 5, 2013 at 10:35 PM, Michael Paquier
> wrote:
> > Thanks for the review. All your comments are addressed and updated
> patches
> > are attached.
>
> I got the compile warnings:
> tuptoaster.c:1539: warning: format '%s' expects typ
On Tue, Mar 5, 2013 at 9:11 AM, Kevin Grittner wrote:
> Will investigate.
> You don't have default_with_oids = on, do you?
No, this was a default install with a default postgresql.conf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such a thing. (Oracle has
a "rowid" that acts
Tom,
> One of the core problems for a writable-foreign-tables feature is how
> to identify a previously-fetched row for UPDATE or DELETE actions.
> In an ordinary Postgres table, we use the ctid system column for that,
> but a remote table doesn't necessarily have such a thing. (Oracle has
> a "r
On Wed, Mar 6, 2013 at 6:00 AM, Tom Lane wrote:
> One of the core problems for a writable-foreign-tables feature is how
> to identify a previously-fetched row for UPDATE or DELETE actions.
> In an ordinary Postgres table, we use the ctid system column for that,
> but a remote table doesn't necessa
Hey
I want to work towards the follwing feature in TODO list:
Prevent index uniqueness checks when UPDATE does not modify the
columnUniqueness
(index) checks are done when updating a column even if the column is not
modified by the UPDATE. However, HOT already short-circuits this in common
cases, s
On Tue, Mar 5, 2013 at 3:04 PM, Kevin Grittner wrote:
> Dmitry Koterov wrote:
>
>> LOG: server process (PID 18705) was terminated by signal 7: Bus error
>
> So far I have only heard of this sort of error when PostgreSQL is
> running in a virtual machine and the VM software is buggy. If you
> ar
> Kevin Grittner wrote:
>
>> REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
>
> Given the short time, I left out the "[, ...]". If people think
> that is important to get into this release, a follow-on patch might
> be possible.
>
>> Barring objections, I will use the above and push t
Hmm..
> Horiguch's patch does not seem to record minRecoveryPoint in
> ReadRecord();
> Attempt patch records minRecoveryPoint.
> [crash recovery -> record minRecoveryPoint in control file -> archive
> recovery]
> I think that this is an original intention of Heikki's patch.
It could be. Before th
On Tue, Mar 5, 2013 at 3:44 PM, Tom Lane wrote:
> Well, the point is not so much about whether it's an improvement as that
> 9.2's current behavior is a regression from 9.1 and earlier. People may
> not like changes in minor releases, but they don't like regressions
> either.
That's true, but I'
On Sun, Mar 3, 2013 at 9:25 PM, Greg Smith wrote:
> -Allow a "pg_ctl standby" and "pg_ctl recover" command that work similarly
> to "promote". This should slim down the work needed for the first
> replication setup people do.
> -Make it obvious when people try to use recovery.conf that it's not
>
On Mon, 2013-01-14 at 06:37 -0500, Peter Eisentraut wrote:
> Here is a patch to add an option -I/--idempotent to pg_ctl, the result
> of which is that pg_ctl doesn't error on start or stop if the server is
> already running or already stopped.
So apparently, pg_upgrade needs the existing behavior,
Alvaro Herrera escribió:
> Now, one last thing that comes up is what about objects that don't have
> straight names (such as pg_amop, pg_amproc, pg_default_acl etc etc), the
> only thing you get is a catalog OID and an object OID ... but they are
> pretty useless because by the time you get to the
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee wrote:
> +1 for adding a new system attribute. We did something similar in
> Postgres-XC, though problem there was much simpler because we always
> knew that the remote FDW is a Postgres instance running the same
> version. So we added a new system c
Robert Haas writes:
> On Tue, Mar 5, 2013 at 3:44 PM, Tom Lane wrote:
>> If "foo OR bar" is useful as an indexqual condition in the inner scan,
>> that's one thing. But if it isn't, the cycles expended to check it in
>> the inner scan are possibly wasted, because we'll still have to check
>> the
2013/3/6 Tom Lane :
> One of the core problems for a writable-foreign-tables feature is how
> to identify a previously-fetched row for UPDATE or DELETE actions.
> In an ordinary Postgres table, we use the ctid system column for that,
> but a remote table doesn't necessarily have such a thing. (Ora
Thanks for taking time in typing a complete summary of the situation. That
really helps.
On Mon, Mar 4, 2013 at 11:25 AM, Greg Smith wrote:
> On 1/23/13 6:36 AM, Michael Paquier wrote:
>
>> The only problem I see is if the same parameter is defined in
>> recovery.conf and postgresql.conf, is the
Hi, I suppose the attached patch is close to the solution.
> I think that this is an original intention of Heikki's patch.
I noticed that archive recovery will be turned on in
next_record_is_invalid thanks to your patch.
> On the other hand, your patch fixes that point but ReadRecord
> runs on t
77 matches
Mail list logo
