On Sun, May 5, 2013 at 5:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Paquier michael.paqu...@gmail.com writes:
On Thu, May 2, 2013 at 11:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps it'd be a good idea to emit the command tag on receiving a
non-tuple-bearing result, just to make
On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2. Those dates might change,
but that is the current plan. I have completed a draft 9.3 release
notes, which you can view here:
Dear Amit
yes, my new constrains must not be name of variable.
I moved new keyword to reserved keyword.
Problem solved :D
Regards
Soroosh
On Mon, May 6, 2013 at 10:17 AM, Amit Kapila amit.kap...@huawei.com wrote:
On Sunday, May 05, 2013 1:03 PM soroosh sardari wrote:
Hi
I'm trying to
On 03.05.2013 18:17, Fujii Masao wrote:
Hi,
I got the following assertion failure when I promoted the standby.
2013-05-04 00:12:31 JST sby1 LOG: received promote request
2013-05-04 00:12:31 JST sby1 FATAL: terminating walreceiver process
due to administrator command
2013-05-04 00:12:31 JST
On 05.05.2013 12:13, Amit Langote wrote:
Hello,
I tried reproducing the scenario. Note that I did not archive xlogs
(that is, archive_command = '/bin/true' and corresponding
restore_command = '/bin/false'). I performed the steps you mentioned
and could find following:
[snip]
[Standby-2]FATAL:
On May 5, 2013, at 11:51 AM, Andrew Dunstan and...@dunslane.net wrote:
I can't off the top of my head see any good reason for zero padding, so I'm
with Tom.
Same here.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Andres Freund and...@2ndquadrant.com writes:
On 2013-04-30 05:14:15 +0100, Joel Jacobson wrote:
It would be better to find a way to update sql-language functions in
minor upgrades, instead of shutting that door entirely for all future
implementation ideas involving sql-language functions in
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Andres Freund and...@2ndquadrant.com writes:
Just a little collection of problems:
* You need to connect to all databases, not just one. There's no
infrastructure for this.
I wonder if it wouldn't be possible to have a per database
Stephen Frost sfr...@snowman.net writes:
It likely is, but it would really be nice to be able to do catalog
updates like these in a better fashion than sticking some update command
into the release notes and hoping that someone reads them and runs the
command..
Agreed.
Another advantage of
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Another advantage of using more the extension infrastructure is that
shipping bug fixes in the C or SQL parts of them would allow a hot fix
to be shipped without restart when limited to an extension.
I'm actually not thrilled with the security
On 2013-05-06 14:34:52 +0200, Dimitri Fontaine wrote:
In-core installed-by-default extensions, anyone?
We already have that in plpgsql ...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
On Mon, May 6, 2013 at 06:54:06AM -0400, Robert Haas wrote:
On May 5, 2013, at 11:51 AM, Andrew Dunstan and...@dunslane.net wrote:
I can't off the top of my head see any good reason for zero padding, so I'm
with Tom.
Same here.
Agreed, reverted.
--
Bruce Momjian br...@momjian.us
Stephen Frost sfr...@snowman.net writes:
I'm not against this idea- but we *still* need to solve the problem of
how we update the catalog during a point release and, imv anyway, we
would need to be able to upgrade any in-core installed-by-default
extensions during a point release too, to
Hi guys,
My first post here :)
I stumbled into the same problem as this guy
http://www.postgresql.org/message-id/4be2835a.5020...@cybertec.at
, so since I have some spare time recently, I've set-up the development
environment for postgresql and I think I may be able to contibute for the
feature
On Fri, May 3, 2013 at 9:07 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-05-03 14:54:23 -0400, Andrew Dunstan wrote:
On 05/03/2013 02:43 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 03.05.2013 20:56, Bruce Momjian wrote:
On Fri, May 3, 2013 at
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
it seems like the extensions code should test for and reject an attempt
to set a relocatable extension's schema to pg_catalog. Otherwise you'd
be likely to get not-too-intelligible errors from the extension
On Mon, May 6, 2013 at 12:43:55PM +0530, Amit Kapila wrote:
On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2. Those dates might change,
but that is the current plan. I
On 05/06/2013 10:19 AM, Magnus Hagander wrote:
On Fri, May 3, 2013 at 9:07 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-05-03 14:54:23 -0400, Andrew Dunstan wrote:
On 05/03/2013 02:43 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 03.05.2013 20:56,
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
If you want to call the pg_class column relispopulated rather
than relisscannable, I have no particular objection to that
That column name and the wording of some comments are the main
things, although I'm also
Patch to allow pg_dump to use a snapshot exported with an explicit
pg_export_snapshot() for when precise timing of the snapshot is
important.
This overrides the internally generated snapshot in parallel pg_dump.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL
On Sun, May 5, 2013 at 02:16:59PM -0700, Jeff Janes wrote:
On Thu, May 2, 2013 at 4:13 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, May 2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
Some suggestions, perhaps just based on my preference for verbosity:
On Sun, May 5, 2013 at 06:59:28PM -0400, Andrew Dunstan wrote:
I think this is equally important for restoration of dumps, if
the restoration
is run all in one transaction. (Making the dump and restoring
it have similar
locking and unlocking patterns)
Do you
Tom Lane t...@sss.pgh.pa.us writes:
Huh? According to the comment, at least, we don't get here for a
relocatable extension. I don't see anything wrong with auto-creating
the target schema for a non-relocatable extension.
I was not finding why I would trust the comment the other evening,
On 05/06/2013 10:56 AM, Simon Riggs wrote:
Patch to allow pg_dump to use a snapshot exported with an explicit
pg_export_snapshot() for when precise timing of the snapshot is
important.
This overrides the internally generated snapshot in parallel pg_dump.
Could you be a bit more expansive
Kevin Grittner kgri...@ymail.com writes:
Kevin Grittner kgri...@ymail.com wrote:
That column name and the wording of some comments are the main
things
Patch for that attached. I left the part where you got rid of the
SQL function to allow users to test whether a matview is currently
Tom Lane t...@sss.pgh.pa.us writes:
The long and the short of it is this: having unlogged matviews in 9.3
is not worth taking that risk for. IMO anyway.
FWIW, +1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers
Peter Eisentraut pete...@gmx.net writes:
At this point, all that is appropriate is some documentation of the C
API. If the contrib example you have in mind is short enough, it might
as well become part of the example in the documentation.
Please find attached a patch against the
On 05.05.2013 18:51, Andrew Dunstan wrote:
On 05/05/2013 01:35 AM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, so we can either use 4 hex digits minimum and have a fixed with on
most platforms, extend it to 8 hex digits, or revert the entire
fixed-width idea.
I think we should
On 05/06/2013 08:17 AM, Tom Lane wrote:
Per my other mail, I think adding an AMV option at this time is
inadvisable. I could go either way on removing or keeping the
is_scannable function --- anybody else have an opinion on that point?
Which of us is going to commit this? We're running low
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
The flip side of that is that it might be confusing to try
to explain why users should care which test they use before they
are capable of returning different results.
That's a good point too, though; if they are
On Mon, May 6, 2013 at 06:23:07PM +0300, Heikki Linnakangas wrote:
On 05.05.2013 18:51, Andrew Dunstan wrote:
On 05/05/2013 01:35 AM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, so we can either use 4 hex digits minimum and have a fixed with on
most platforms, extend it to 8
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
It seems a bit late to be adding such a thing;
No kidding. The same could be said for the rest of this. It was
all talked to death months ago before I posted a patch which was
proposed for commit. All this
* Kevin Grittner (kgri...@ymail.com) wrote:
Since the patch we have floating around drops it, let's leave it
that way, in the interest of saving time getting to beta. If it
was still there, I'd probably vote to leave it for the same reason.
I'll vote for dropping it also, though for a
On 6 May 2013 16:02, Andrew Dunstan and...@dunslane.net wrote:
On 05/06/2013 10:56 AM, Simon Riggs wrote:
Patch to allow pg_dump to use a snapshot exported with an explicit
pg_export_snapshot() for when precise timing of the snapshot is
important.
This overrides the internally generated
On Mon, May 6, 2013 at 4:47 PM, Andrew Dunstan and...@dunslane.net wrote:
On 05/06/2013 10:19 AM, Magnus Hagander wrote:
On Fri, May 3, 2013 at 9:07 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-05-03 14:54:23 -0400, Andrew Dunstan wrote:
On 05/03/2013 02:43 PM, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 6 May 2013 16:02, Andrew Dunstan and...@dunslane.net wrote:
On 05/06/2013 10:56 AM, Simon Riggs wrote:
This overrides the internally generated snapshot in parallel pg_dump.
Could you be a bit more expansive about the use case, please?
Exported
On Mon, May 6, 2013 at 06:41:53PM +0200, Magnus Hagander wrote:
In practice, something else must be further truncating it, at about 64 chars
by the look of it - see for example
http://www.postgresql.org/message-id/e1uvtfj-00079k...@gemulon.postgresql.org
Ha. Good point. There's actually
I've thought for some time that, given that it can't reproduce the MV
states exactly, pg_dump shouldn't even try. I think it would be more
useful to have two operating modes selectable by command line switch:
refresh all matviews, or refresh none of them.
This seems like a reasonable
On 2013-05-06 13:07:17 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 6 May 2013 16:02, Andrew Dunstan and...@dunslane.net wrote:
On 05/06/2013 10:56 AM, Simon Riggs wrote:
This overrides the internally generated snapshot in parallel pg_dump.
Could you be a bit more
On 6 May 2013 18:07, Tom Lane t...@sss.pgh.pa.us wrote:
Or in short: -1 for the very concept of letting the user control
pg_dump's snapshot.
That API is already exposed, so not sure why you say this now? This
has been in PG since early in 9.2, about 2 years ago.
In any case, flashback
* Andres Freund (and...@2ndquadrant.com) wrote:
Its rather useful if you e.g. want to instantiate a new replica without
rebuilding pg_dump/pg_restore's capabilities wrt. ordering, parallelism,
separating initial data load from index creation and all that. Which
already has been incompletely
On 2013-05-06 14:35:14 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
Its rather useful if you e.g. want to instantiate a new replica without
rebuilding pg_dump/pg_restore's capabilities wrt. ordering, parallelism,
separating initial data load from index
On Mon, May 6, 2013 at 6:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
In any case, flashback database is one of the most requested
features I know of... the ability to dump the database as it appeared
in the past *after* that point has passed.
Fwiw that's not what flashback database does.
On 06.05.2013 20:12, Bruce Momjian wrote:
On Mon, May 6, 2013 at 06:41:53PM +0200, Magnus Hagander wrote:
So what should our goal length be?
Different tools seem to have different truncation points, so it sounds
like the rule is something like: If you can keep it under 50 characters,
great.
On Wed, May 1, 2013 at 3:04 PM, Jeff Davis pg...@j-davis.com wrote:
Regardless, you have a reasonable claim that my patch had effects that
were not necessary. I have attached a draft patch to remedy that. Only
rudimentary testing was done.
This looks reasonable to me.
--
Robert Haas
On Fri, May 3, 2013 at 11:13 AM, Cédric Villemain
ced...@2ndquadrant.com wrote:
If we want to avoid adding a new option for this, how about a magic
restore point called consistent or immediate:
recovery_target_name='immediate'
That would stop recovery right after reaching consistency, but
RSA secret key extraction code uses wrong variable so
that decryption is skipped and only secret keys without
password work for pgp_pub_decrypt().
Attached patch fixes it and also adds regtest.
Please apply to all branches.
Reported-by: Keith Fiske ke...@omniti.com
--
marko
diff --git
On Thu, May 2, 2013 at 1:59 PM, Fabien COELHO coe...@cri.ensmp.fr wrote:
This is mostly for reference to the next commitfest.
This very minor patch adds a corresponding long option to all short (one
letter) options of pgbench. In particular for connection options there is
now --host
On 6 May 2013 19:35, Stephen Frost sfr...@snowman.net wrote:
It certainly sounds interesting and I like the idea of it, but perhaps
we need a different mechanism than just passing in a raw snapshot, to
address the concerns that Tom raised.
It does *not* pass in a raw snapshot. All it does is
On 6 May 2013 19:48, Greg Stark st...@mit.edu wrote:
On Mon, May 6, 2013 at 6:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
In any case, flashback database is one of the most requested
features I know of... the ability to dump the database as it appeared
in the past *after* that point has
On Mon, 2013-05-06 at 15:31 -0400, Robert Haas wrote:
On Wed, May 1, 2013 at 3:04 PM, Jeff Davis pg...@j-davis.com wrote:
Regardless, you have a reasonable claim that my patch had effects that
were not necessary. I have attached a draft patch to remedy that. Only
rudimentary testing was
Simon Riggs si...@2ndquadrant.com writes:
It does *not* pass in a raw snapshot. All it does is to allow pg_dump
to use an API that is already exposed by the backend for this very
purpose, one that has been in Postgres since 9.2.
On Wed, May 1, 2013 at 6:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fix permission tests for views/tables proven empty by constraint exclusion.
I believe that this commit is responsible for the fact that the
following test case now crashes the server:
rhaas=# create or replace view foo (x) AS
Robert Haas robertmh...@gmail.com writes:
rhaas=# create or replace view foo (x) AS (select 1 union all select 2);
CREATE VIEW
rhaas=# select * from foo where false;
The connection to the server was lost. Attempting reset: Failed.
Ugh. I'm about to leave for the day, but I'll take a look
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 6 May 2013 19:35, Stephen Frost sfr...@snowman.net wrote:
It certainly sounds interesting and I like the idea of it, but perhaps
we need a different mechanism than just passing in a raw snapshot, to
address the concerns that Tom
On Mon, May 6, 2013 at 10:02 PM, Simon Riggs si...@2ndquadrant.com wrote:
At the database level, it rolls back the whole kaboodle. Not what I
meant at all and I would expect people to start twitching at the
prospect.
I think it would be pretty sweet but we don't have the infrastructure
for it.
* Greg Stark (st...@mit.edu) wrote:
On Mon, May 6, 2013 at 10:02 PM, Simon Riggs si...@2ndquadrant.com wrote:
At the database level, it rolls back the whole kaboodle. Not what I
meant at all and I would expect people to start twitching at the
prospect.
I think it would be pretty sweet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/06/2013 03:00 PM, Stephen Frost wrote:
For example, I'm not sure that we need more information in the
WAL.. What we need is a way to tell VACUUM to skip over 'recently
modified' records and not mark them as dead until some time has
passed.
On 6 May 2013 22:13, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It does *not* pass in a raw snapshot. All it does is to allow pg_dump
to use an API that is already exposed by the backend for this very
purpose, one that has been in Postgres since 9.2.
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
If anybody really wanted to fix pg_dump, they could do. If that was so
important, why block this patch, but allow parallel pg_dump to be
committed without it?
Because parallel pg_dump didn't make the problem any *worse*..? This
does. The
On 2013-05-06 20:18:26 -0400, Stephen Frost wrote:
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
If anybody really wanted to fix pg_dump, they could do. If that was so
important, why block this patch, but allow parallel pg_dump to be
committed without it?
Because parallel pg_dump
On 2013-05-07 02:53:16 +0200, Andres Freund wrote:
A rather useful feature has to fix a bug in pg_dump which a) exists for
ages b) has yet to be reported to the lists c) is rather complicated to
fix and quite possibly requires proper snapshots for internals?
Just to clarify: I think this worth
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-05-06 20:18:26 -0400, Stephen Frost wrote:
Because parallel pg_dump didn't make the problem any *worse*..? This
does. The problem existed before parallel pg_dump.
Yes, it did.
That's not entirely clear- are you agreeing with my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2013 06:37 AM, Joe Conway wrote:
On 05/06/2013 03:00 PM, Stephen Frost wrote:
For example, I'm not sure that we need more information in the
WAL.. What we need is a way to tell VACUUM to skip over 'recently
modified' records and not
On 2013-05-06 21:07:36 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-05-06 20:18:26 -0400, Stephen Frost wrote:
Because parallel pg_dump didn't make the problem any *worse*..? This
does. The problem existed before parallel pg_dump.
Yes, it did.
On Monday, May 06, 2013 8:17 PM Bruce Momjian wrote:
On Mon, May 6, 2013 at 12:43:55PM +0530, Amit Kapila wrote:
On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2. Those
Hi,
Attached is a documentation patch against head which makes
static the targets of the on-line PG html documentation that
are referenced by the phpPgAdmin help system.
Apply with patch -p1 at the top of the pg code tree.
The phpPgAdmin project is a web interface into PG. It
contains help
67 matches
Mail list logo
