Re: [HACKERS] No, pg_size_pretty(numeric) was not such a hot idea
Euler Taveira wrote: On 27-05-2012 10:45, Fujii Masao wrote: OK, let me propose another approach: add pg_size_pretty(int). If we do this, all usability and performance problems will be solved. I wouldn't like to add another function but if it solves both problems... +1. It fixes Tom's example and doesn't break anything else I can find, so +1. Is any further overloading needed to cover other cases which previously worked, or does this cover it? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Uh, I change my mind about commit_delay + commit_siblings (sort of)
Tom Lane wrote: Simon Riggs writes: On 31 May 2012 15:00, Tom Lane wrote: If we want to finish the beta cycle in a reasonable time period and get back to actual development, we have to refrain from adding more possibly-destabilizing development work to 9.2. And that is what this is. In what way is it possibly destabilising? I'm prepared to believe that it only affects performance, but it could be destabilizing to that. It needs proper review and testing, and the next CF is the right environment for that to happen. +1 This is not a bug fix or even a fix for a performance regression. The train has left the station; the next one will be along shortly. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.
Robert Haas robertmh...@gmail.com writes: On the other hand, if we simply say PostgreSQL computes the replication delay by subtracting the time at which the WAL was generated, as recorded on the master, from the time at which it is replayed by the slave then, hey, we still have a wart, but it's pretty clear what the wart is and how to fix it, and we can easily document that. Again, if we could get rid of the failure modes and make this really water-tight, I think I'd be in favor of that, but it seems to me that we are in the process of expending a lot of energy and an even larger amount of calendar time to create a system that will misbehave in numerous subtle ways instead of one straightforward one. I don't see that as a good trade. Well, okay, but let's document if you use this feature, it's incumbent on you to make sure the master and slave clocks are synced. We recommend running NTP. or words to that effect. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.
On 6/2/12, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On the other hand, if we simply say PostgreSQL computes the replication delay by subtracting the time at which the WAL was generated, as recorded on the master, from the time at which it is replayed by the slave then, hey, we still have a wart, but it's pretty clear what the wart is and how to fix it, and we can easily document that. Again, if we could get rid of the failure modes and make this really water-tight, I think I'd be in favor of that, but it seems to me that we are in the process of expending a lot of energy and an even larger amount of calendar time to create a system that will misbehave in numerous subtle ways instead of one straightforward one. I don't see that as a good trade. Well, okay, but let's document if you use this feature, it's incumbent on you to make sure the master and slave clocks are synced. We recommend running NTP. or words to that effect. What if the two servers are in different time zones? -- Mike Nolan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] relation complex types
Jaime Casanova wrote: I knew that we create an entry in pg_type for every table we create, what i didn't know is that we actually create 2 entries. for example CREATE TABLE foo (i int); will create types foo and _foo. so, any reason to create 2 entries? I don't know offhand; maybe its the corresponding row/tuple type and table/relation type? anyway, what really kept my attention is that CREATE SEQUENCE also create an entry in pg_type. there is any reason for that? This I'm fairly sure, is due to a sequence generator being implemented as a table/relation-typed variable, so it has a corresponding type like the regular table/relation-typed variables in the database. -- Darren Duncan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [GENERAL] pg_upgrade from 9.0.7 to 9.1.3: duplicate key pg_authid_oid_index
On Fri, Jun 01, 2012 at 09:52:59AM -0400, Tom Lane wrote:
Bryan Murphy bmurphy1...@gmail.com writes:
The old 9.0 cluster was created by ubuntu. In this cluster there was an
ubuntu user with an oid of 10 and a postgres user with an oid of 16386.
The new 9.1 cluster was created with a custom build of postgres 9.1. This
did not have an ubuntu user, and it had a postgres user with an oid of 10.
OID 10 is the bootstrap superuser, which is created with the name of the
operating system user that ran initdb. So the above does not sound like
anything to do with custom vs stock builds, but with who did initdb.
It seems that pg_upgrade needs a check to make sure that the bootstrap
superuser is named the same in old and new clusters.
[ Thread moved to hackers.]
OK, I have studied this. First we preserve pg_authid.oid because oids
are stored in pg_largeobject_metadata. Second, we dumpall all users,
even the install user because (from pg_dumpall.c):
* We dump CREATE ROLE followed by ALTER ROLE to ensure that the role
* will acquire the right properties even if it already exists (ie, it
* won't hurt for the CREATE to fail). This is particularly important
* for the role we are connected as, since even with --clean we will
* have failed to drop it.
So, pg_upgrade has to strip out restoring the install user because that
would cause an error on restore. That is done in
dump.c::split_old_dump().
The problem is if the old and new install users have different oids, as
the reporter verified.
The attached patch adds checks to verify the the old/new servers have
the same install-user oid.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/pg_upgrade.c b/contrib/pg_upgrade/pg_upgrade.c
new file mode 100644
index 465ecdd..ba81823
*** a/contrib/pg_upgrade/pg_upgrade.c
--- b/contrib/pg_upgrade/pg_upgrade.c
***
*** 29,35
* We control all assignments of pg_enum.oid because these oids are stored
* in user tables as enum values.
*
! * We control all assignments of pg_auth.oid because these oids are stored
* in pg_largeobject_metadata.
*/
--- 29,35
* We control all assignments of pg_enum.oid because these oids are stored
* in user tables as enum values.
*
! * We control all assignments of pg_authid.oid because these oids are stored
* in pg_largeobject_metadata.
*/
diff --git a/contrib/pg_upgrade/check.c b/contrib/pg_upgrade/check.c
new file mode 100644
index 2669c09..df77f53
*** a/contrib/pg_upgrade/check.c
--- b/contrib/pg_upgrade/check.c
*** static void set_locale_and_encoding(Clus
*** 16,22
static void check_new_cluster_is_empty(void);
static void check_locale_and_encoding(ControlData *oldctrl,
ControlData *newctrl);
! static void check_is_super_user(ClusterInfo *cluster);
static void check_for_prepared_transactions(ClusterInfo *cluster);
static void check_for_isn_and_int8_passing_mismatch(ClusterInfo *cluster);
static void check_for_reg_data_type_usage(ClusterInfo *cluster);
--- 16,22
static void check_new_cluster_is_empty(void);
static void check_locale_and_encoding(ControlData *oldctrl,
ControlData *newctrl);
! static void check_is_super_user_get_oid(ClusterInfo *cluster);
static void check_for_prepared_transactions(ClusterInfo *cluster);
static void check_for_isn_and_int8_passing_mismatch(ClusterInfo *cluster);
static void check_for_reg_data_type_usage(ClusterInfo *cluster);
*** check_old_cluster(bool live_check, char
*** 69,75
/*
* Check for various failure cases
*/
! check_is_super_user(old_cluster);
check_for_prepared_transactions(old_cluster);
check_for_reg_data_type_usage(old_cluster);
check_for_isn_and_int8_passing_mismatch(old_cluster);
--- 69,75
/*
* Check for various failure cases
*/
! check_is_super_user_get_oid(old_cluster);
check_for_prepared_transactions(old_cluster);
check_for_reg_data_type_usage(old_cluster);
check_for_isn_and_int8_passing_mismatch(old_cluster);
*** check_new_cluster(void)
*** 121,137
{
set_locale_and_encoding(new_cluster);
get_db_and_rel_infos(new_cluster);
check_new_cluster_is_empty();
- check_for_prepared_transactions(new_cluster);
check_loadable_libraries();
- check_locale_and_encoding(old_cluster.controldata, new_cluster.controldata);
-
if (user_opts.transfer_mode == TRANSFER_MODE_LINK)
check_hard_link();
}
--- 121,144
{
set_locale_and_encoding(new_cluster);
+ check_locale_and_encoding(old_cluster.controldata, new_cluster.controldata);
+
get_db_and_rel_infos(new_cluster);
check_new_cluster_is_empty();
check_loadable_libraries();
if (user_opts.transfer_mode == TRANSFER_MODE_LINK)
Re: [HACKERS] Re: [GENERAL] pg_upgrade from 9.0.7 to 9.1.3: duplicate key pg_authid_oid_index
Bruce Momjian br...@momjian.us writes: On Fri, Jun 01, 2012 at 09:52:59AM -0400, Tom Lane wrote: It seems that pg_upgrade needs a check to make sure that the bootstrap superuser is named the same in old and new clusters. The attached patch adds checks to verify the the old/new servers have the same install-user oid. That may or may not be a useful check to make, but it's got approximately nothing to do with what I was complaining about. In particular, supposing that the user has given you a username that isn't the bootstrap superuser in the new cluster, this patch is not going to stop the update script from failing. Because the script is then going to try to replace the bootstrap superuser, and that is certainly going to give an error. I see the point of worrying about the install user as well as the bootstrap superuser, but wouldn't it be best to insist they be the same? Particularly in the new cluster, where if they aren't the same it means the user has manually created at least one role in the new cluster, which is likely to lead to OID conflicts or worse. Furthermore, if the bootstrap superusers aren't named the same, your patch fails to handle the original complaint. In the case the OP mentioned, the old cluster had OID 10: ubuntu some user-defined OID: postgres and the new cluster had OID 10: postgres If the user tells pg_upgrade to use username postgres, your check will not fail AFAICS, but nonetheless things are going to be messed up after the upgrade, because some objects and privileges that used to belong to the bootstrap superuser will now belong to a non-default superuser, whereas what used to belong to the non-default superuser will now belong to the bootstrap superuser. That cannot be thought desirable. For one reason, in the old installation the postgres role could have been dropped (possibly after dropping a few non-builtin objects) whereas the ubuntu role was pinned. In the new installation, postgres is pinned and ubuntu won't be. I think the checks that are actually needed here are (1) bootstrap superusers are named the same, and (2) there are no roles other than the bootstrap superuser in the new cluster. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] relation complex types
Darren Duncan dar...@darrenduncan.net writes: Jaime Casanova wrote: I knew that we create an entry in pg_type for every table we create, what i didn't know is that we actually create 2 entries. for example CREATE TABLE foo (i int); will create types foo and _foo. so, any reason to create 2 entries? I don't know offhand; maybe its the corresponding row/tuple type and table/relation type? _foo is the array type foo[]. There was bellyaching about the extra pg_type entries when we added support for arrays of complex types, but it was decided that trying to suppress them for table rowtypes would be too, um, complex. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Visual Studio 2012 RC
The attached patch makes postgres build with Visual Studio 2012 RC.
As MS finally decided on the name I don't expect any need for changes
for the final RTM.
I didn't bother to update the docs for now as I still have some hope
that the developer community succeds in pushig M$ to reverse this decision:
http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html
Regards,
Brar
diff -Napcdr -x .git postgresql/src/tools/msvc/MSBuildProject.pm
postgresql_dev/src/tools/msvc/MSBuildProject.pm
*** postgresql/src/tools/msvc/MSBuildProject.pm Tue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/MSBuildProject.pm Wed Mar 14 23:59:07 2012
*** sub new
*** 385,388
--- 385,428
return $self;
}
+ package VC2012Project;
+
+ #
+ # Package that encapsulates a Visual C++ 2012 project file
+ #
+
+ use strict;
+ use warnings;
+ use base qw(MSBuildProject);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{vcver} = '11.00';
+
+ return $self;
+ }
+
+ sub WriteConfigurationPropertyGroup
+ {
+ my ($self, $f, $cfgname, $p) = @_;
+ my $cfgtype =
+ ($self-{type} eq exe)
+ ?'Application'
+ :($self-{type} eq dll?'DynamicLibrary':'StaticLibrary');
+
+ print $f EOF;
+ PropertyGroup
Condition='\$(Configuration)|\$(Platform)'=='$cfgname|$self-{platform}'
Label=Configuration
+ ConfigurationType$cfgtype/ConfigurationType
+ UseOfMfcfalse/UseOfMfc
+ CharacterSetMultiByte/CharacterSet
+ WholeProgramOptimization$p-{wholeopt}/WholeProgramOptimization
+ PlatformToolsetv110/PlatformToolset
+ /PropertyGroup
+ EOF
+ }
+
1;
diff -Napcdr -x .git postgresql/src/tools/msvc/Solution.pm
postgresql_dev/src/tools/msvc/Solution.pm
*** postgresql/src/tools/msvc/Solution.pm Wed Mar 14 23:14:28 2012
--- postgresql_dev/src/tools/msvc/Solution.pm Wed Mar 14 23:58:58 2012
*** sub new
*** 645,648
--- 645,672
return $self;
}
+ package VS2012Solution;
+
+ #
+ # Package that encapsulates a Visual Studio 2012 solution file
+ #
+
+ use Carp;
+ use strict;
+ use warnings;
+ use base qw(Solution);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{solutionFileVersion} = '12.00';
+ $self-{vcver} = '11.00';
+ $self-{visualStudioName} = 'Visual Studio 2012';
+
+ return $self;
+ }
+
1;
diff -Napcdr -x .git postgresql/src/tools/msvc/VSObjectFactory.pm
postgresql_dev/src/tools/msvc/VSObjectFactory.pm
*** postgresql/src/tools/msvc/VSObjectFactory.pmTue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/VSObjectFactory.pmWed Mar 14 23:59:03 2012
*** sub CreateSolution
*** 41,46
--- 41,50
{
return new VS2010Solution(@_);
}
+ elsif ($visualStudioVersion eq '11.00')
+ {
+ return new VS2012Solution(@_);
+ }
else
{
croak The requested Visual Studio version is not supported.;
*** sub CreateProject
*** 68,73
--- 72,81
{
return new VC2010Project(@_);
}
+ elsif ($visualStudioVersion eq '11.00')
+ {
+ return new VC2012Project(@_);
+ }
else
{
croak The requested Visual Studio version is not supported.;
*** sub DetermineVisualStudioVersion
*** 105,115
sub _GetVisualStudioVersion
{
my($major, $minor) = @_;
! if ($major 10)
{
carp
The determined version of Visual Studio is newer than the latest supported
version. Returning the latest supported version instead.;
! return '10.00';
}
elsif ($major 6)
{
--- 113,123
sub _GetVisualStudioVersion
{
my($major, $minor) = @_;
! if ($major 11)
{
carp
The determined version of Visual Studio is newer than the latest supported
version. Returning the latest supported version instead.;
! return '11.00';
}
elsif ($major 6)
{
diff -Napcdr -x .git postgresql/src/tools/msvc/build.pl
postgresql_dev/src/tools/msvc/build.pl
*** postgresql/src/tools/msvc/build.pl Tue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/build.pl Thu Mar 15 00:12:25 2012
*** elsif ($ARGV[0] ne RELEASE)
*** 50,56
# ... and do it
! if ($buildwhat and $vcver eq '10.00')
{
system(msbuild $buildwhat.vcxproj /verbosity:detailed
/p:Configuration=$bconf);
}
--- 50,56
# ... and do it
! if ($buildwhat and $vcver = 10.00)
{
system(msbuild $buildwhat.vcxproj /verbosity:detailed
/p:Configuration=$bconf);
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
