Re: [HACKERS] Parallel Seq Scan

[Noah Misch]

On Sat, Oct 24, 2015 at 07:49:07AM -0400, Robert Haas wrote:
> On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch  wrote:
> > Since that specification permits ParamListInfo consumers to ignore 
> > paramMask,
> > the plpgsql_param_fetch() change from copy-paramlistinfo-fixes.patch is 
> > still
> > formally required.
> 
> So why am I not just doing that, then?  Seems a lot more surgical.

do $$
declare
param_unused text := repeat('a', 100 * 1024 * 1024);
param_used oid := 403;
begin
perform count(*) from pg_am where oid = param_used;
end
$$;

I expect that if you were to inspect the EstimateParamListSpace() return
values when executing that, you would find that it serializes the irrelevant
100 MiB datum.  No possible logic in plpgsql_param_fetch() could stop that
from happening, because copyParamList() and SerializeParamList() call the
paramFetch hook only for dynamic parameters.  Cursors faced the same problem,
which is the raison d'être for setup_unshared_param_list().


-- 
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] JDBC driver debug out?

[Tatsuo Ishii]

Thanks. It works.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

> Add
> 
> DriverManager.setLogWriter(new PrintWriter(System.out));
> 
> below the setLogLevel and it will
> 
> I'll fix this though
> 
> Dave Cramer
> 
> da...@postgresintl.com
> www.postgresintl.com
> 
> On 23 October 2015 at 22:35, Tatsuo Ishii  wrote:
> 
>> Unfortunately it doesn't work (no debug trace).
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese:http://www.sraoss.co.jp
>>
>> > This should work better
>> >
>> >
>> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-1204-jdbc41-SNAPSHOT/
>> >
>> > Dave Cramer
>> >
>> > da...@postgresintl.com
>> > www.postgresintl.com
>> >
>> > On 23 October 2015 at 21:32, Dave Cramer  wrote:
>> >
>> >> No, I need to provide you with a 41 version.
>> >>
>> >> I just happened to have java 1.8 on my machine.
>> >>
>> >> Dave Cramer
>> >>
>> >> da...@postgresintl.com
>> >> www.postgresintl.com
>> >>
>> >> On 23 October 2015 at 21:31, Tatsuo Ishii  wrote:
>> >>
>> >>> Dave,
>> >>>
>> >>> Thanks for the quick response. Unfortunately now I'm getting error
>> >>> with the JDBC driver.
>> >>>
>> >>> warning:
>> >>>
>> /usr/local/pgsql/share/postgresql-9.4-1204-jdbc42-20151023.230759-1.jar(org/postgresql/Driver.class):
>> >>> major version 52 is newer than 51, the highest major version supported
>> by
>> >>> this compiler.
>> >>>   It is recommended that the compiler be upgraded.
>> >>> 1 warning
>> >>> [snip]
>> >>> Exception in thread "main" java.lang.UnsupportedClassVersionError:
>> >>> org/postgresql/Driver : Unsupported major.minor version 52.0
>> >>> at java.lang.ClassLoader.defineClass1(Native Method)
>> >>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>> >>> at
>> >>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>> >>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>> >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>> >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>> >>> at java.security.AccessController.doPrivileged(Native Method)
>> >>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>> >>> at
>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>> >>> at java.lang.Class.forName0(Native Method)
>> >>> at java.lang.Class.forName(Class.java:191)
>> >>> at begin_select_sleep.dbAccess(begin_select_sleep.java:39)
>> >>> at begin_select_sleep.main(begin_select_sleep.java:21)
>> >>>
>> >>> $ java -version
>> >>> java version "1.7.0_79"
>> >>> OpenJDK Runtime Environment (IcedTea 2.5.6)
>> (7u79-2.5.6-0ubuntu1.14.04.1)
>> >>> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
>> >>>
>> >>> Probably I should upgrade Java...
>> >>>
>> >>> Best regards,
>> >>> --
>> >>> Tatsuo Ishii
>> >>> SRA OSS, Inc. Japan
>> >>> English: http://www.sraoss.co.jp/index_en.php
>> >>> Japanese:http://www.sraoss.co.jp
>> >>>
>> >>> > Tatsuo,
>> >>> >
>> >>> > Can you confirm it is fixed in this snapshot
>> >>> >
>> >>>
>> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-1204-jdbc42-SNAPSHOT/
>> >>> >
>> >>> > Dave Cramer
>> >>> >
>> >>> > da...@postgresintl.com
>> >>> > www.postgresintl.com
>> >>> >
>> >>> > On 23 October 2015 at 19:00, Dave Cramer  wrote:
>> >>> >
>> >>> >> Tatsuo,
>> >>> >>
>> >>> >> posting to jdbc list
>> >>> >>
>> >>> >> Dave Cramer
>> >>> >>
>> >>> >> da...@postgresintl.com
>> >>> >> www.postgresintl.com
>> >>> >>
>> >>> >> On 23 October 2015 at 18:28, Tatsuo Ishii 
>> >>> wrote:
>> >>> >>
>> >>> >>> It seems
>> >>> >>> org.postgresql.Driver.setLogLevel(org.postgresql.Driver.DEBUG) does
>> >>> >>> not work anymore in the newer JDBC driver.
>> >>> >>>
>> >>> >>> As far as I know, postgresql-9.2-1003.jdbc4.jar or
>> >>> >>> postgresql-9.3-1104.jdbc41.jar work fine and produce following
>> output
>> >>> >>> for example:
>> >>> >>>
>> >>> >>> 16:36:36.459 (1) PostgreSQL 9.3 JDBC4.1 (build 1104)
>> >>> >>> 16:36:36.464 (1) Trying to establish a protocol version 3
>> connection
>> >>> to
>> >>> >>> localhost:11000
>> >>> >>> 16:36:36.481 (1) Receive Buffer Size is 530904
>> >>> >>> 16:36:36.481 (1) Send Buffer Size is 1313280
>> >>> >>> 16:36:36.481 (1)  FE=>  StartupPacket(user=t-ishii, database=test,
>> >>> >>> client_encoding=UTF8, DateStyle=ISO, TimeZone=Asia/Tokyo,
>> >>> >>> extra_float_digits=2)
>> >>> >>> 16:36:36.487 (1)<=BE 

