Hello Amit,
In the example
>create table part201606week4 partition of parted
>for values start (2016, 6, 2) end (2016, 6, 29);
seems to be a typo
regards
Sameer
--
View this message in context:
http://postgresql.nabble.com/Declarative-partitioning-tp5862462p5903204.html
Sent from the
Hello,
Continuing testing:
For pg_syncinfo.conf below an error is thrown.
{
"sync_info":
{
"quorum": 3,
"nodes":
Hello,
I did apply the patch to HEAD and tried to setup basic async replication.But
i got an error. Turned on logging for details below.
Unpatched Primary Log
LOG: database system was shut down at 2015-09-12 13:41:40 IST
LOG: MultiXact member wraparound protections are now enabled
LOG:
Hello,
Your current design completely misses the time taken to scan indexes, which
is significant.
I tried to address this issue in the attached patch.
The patch calculates index scan progress by measuring against scanned pages
in LVRelStats. It checks for a change current page being scanned and
Hello,
Thank you for suggestion. The design with hooks and a separate view was
mainly to keep most of the code outside core as the feature proposed is
specific to VACUUM command. Also, having a separate view can give more
flexibility in terms of displaying various progress parameters.
FWIW ,there
Hello,
Well, speaking of the two-arg form vs alternate name, here's a version of
the patch which includes the new behavior
Thought i will attempt a review.
The patch applies cleanly to latest HEAD.
patch -p1
/home/Sameer/Downloads/0001-Add-two-arg-form-of-current_setting-to-optionally-su.patch
Hello,
I applied the patch to current HEAD. There was one failure (attached),
freelist.rej
http://postgresql.1045698.n5.nabble.com/file/n5804200/freelist.rej
Compiled the provided pgbench.c and added following in .conf
shared_buffers = 128MB # min 128kB
Shared_buffers=64MB
Hello,
What kind of error did you get at the server crash? Assertion error? If yes,
it might be because of the conflict with
4a170ee9e0ebd7021cb1190fabd5b0cbe2effb8e.
This commit forbids palloc from being called within a critical section, but
the patch does that and then the assertion error
Hello,
Done. Attached is the updated version of the patch.
I was trying to check WAL reduction using this patch on latest available git
version of Postgres using JDBC runner with tpcc benchmark.
patching_problems.txt
http://postgresql.1045698.n5.nabble.com/file/n5803482/patching_problems.txt
On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov
sergey.k.murav...@gmail.com wrote:
Hi.
I've improved the patch.
It works in expanded mode when either format option is set to wrapped (\pset
format wrapped), or we have no pager, or pager doesn't chop long lines (so
you can still use the
I've cleaned this up - revision attached - and marked it ready for
committer.
Thank you for this.
I did the basic hygiene test. The patch applies correctly and compiles
with no warnings. Did not find anything broken in basic functionality.
In the documentation i have a minor suggestion of
Hello,
Please find v10 of patch attached. This patch addresses following
review comments
1. Removed errcode and used elogs for error pg_stat_statements schema
is not supported by its binary
2. Removed comments and other code formatting not directly relevant to
patch functionality
3. changed
Hello,
Tried to test this patch. Did the following
1. cloned from https://github.com/samthakur74/postgres
2. Applied patch and make install
3. created rolesapp_readonly_role,app2_writer_role
4. Tried createuser -D -S -l -g app_readonly_role,app2_writer_role
test_user got error: createuser: invalid
1. cloned from https://github.com/samthakur74/postgres
Sorry. cloned from https://github.com/postgres/postgres
regards
Sameer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I took a quick look. Observations:
+ /* Making query ID dependent on PG version */
+ query-queryId |= PG_VERSION_NUM 16;
If you want to do something like this, make the value of
PGSS_FILE_HEADER incorporate (PG_VERSION_NUM / 100) or something.
Why are you doing this?
The thought was
Hello,
Please find attached pg_stat_statements-identification-v9.patch.
I have tried to address the following review comments
1. Use version PGSS_TUP_V1_2
2.Fixed total time being zero
3. Remove 'session_start' from the view and use point release number
to generate queryid
4. Hide only queryid and
This paragraph reads a bit strange to me:
+ A statistics session is the time period when statistics are gathered by
statistics collector
+ without being reset. So a statistics session continues across normal
shutdowns,
+ but whenever statistics are reset, like during a crash or upgrade,
Please find patch attached which adds documentation for session_start
and introduced fields and corrects documentation for queryid to be
query_id. session_start remains in the view as agreed.
regards
Sameer
pg_stat_statements-identification-v8.patch.gz
Description: GNU Zip compressed data
--
Please find the patch attached
Thanks for the patch! Here are the review comments:
+OUT session_start timestamptz,
+OUT introduced timestamptz,
The patch exposes these columns in pg_stat_statements view.
These should be documented.
Yes, will add to documentation.
I don't think
On Sat, Oct 5, 2013 at 1:38 PM, Daniel Farina dan...@heroku.com wrote:
On Fri, Oct 4, 2013 at 7:22 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Oct 3, 2013 at 5:11 PM, Sameer Thakur samthaku...@gmail.com wrote:
On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur samthaku...@gmail.com wrote
On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur samthaku...@gmail.com wrote:
Looks pretty good. Do you want to package up the patch with your
change and do the honors and re-submit it? Thanks for helping out so
much!
Sure, will do. Need to add a bit of documentation explaining
statistics
Looks pretty good. Do you want to package up the patch with your
change and do the honors and re-submit it? Thanks for helping out so
much!
Sure, will do. Need to add a bit of documentation explaining
statistics session as well.
I did some more basic testing around pg_stat_statements.max, now
On Tue, Oct 1, 2013 at 12:48 AM, Daniel Farina-5 [via PostgreSQL]
ml-node+s1045698n5772887...@n5.nabble.com wrote:
On Sep 30, 2013 4:39 AM, Sameer Thakur [hidden email] wrote:
Also, for onlookers, I have changed this patch around to do the
date-oriented stuff but want to look it over before
On Tue, Oct 1, 2013 at 12:48 AM, Daniel Farina-5 [via PostgreSQL]
ml-node+s1045698n5772887...@n5.nabble.com wrote:
On Sep 30, 2013 4:39 AM, Sameer Thakur [hidden email] wrote:
Also, for onlookers, I have changed this patch around to do the
date-oriented stuff but want to look it over before
Also, for onlookers, I have changed this patch around to do the
date-oriented stuff but want to look it over before stapling it up and
sending it. If one cannot wait, one can look at
https://github.com/fdr/postgres/tree/queryid. The squashed-version of
that history contains a reasonable
On Mon, Sep 23, 2013 at 1:26 PM, samthakur74 samthaku...@gmail.com wrote:
I forgot about removal of the relevant SGML, amended here in v6.
Thank you for this!
i did a quick test with following steps:
1. Applied v6 patch
2. make and make install on pg_stat_statements;
3. Restarted Postgres
Attached patch combines documentation patch and source-code patch.
I have had a stab at reviewing the documentation. Have a look.
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1749,6 +1749,50 @@ include 'filename'
/listitem
/varlistentry
+
You seem to have forgotten to include the pg_stat_statements--1.2.sql
and pg_stat_statements--1.1--1.2.sql in the patch.
Sorry again. Please find updated patch attached.
I did not add pg_stat_statements--1.2.sql. I have added that now and
updated the patch again.
The patch attached should
Hello All,
I am trying to revive the discussion about exposing queryid in
pg_stat_statements.
I did find the same request posted on hackers @
http://www.postgresql.org/message-id/CABUevExLnb6xJwS=8rTaLOfDOS-tFm09==z2m_vz5hhfkgw...@mail.gmail.com
and
On Fri, Apr 12, 2013 at 9:52 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-04-12 12:14:24 -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/12/2013 10:15 AM, Tom Lane wrote:
There's 0 chance of making that work, because the two databases
wouldn't
have
Hello,
The current process of transferring data files from one cluster to another
by using pg_dump and pg_restore is time consuming.
The proposed tool tries to make migration faster for tables and indices
only by copying their binary data files. This is like pg_upgrade but used
for migration of
Hello,
The only potential use case for this that I can see, would be for system
maintenance and a controlled failover. I agree: that's a major PITA when
doing DR testing, but I personally don't think this is the way to fix that
particular edge case.
This is the use case we are trying to address
32 matches
Mail list logo