Re: [HACKERS] [patch] extensions_path GUC

[David E. Wheeler]

On Oct 23, 2015, at 9:26 AM, Jim Nasby  wrote:

> I would love it if make check worked. make installcheck adds extra effort to 
> extension develoopment, not to mention leaving your actual install in a less 
> than pristine state.

I’ve wanted this for a long time. I think it would have to create a temporary 
cluster, fire up a server, install the extension(s), run the tests, shut down 
the server and delete the cluster.

> Possibly related to this... I'd also like to have other options for running 
> unit tests, besides pg_regress. I looked at it briefly and the big PITA about 
> doing it was having to manage the temporary database (and ideally temporary 
> cluster). If standing those up was separated from pg_regress it would make it 
> a lot easier for someone to customize how testing works under PGXS.

Right, then pg_regress could just be the default test framework.

Dvaid



smime.p7s
Description: S/MIME cryptographic signature

Re: [HACKERS] Rework the way multixact truncations work

[Noah Misch]

I'm several days into a review of this change (commits 4f627f8 and aa29c1c).
There's one part of the design I want to understand before commenting on
specific code.  What did you anticipate to be the consequences of failing to
remove SLRU segment files that MultiXactState->oldestMultiXactId implies we
should have removed?  I ask because, on the one hand, I see code making
substantial efforts to ensure that it truncates exactly as planned:

/*
 * Do truncation, and the WAL logging of the truncation, in a critical
 * section. That way offsets/members cannot get out of sync anymore, 
i.e.
 * once consistent the newOldestMulti will always exist in members, even
 * if we crashed in the wrong moment.
 */
START_CRIT_SECTION();

/*
 * Prevent checkpoints from being scheduled concurrently. This is 
critical
 * because otherwise a truncation record might not be replayed after a
 * crash/basebackup, even though the state of the data directory would
 * require it.
 */
Assert(!MyPgXact->delayChkpt);
MyPgXact->delayChkpt = true;
...
/*
 * Update in-memory limits before performing the truncation, while 
inside
 * the critical section: Have to do it before truncation, to prevent
 * concurrent lookups of those values. Has to be inside the critical
 * section as otherwise a future call to this function would error out,
 * while looking up the oldest member in offsets, if our caller crashes
 * before updating the limits.
 */

On the other hand, TruncateMultiXact() callees ignore unlink() return values:

On Tue, Sep 22, 2015 at 07:57:27PM +0200, Andres Freund wrote:
> On 2015-09-22 13:38:58 -0400, Robert Haas wrote:
> > - If SlruDeleteSegment fails in unlink(), shouldn't we at the very
> > least log a message?  If that file is still there when we loop back
> > around, it's going to cause a failure, I think.
> 
> The existing unlink() call doesn't, that's the only reason I didn't add
> a message there. I'm fine with adding a (LOG or WARNING?) message.

Unlinking old pg_clog files is strictly an optimization.  If you were to
comment out every unlink() call in slru.c, the only ill effect on CLOG is the
waste of disk space.  Is the same true of MultiXact?

If there's anyplace where failure to unlink would cause a malfunction, I think
it would be around the use of SlruScanDirCbFindEarliest().  That function's
result becomes undefined if the range of pg_multixact/offsets segment files
present on disk spans more than about INT_MAX/2 MultiXactId.

Thanks,
nm


-- 
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] Patch (2): Implement failover on libpq connect level.

[Victor Wagner]

В Fri, 23 Oct 2015 22:14:56 +0100
Thom Brown  пишет:

c> >
> > pg_basebackup -v -x -D standby1 \
> >   -d "host=localhost port=5532 user=rep_user readonly=1"
> 
> Yes, this works:
> 
> $ pg_basebackup -v -x -D standby1 -d "host=localhost port=5532
> user=rep_user readonly=1"
> transaction log start point: 0/228 on timeline 1
> transaction log end point: 0/2000130
> pg_basebackup: base backup completed
> 
> Thom

Thanks for your help.

I was unable to reproduce segfault with this situation on Linux x86-64..

I got message:

row number 0 is out of range 0..-1

and connection failed. Can you tell me a bit more of your setup.
At least which architecture you are compiling Postgres for.


-- 
   Victor Wagner 


-- 
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] Allow ssl_renegotiation_limit in PG 9.5

[Shay Rojansky]

>
> > Here's a patch that adds back the GUC, with default/min/max 0 and
> > GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE.
> >
> > This is my first pg patch, please be gentle with any screwups :)
>
> Why, you dummy.
>
> No, actually, this looks fine.  I've committed it and back-patched it
> to 9.5.  I took the liberty of making some cosmetic changes, however.
>
> Thanks for preparing this patch.
>

Thanks for accepting it! It will definitely save some trouble.

Re: [HACKERS] Proposal: Trigonometric functions in degrees

[Simon Riggs]

On 24 October 2015 at 05:24, Dean Rasheed  wrote:

> Currently PostgreSQL only has trigonometric functions that work in
> radians. I think it would be quite useful to have an equivalent set of
> functions that worked in degrees. In other environments these are
> commonly spelled sind(), cosd(), etc.
>
> Partly, this would be a matter of convenience. It's quite common to
> have a problem domain where angles are specified in degrees, and it's
> somewhat cumbersome having to type things like sin(radians(x)) and
> degrees(asin(x)).
>
> Additionally, functions that worked natively in degrees would be able
> to return exact answers in special cases like cosd(90) = 0, whereas
> cos(radians(90)) is not exactly 0 because pi/2 cannot be represented
> exactly as a floating point number.
>

That is important.


> Possibly the earthdistance module would benefit from these functions too.
>
> Thoughts?
>

+1, yes, please.

-- 
Simon Riggshttp://www.2ndQuadrant.com/

PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

[Peter Eisentraut]

On 10/23/15 11:10 PM, Noah Misch wrote:
> On RHEL 5 and some other "active adult" systems, "localhost" does not reach a
> listen_addresses='::' server.  IPv6 is available, but "localhost" resolves to
> 127.0.0.1 only.
> 
> The latest systems resolve "localhost" to both 127.0.0.1 and ::1, in which
> case PQping("host='localhost'") will attempt both addresses in an unspecified
> order.  Given a postmaster with listen_addresses='0.0.0.0', contacting ::1
> first will fail (fine) or reach a different postmaster (not fine).

A design I have seen in some other systems is that you specify as a
configuration parameter an address by which you want to be contacted by
admin tools.  This might be overkill here since we only need to be
contacted by a local client and the discussion is hoping to handle those
cases, but if not it would be a more principled solution.



-- 
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] Patch (2): Implement failover on libpq connect level.

[Victor Wagner]

В Fri, 23 Oct 2015 16:02:33 -0400
Korry Douglas  пишет:

d> > Now support for service files is implemented and multiple host
> > statements in the service file are allowed.
> 
> A couple of minor nits:
> 
> When you call pg_is_in_recovery(), you should schema-qualify the 
> function name, just in case some other version of that function
> exists in the search_path.
> 
> Also, pg_is_in_recovery() returns a boolean value - PQgetvalue() will 
> not return "true" or "false", it will return "t" or "f".
> 
> And, you have a bit of garbage in the patch (the patch inserts 
> UNIXSOCK_PATH(portstr, portnum, conn->pgunixsocket); in the header 
> comment at the top of fe-connect.c).
> 

Thanks, I'd address this issues in the next version of path.
 



-- 
   Victor Wagner 


-- 
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] JDBC driver debug out?

[Dave Cramer]

Add

DriverManager.setLogWriter(new PrintWriter(System.out));

below the setLogLevel and it will

I'll fix this though

Dave Cramer

da...@postgresintl.com
www.postgresintl.com

On 23 October 2015 at 22:35, Tatsuo Ishii  wrote:

> Unfortunately it doesn't work (no debug trace).
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
> > This should work better
> >
> >
> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-1204-jdbc41-SNAPSHOT/
> >
> > Dave Cramer
> >
> > da...@postgresintl.com
> > www.postgresintl.com
> >
> > On 23 October 2015 at 21:32, Dave Cramer  wrote:
> >
> >> No, I need to provide you with a 41 version.
> >>
> >> I just happened to have java 1.8 on my machine.
> >>
> >> Dave Cramer
> >>
> >> da...@postgresintl.com
> >> www.postgresintl.com
> >>
> >> On 23 October 2015 at 21:31, Tatsuo Ishii  wrote:
> >>
> >>> Dave,
> >>>
> >>> Thanks for the quick response. Unfortunately now I'm getting error
> >>> with the JDBC driver.
> >>>
> >>> warning:
> >>>
> /usr/local/pgsql/share/postgresql-9.4-1204-jdbc42-20151023.230759-1.jar(org/postgresql/Driver.class):
> >>> major version 52 is newer than 51, the highest major version supported
> by
> >>> this compiler.
> >>>   It is recommended that the compiler be upgraded.
> >>> 1 warning
> >>> [snip]
> >>> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> >>> org/postgresql/Driver : Unsupported major.minor version 52.0
> >>> at java.lang.ClassLoader.defineClass1(Native Method)
> >>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> >>> at
> >>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> >>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> >>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> >>> at java.security.AccessController.doPrivileged(Native Method)
> >>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> >>> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> >>> at java.lang.Class.forName0(Native Method)
> >>> at java.lang.Class.forName(Class.java:191)
> >>> at begin_select_sleep.dbAccess(begin_select_sleep.java:39)
> >>> at begin_select_sleep.main(begin_select_sleep.java:21)
> >>>
> >>> $ java -version
> >>> java version "1.7.0_79"
> >>> OpenJDK Runtime Environment (IcedTea 2.5.6)
> (7u79-2.5.6-0ubuntu1.14.04.1)
> >>> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> >>>
> >>> Probably I should upgrade Java...
> >>>
> >>> Best regards,
> >>> --
> >>> Tatsuo Ishii
> >>> SRA OSS, Inc. Japan
> >>> English: http://www.sraoss.co.jp/index_en.php
> >>> Japanese:http://www.sraoss.co.jp
> >>>
> >>> > Tatsuo,
> >>> >
> >>> > Can you confirm it is fixed in this snapshot
> >>> >
> >>>
> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-1204-jdbc42-SNAPSHOT/
> >>> >
> >>> > Dave Cramer
> >>> >
> >>> > da...@postgresintl.com
> >>> > www.postgresintl.com
> >>> >
> >>> > On 23 October 2015 at 19:00, Dave Cramer  wrote:
> >>> >
> >>> >> Tatsuo,
> >>> >>
> >>> >> posting to jdbc list
> >>> >>
> >>> >> Dave Cramer
> >>> >>
> >>> >> da...@postgresintl.com
> >>> >> www.postgresintl.com
> >>> >>
> >>> >> On 23 October 2015 at 18:28, Tatsuo Ishii 
> >>> wrote:
> >>> >>
> >>> >>> It seems
> >>> >>> org.postgresql.Driver.setLogLevel(org.postgresql.Driver.DEBUG) does
> >>> >>> not work anymore in the newer JDBC driver.
> >>> >>>
> >>> >>> As far as I know, postgresql-9.2-1003.jdbc4.jar or
> >>> >>> postgresql-9.3-1104.jdbc41.jar work fine and produce following
> output
> >>> >>> for example:
> >>> >>>
> >>> >>> 16:36:36.459 (1) PostgreSQL 9.3 JDBC4.1 (build 1104)
> >>> >>> 16:36:36.464 (1) Trying to establish a protocol version 3
> connection
> >>> to
> >>> >>> localhost:11000
> >>> >>> 16:36:36.481 (1) Receive Buffer Size is 530904
> >>> >>> 16:36:36.481 (1) Send Buffer Size is 1313280
> >>> >>> 16:36:36.481 (1)  FE=>  StartupPacket(user=t-ishii, database=test,
> >>> >>> client_encoding=UTF8, DateStyle=ISO, TimeZone=Asia/Tokyo,
> >>> >>> extra_float_digits=2)
> >>> >>> 16:36:36.487 (1)<=BE AuthenticationOk
> >>> >>>
> >>> >>> However postgresql-9.4-1204.jdbc41.jar shows nothing.
> >>> >>>
> >>> >>> Best regards,
> >>> >>> --
> >>> >>> Tatsuo Ishii
> >>> >>> SRA OSS, Inc. Japan
> >>> >>> English: http://www.sraoss.co.jp/index_en.php
> >>> >>> Japanese:http://www.sraoss.co.jp
> >>> >>>
> >>> >>>
> >>> >>> 

[HACKERS] Proposal: Trigonometric functions in degrees

[Dean Rasheed]

Currently PostgreSQL only has trigonometric functions that work in
radians. I think it would be quite useful to have an equivalent set of
functions that worked in degrees. In other environments these are
commonly spelled sind(), cosd(), etc.

Partly, this would be a matter of convenience. It's quite common to
have a problem domain where angles are specified in degrees, and it's
somewhat cumbersome having to type things like sin(radians(x)) and
degrees(asin(x)).

Additionally, functions that worked natively in degrees would be able
to return exact answers in special cases like cosd(90) = 0, whereas
cos(radians(90)) is not exactly 0 because pi/2 cannot be represented
exactly as a floating point number.

Possibly the earthdistance module would benefit from these functions too.

Thoughts?

Regards,
Dean


-- 
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] Patch (2): Implement failover on libpq connect level.

[Robert Haas]

On Fri, Oct 23, 2015 at 4:02 PM, Korry Douglas
 wrote:
> When you call pg_is_in_recovery(), you should schema-qualify the function
> name, just in case some other version of that function exists in the
> search_path.

I wonder whether it's really a good idea to put this kind of logic
into libpq at all.  I think there was some previous votes against
doing so, and I tend to agree with that viewpoint.  Shouldn't probing
for the state of the connection be the caller's job, not libpq's?  If
somebody wants to write a wrapper function around this that runs this
query after connecting - or any other query - they can do so.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] Freeze avoidance of very large table.

[Masahiko Sawada]

On Sat, Oct 24, 2015 at 10:59 AM, Amit Kapila  wrote:
> On Mon, Oct 5, 2015 at 9:53 PM, Masahiko Sawada 
> wrote:
>>
>> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao 
>> wrote:
>> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada 
>> > wrote:
>> >>> +#define Anum_pg_class_relallfrozen12
>> >>> Why is pg_class.relallfrozen necessary? ISTM that there is no user of
>> >>> it now.
>> >>
>> >> The relallfrozen would be useful for user to estimate time to vacuum
>> >> freeze or anti-wrapping vacuum before being done them actually.
>> >> (Also this value is used on regression test.)
>> >> But this information is not used on planning like relallvisible, so it
>> >> would be good to move this information to another system view like
>> >> pg_stat_*_tables.
>> >
>> > Or make pgstattuple and pgstattuple_approx report even the number
>> > of frozen tuples?
>> >
>>
>> But we cannot know the number of frozen pages without installation of
>> pageinspect module.
>> I'm a bit concerned about that the all projects cannot install
>> extentension module into postgresql on production environment.
>> I think we need to provide such feature at least into core.
>>
>
> I think we can display information about relallfrozen it in pg_stat_*_tables
> as suggested by you.  It doesn't make much sense to keep it in pg_class
> unless we have some usecase for the same.
>

I'm thinking a bit about implementing the read-only table that is
restricted to update/delete and is ensured that whole table is frozen,
if this feature is committed.
The value of relallfrozen might be useful for such feature.

Regards,

--
Masahiko Sawada


-- 
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] Parallel Seq Scan

[Robert Haas]

On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch  wrote:
> Since that specification permits ParamListInfo consumers to ignore paramMask,
> the plpgsql_param_fetch() change from copy-paramlistinfo-fixes.patch is still
> formally required.

So why am I not just doing that, then?  Seems a lot more surgical.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers