gt; main backend related to wait start and wait end.
>
> I am not sure with out getting any signal or message from main backend,
> how much accurate the data can be gathered from a background worker.
It looks a sort of accuracy-performance trade-off.
So, I think the use-cases matter here to
should not cause assert even if queryId
already has non-zero value --- my module has this problem now.
Is my understanding correct? Any comments?
Regards,
--
NAGAYASU Satoshi
commit b975d7c2fe1b36a3ded1e0960be191466704e0fc
Author: Satoshi Nagayasu
Date: Sat Aug 8 08:51:45 2015 +
Fix
Hi,
I have created a patch for pg_filedump to work with 9.5.
Here is a list of changes.
* Fix to rename CRC32 macros to work with 9.5.
* Fix to add missing DBState: DB_SHUTDOWNED_IN_RECOVERY.
* Fix to add missing page flags for Btree and GIN.
* Update copyright date.
Please take a look. Any
On 2015/08/08 22:32, Robert Haas wrote:
On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu wrote:
I just found that pg_stat_statements causes assert when queryId is
set by other module, which is loaded prior to pg_stat_statements in
the shared_preload_libraries parameter.
Theoretically
2015-08-10 0:04 GMT+09:00 Robert Haas :
> On Sun, Aug 9, 2015 at 1:36 AM, Satoshi Nagayasu wrote:
>> On 2015/08/08 22:32, Robert Haas wrote:
>>> On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu wrote:
>>>>
>>>> I just found that pg_stat_statements cause
yet */
> if (query->queryId == 0)
> calculate_query_hash(query);
I vote for this too.
Jumble-calculation is the smartest way to identify query groups,
so several modules can take advantages of it if in the core.
Regards,
--
Satoshi Nagayasu
--
Hi,
I have a question on jumbling queries in pg_stat_statements.
I found that JumbleRangeTable() uses relation oid in
RangeTblEntry.
Obviously, this would result different queryid when the table
gets re-created (dropped and created).
Why don't we use relation name (with looking up the catalog)
On 2015/09/01 12:36, Peter Geoghegan wrote:
On Mon, Aug 31, 2015 at 8:32 PM, Satoshi Nagayasu wrote:
Why don't we use relation name (with looking up the catalog)
on query jumbling? For performance reason?
I think that there is a good case for preferring this behavior. While
it is a l
On 2015/09/01 13:41, Peter Geoghegan wrote:
On Mon, Aug 31, 2015 at 9:29 PM, Satoshi Nagayasu wrote:
BTW, I'm interested in improving the queryid portability now because
I'd like to use it in other extensions. :)
That's the reason why I'm looking at query jumbling here.
A
On 2015/09/01 14:01, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> On 2015/09/01 13:41, Peter Geoghegan wrote:
>>> If you want to use the queryId field directly, which I recall you
>>> mentioning before, then that's harder. There is simply no contract
>>>
On 2015/09/01 14:39, Satoshi Nagayasu wrote:
> On 2015/09/01 14:01, Tom Lane wrote:
>> Satoshi Nagayasu writes:
>>> On 2015/09/01 13:41, Peter Geoghegan wrote:
>>>> If you want to use the queryId field directly, which I recall you
>>>> mentioning befo
tch is WIP yet. But I'd like to hear the opinions about this idea
before completing it, and then add the patch to next CF if okay.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
(2013/08/30 12:07), Satoshi Nagayasu wrote:
(2013/08/30 11:55), Fujii Masao wrote:
Hi,
Attached patch adds new GUC parameter 'compress_backup_block'.
When this parameter is enabled, the server just compresses FPW
(full-page-writes) in WAL by using pglz_compress() before inserting
heap and btree in pgstat.stat would be preferred to reduce
read/write and to allow updating access statistics for specific tables
in pgstat.stat file.
Is this good for us?
Any comments or suggestions?
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via
Hi,
(2013/09/04 13:07), Alvaro Herrera wrote:
Satoshi Nagayasu wrote:
As you may know, this file could be handreds of MB in size, because
pgstat.stat holds all access statistics in each database, and it needs
to read/write an entire pgstat.stat frequently.
As a result, pgstat.stat often
Hi,
(2013/09/04 12:52), Atri Sharma wrote:
On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu wrote:
Hi,
I'm considering overhauling pgstat.stat, and would like to know how many
people are interested in this topic.
As you may know, this file could be handreds of MB in size, be
(2013/09/04 15:23), Atri Sharma wrote:
Sent from my iPad
On 04-Sep-2013, at 10:54, Satoshi Nagayasu wrote:
Hi,
(2013/09/04 12:52), Atri Sharma wrote:
On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu wrote:
Hi,
I'm considering overhauling pgstat.stat, and would like to know how
memory database fetures.
Yeah, I'm interested in this idea too.
If the stat collector has a dedicated connection to the backend in
order to store statistics into dedicated tables, we can easily take
advantages of index (btree, or hash?) and heap storage.
Is this worth trying?
Regards,
--
S
e we already have several index storages,
and it will allow us to minimize read/write operations.
BTW, what kind of index would be preferred for this purpose?
btree or hash?
If we use btree, do we need "range scan" thing on the statistics
tables? I have no idea so far.
Regards,
--
Satoshi
Hi,
The revised patch for wal buffer statistics is attached.
A test script is also attached. Please take a look.
Regards,
(2013/07/19 7:49), Satoshi Nagayasu wrote:
Will revise and re-resubmit for the next CF.
Regards,
2013/07/19 1:06, Alvaro Herrera wrote:
What happened to this patch
(2013/09/09 8:19), Tomas Vondra wrote:
On 8.9.2013 23:04, Jeff Janes wrote:
On Tue, Sep 3, 2013 at 10:09 PM, Satoshi Nagayasu
wrote:
Hi,
(2013/09/04 13:07), Alvaro Herrera wrote:
Satoshi Nagayasu wrote:
As you may know, this file could be handreds of MB in size,
because pgstat.stat
Thanks for checking. Revised one attached.
(2013/09/10 6:43), Peter Eisentraut wrote:
> On 9/6/13 11:32 PM, Satoshi Nagayasu wrote:
>> The revised patch for wal buffer statistics is attached.
>> A test script is also attached. Please take a look.
>
> You have duplicate
(2013/09/10 22:48), Peter Eisentraut wrote:
> On 9/10/13 3:37 AM, Satoshi Nagayasu wrote:
>> Thanks for checking. Revised one attached.
>
> Please fix compiler warning:
>
> walwriter.c: In function ‘WalWriterMain’:
> walwriter.c:293:3: warning: implicit
(2013/07/23 20:02), Greg Smith wrote:
> On 7/23/13 2:16 AM, Satoshi Nagayasu wrote:
>> I've been working on new pgstattuple function to allow
>> block sampling [1] in order to reduce block reads while
>> scanning a table. A PoC patch is attached.
>
> Take a look
(2013/09/15 11:07), Peter Eisentraut wrote:
On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote:
I'm looking forward to seeing more feedback on this approach,
in terms of design and performance improvement.
So, I have submitted this for the next CF.
Your patch fails to
) AS next_xlog_file,
...
pg_controldata('encoding')::text AS encoding;
Given that the view can work like a SRF, and it allows us to retrieve
all the values of pg_controldata with appropriate types in single
record from the view:
select * from pg_catalog.pg_controldata;
add a test case here, not only
for the view definition, but also working correctly.
Please take a look at attached one.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
diff --git a/src/test/regress/expected/stats.out
b/src/test/regress/expected/stats.out
index 56bace
g trigger
and non-existing table? Or just only for non-existing trigger?
I've not understood the pg_restore issue precisely so far,
but IMHO "DROP TRIGGER IF EXISTS" means "if the _trigger_ exists",
not "if the _table_ exists".
Is this a correct and/or an expec
(2013/10/11 7:32), Mark Kirkwood wrote:
> On 11/10/13 11:09, Mark Kirkwood wrote:
>> On 16/09/13 16:20, Satoshi Nagayasu wrote:
>>> (2013/09/15 11:07), Peter Eisentraut wrote:
>>>> On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote:
>>>>> I'
On 2015/10/03 6:18, Peter Geoghegan wrote:
On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu wrote:
I know this still needs to be discussed, but I would like to submit
a patch for further discussion at the next CF, 2015-11.
I think I already expressed this in my explanation of the current
(2013/06/17 4:02), Fujii Masao wrote:
On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu wrote:
It is obviously easy to keep two types of function interfaces,
one with regclass-type and another with text-type, in the next
release for backward-compatibility like below:
pgstattuple(regclass
functions for collecting
specific table/index statistics.
So, we can have similar feature in different modules.
Any comments?
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
applied to the latest HEAD.
I guess it need to have some fix, I couldn't clafiry it though.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ORMAL
-
Please check attached script to reproduce it.
Also, I have update the help message and README.
Please check attached patch.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
PGHOME=/tmp/pgsql
PGPORT=15433
function build_check {
echo
ment is more appropriate for passing
relation/index name to a function than text-type, but having both
arguments in each function seems to be a good choice at this moment,
in terms of backward-compatibility.
Docs needs to be updated if this change going to be applied.
Any comments?
--
Satoshi Naga
d patch to handle the issue in three functions
of the pgstattuple module. Please take a look.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
all_visible_percent | 99.98
It seems working fine.
And I added a regression test for pg_freespacemap and additional
test cases for pgstattuple. Please take a look.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
diff --git a/contrib/pg_freespacemap/Makefile b/cont
(2013/07/18 2:31), Fujii Masao wrote:
On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu wrote:
(2013/07/04 3:58), Fujii Masao wrote:
For the test, I just implemented the regclass-version of pg_relpages()
(patch attached) and tested some cases. But I could not get that problem.
SELECT
Will revise and re-resubmit for the next CF.
Regards,
2013/07/19 1:06, Alvaro Herrera wrote:
What happened to this patch? We were waiting on an updated version from
you.
Satoshi Nagayasu wrote:
(2012/12/10 3:06), Tomas Vondra wrote:
On 29.10.2012 04:58, Satoshi Nagayasu wrote:
2012/10
t;random" transactions,
and those update operations might not have any skew over the table,
so estimating table status seems to be easy in this test.
However, I'm still curious to know whether it would work in
"real-world" worklaod.
Is it worth having this? Any comment or sug
please check the attached test script.
Any comments?
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
[snaga@devsv03 postgresql.git]$ sh test_recovery.sh
createdb: database creation failed: ERROR: database "testdb" already exists
drop table if exists t1;
DR
f CFs this time, and I'd like to hear if
people think that helped.
The 5-day rule (and the notifications from CFM) seemed to be working
for me. It helped me focus on the patch review.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing
would be really helpful for DBA to make some critical decision.
I think PostgreSQL will be able to do that.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
#!/bin/sh
PGHOME=/tmp/pgsql
PGDATA=/tmp/pgsql/data
PATH=${PGHOME}/bin:${PATH}
export PGHOME PGDATA PATH
createdb
(2012/11/27 7:42), Alvaro Herrera wrote:
Satoshi Nagayasu escribió:
I attached the latest one, which splits the reset_time
for bgwriter and walwriter, and provides new system view,
called pg_stat_walwriter, to show the dirty write counter
and the reset time.
Thanks. I gave this a look and I
(2012/12/10 3:06), Tomas Vondra wrote:
On 29.10.2012 04:58, Satoshi Nagayasu wrote:
2012/10/24 1:12, Alvaro Herrera wrote:
Satoshi Nagayasu escribi�:
With this patch, walwriter process and each backend process
would sum up dirty writes, and send it to the stat collector.
So, the value could
bigint, instead of int,
when the scalefactor >= 20,000.
(aid columns would exeed the upper bound of int when sf>21474.)
Also, I added a few fixes on it.
- Fixed to apply for the current git master.
- Fixed to surpress few more warnings about INT64_FORMAT.
- Minor improvement in t
fers(), needs to be modified as well. Right?
With this additional fix, the patch could be applied to the
current git master, and could be compiled with --enable-cassert
option.
Then, I need some suggestion from hackers to continue this review.
How should I reproduce this message for review?
ed patch that
just adds the pattern support.
It seems working well with the latest git master.
I think it's good enough to be committed.
BTW, is there any good place to put new regression test for the psql
command? I couldn't find it out.
Any comment or suggestion?
Regards,
--
Sat
(2013/01/30 0:34), Tom Lane wrote:
> Satoshi Nagayasu writes:
>>> On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
>>>> Here is a patch for psql's \l command to accept patterns, like \d
>
>> BTW, is there any good place to put new regression te
of the blocks in the
table/index if the table/index is large (maybe 10GB or more).
It would allow us to run pgstattuple/pgstatindex easier.
Is it worth having?
Any comments?
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgs
(2013/02/15 1:55), Robert Haas wrote:
> On Tue, Feb 12, 2013 at 10:22 AM, Satoshi Nagayasu wrote:
>> (1) Fix pgstatindex arguments to work same as pgstattuple.
>>
>> As the document describes, pgstattuple accepts 'schema.table'
>> expression and oid
.test_pkey');
select * from pgstatindex('myschema.test_pkey');
select * from pgstatindex('myschema.test_pkey'::regclass::oid);
With attached patch, all functions in the pgstattuple module can
accept the same expression to specify the target relation/index.
Any comments or suggestion
terfaces
in the future release, maybe 9.4 or 9.5. I think this approach
would minimize an impact of such interface change.
So, I think we can clean up function arguments in the pgstattuple
module, and also we can have two interfaces, both regclass and text,
for the next release.
Any comments?
Rega
larger block size, like 256kB, would take
advantage of the SSD performance because of the block management
within SSD.
So, I'm just curious to know that.
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
r comments?
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
/or (b) a context type that could provide
> better allocation speed at a loss of storage efficiency (eg, lose the
> ability to pfree individual chunks). Case (a) has never become
> practical given the inability of SysV-style shared memory to expand at
> all. I don't know if tha
on its development
and enough eyeballs to maintain, it's ok to be an independent project.
However when a tool have already got matured with less eyeballs,
it needs to be merged into this umbrella project.
Any comments?
>
> Sakamoto
>
>
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bhost4
[snaga@devvm03 libpq_repli]$
--------
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 9eaf410..14e31b6 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -569,
eb?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
> -BEGIN PGP SIGNATURE-
>
> iEYEAREDAAYFAlBeg/AACgkQvJuQZxSWSsjL5ACgimT71B4lSb1ELhgMw5EBzAKs
> xHIAn08vxGzmM6eSmDfZfxlJDTousq7h
> =KgXW
> -END PGP SIGNATURE-
>
>
>
>
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
apps again and again, it's time to consider
implementing it to deliver and/or leverage with the potential
of PostgreSQL replication.
Regards,
On 2012-09-23 10:01 AM, "Euler Taveira" mailto:eu...@timbira.com>> wrote:
On 23-09-2012 07:50, Satoshi Nagayasu wrote:
>
ally, rebuilding tables and/or indexes has
a trade-off between "lock-free" and "disk-space".
So, if we have enough disk space to build a "temporary"
table/index when rebuilding a table/index, "concurrently"
would be a great option, and I would love it to have
Hi,
2012/08/12 7:11, Jeff Janes wrote:
On Sat, Jul 28, 2012 at 3:33 PM, Jeff Janes wrote:
On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu wrote:
Hi,
Jeff Janes has pointed out that my previous patch could hold
a number of the dirty writes only in single local backend, and
it could not
get_lwlocks() New function to retrieve lwlock statistics.
>pg_stat_reset_lwlocks() New function to reset lwlock statistics.
>
> Please try it out.
>
> Regards,
>
> 2012/06/26 5:29, Satoshi Nagayasu wrote:
>> Hi all,
>>
>> I've been working on a new syst
Hi,
2012/10/13 23:05, Satoshi Nagayasu wrote:
> Hi all,
>
> I have fixed my previous patch for pg_stat_lwlocks view, and
> as Josh commented, it now supports local and global (shared)
> statistics in the same system view.
Sorry, I found my mistakes. New fixed one is attach
Thanks for the review.
2012/10/14 8:55, Michael Paquier wrote:
On Sun, Oct 14, 2012 at 6:00 AM, Fujii Masao mailto:masao.fu...@gmail.com>> wrote:
On Sun, Oct 14, 2012 at 3:34 AM, Fujii Masao mailto:masao.fu...@gmail.com>> wrote:
> On Sat, Oct 13, 2012 at 11:34 PM, S
(2012/10/14 13:26), Fujii Masao wrote:
On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu wrote:
HEAD
number of transactions actually processed: 3439971
tps = 57331.891602 (including connections establishing)
tps = 57340.932324 (excluding connections establishing)
pg_stat_lwlocks patch
2012/10/15 1:43, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> (2012/10/14 13:26), Fujii Masao wrote:
>>> The tracing lwlock usage seems to still cause a small performance
>>> overhead even if reporting is disabled. I believe some users would
>>> p
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
The tracing lwlock usage seems to still cause a small performance
overhead even if reporting is disabled. I believe some users would
prefer to
2012/10/19 4:36, Robert Haas wrote:
On Tue, Oct 16, 2012 at 11:31 AM, Satoshi Nagayasu wrote:
A flight-recorder must not be disabled. Collecting
performance data must be top priority for DBA.
This analogy is inapposite, though, because a flight recorder rarely
crashes the aircraft. If it
2012/10/19 23:48, Fujii Masao wrote:
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu wrote:
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
The tracing lwlock usage seems to still
2012/10/20 2:45, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> Ok, I guess we have reached the consensus to have
>> "some flight-recorder". Right?
>
> I remain unconvinced. I think the argument that this will promote
> novice understanding is complete hogwash:
2012/10/24 1:12, Alvaro Herrera wrote:
Satoshi Nagayasu escribió:
With this patch, walwriter process and each backend process
would sum up dirty writes, and send it to the stat collector.
So, the value could be saved in the stat file, and could be
kept on restarting.
The statistics could be
sometimes the thing you really need
to look at is not in the list of most frequent queries.
I think auto_explain would help you solve such rare incidents
if it could dump several statistics into server log, including lock
waits and block reads/writes statistic per-session, for example.
Do we
ockId itself. But LWLockId is
not easy for DBA to determine actual lock type.
So, I want to show LWLock names (or labels), like 'WALWriteLock'
or 'LockMgrLock', but how should I implement it?
Any comments?
Regards,
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://w
2012/06/26 6:44, Josh Berkus wrote:
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the patch,
and confirmed that this patch does not affect the LWLock perfomance
at all.
This would be my main concern with this
2012/06/26 7:04, Kevin Grittner wrote:
Josh Berkus wrote:
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the
patch, and confirmed that this patch does not affect the LWLock
perfomance at all.
This would be my
locks() New function to reset lwlock statistics.
Please try it out.
Regards,
2012/06/26 5:29, Satoshi Nagayasu wrote:
> Hi all,
>
> I've been working on a new system view, pg_stat_lwlocks, to observe
> LWLock, and just completed my 'proof-of-concept' code that can work
&
--
(1 row)
postgres=# SELECT pg_stat_get_xlog_dirty_write();
pg_stat_get_xlog_dirty_write
--
0
(1 row)
postgres=# \q
[snaga@devvm03 src]$
-------
--
Satoshi Nagayasu
Uptim
2012/07/07 22:07, Euler Taveira wrote:
> On 07-07-2012 09:00, Satoshi Nagayasu wrote:
>> I've created new patch to get/reset statistics of WAL buffer
>> writes (flushes) caused by WAL buffer full.
>>
> This new statistic doesn't solve your problem (tune wal_b
o
the shared memory, as a member of XLogCtlWrite, to keep total
dirty writes in the cluster.
Regards,
2012/07/07 21:00, Satoshi Nagayasu wrote:
> Hi all,
>
> I've created new patch to get/reset statistics of WAL buffer
> writes (flushes) caused by WAL buffer full.
>
>
It would mean that the users using older major version could not take
advantage of new features and enhancements of the latest xlogdump,
but it's not what I wanted, actually.
Regards,
Greetings,
Andres
--
Satoshi Nagayasu
Uptime Technologies, LLC. http://www.uptime.jp
--
Se
a pain
in the neck.
Does it make sense to make some static library which can be
referred from both the backend and several client utilities,
including libpq? Or just a dynamic link be preferred?
Despite I do not have a clear idea right now, is it time to
start thinking of it?
Regards,
--
Satosh
Hi,
On 2014/12/12 23:13, Heikki Linnakangas wrote:
> Hi,
>
> I'd like to include pg_rewind in contrib. I originally wrote it as an
> external project so that I could quickly get it working with the
> existing versions, and because I didn't feel it was quite ready for
> production use yet. Now, wi
On 2014/12/16 18:37, Heikki Linnakangas wrote:
On 12/16/2014 11:23 AM, Satoshi Nagayasu wrote:
pg_rewind assumes that the source PostgreSQL has, at least, one
checkpoint after getting promoted. I think the target timeline id
in the pg_control file to be read is only available after the first
Hi hackers,
I'm pleased to announce the latest release of xlogdump.
xlogdump is a tool for extracting data from WAL segment files.
Here is xlogdump README:
https://github.com/snaga/xlogdump/blob/master/xlogdump/README.xlogdump
xlogdump was originally developed by Tom Lane and Diogo Biazus around
ommit afffca193b69ea5eb42f5e7273d48a6a82eb7e37
Author: Satoshi Nagayasu
Date: Thu Jul 9 03:42:31 2015 +
Fix to expose "Log_disconnections" GUC variable to the outside postgres.c.
diff --git a/src/include/postmaster/postmaster.h
b/src/include/postmaster/postmaster.h
index d160304.
On 2015/07/09 13:06, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> I just found that Log_disconnections value has not been
>> exposed to outside of postgres.c.
>> Despite that, Log_connections has already been exposed.
>
> Why would an external module need to
On 2015/07/09 15:30, Heikki Linnakangas wrote:
> On 07/09/2015 07:19 AM, Satoshi Nagayasu wrote:
>>
>> On 2015/07/09 13:06, Tom Lane wrote:
>>> Satoshi Nagayasu writes:
>>>> I just found that Log_disconnections value has not been
>>>> exp
. You might want to compare the behaviour
> with other cases where value of nloops is used.
>
>> Is it a bug?
>>
>
> I don't think so.
I would like to propose a few modification for parallel queries to
make it more clear.
>>-> Parallel Seq Scan on public.pg
static/sql-createfunction.html
--
Satoshi Nagayasu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
procedure?
Regards,
[1] http://madlib.incubator.apache.org/
--
Satoshi Nagayasu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2016-07-21 13:53 GMT+09:00 Alvaro Herrera :
> Satoshi Nagayasu wrote:
>> Hi,
>>
>> I have been trying MADlib [1], a machine-learning library for PostgreSQL,
>> and when I was tying it on 9.5 and 9.6beta2, I often got f
lease the next major release
saying 10.0 with the wait monitoring, many people will start their
benchmark test
with a configuration with *the default values*, and if they see some performance
decrease, for example around 10%, they will be talking about it as the
performance
decrease in PostgreSQL 10.0.
ly
> non-production ready code into mission-critical production for such tests.
>As a result it will be clear if this design should be abandoned and we
> need to think about less-invasive solutions or this design is acceptable.
>
> Any thoughts?
Seems a good starting point. I&#x
2016/08/10 23:22 "Bruce Momjian" :
>
> On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote:
> > On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian wrote:
> >
> > On Tue, Aug 9, 2016 at 02:06:40AM +, Tsunakawa, Takayuki wrote:
> > > I hope wait event monitoring will be on by
2012/01/11 19:56, Simon Riggs wrote:
2012/1/11 Euler Taveira de Oliveira:
On 08-01-2012 11:59, Satoshi Nagayasu / Uptime Technologies, LLC. wrote:
[2011-12-08 15:14:36 JST] 16758: LOG: restored log file
"00080046" from archive
[2011-12-08 15:14:36 JST]
2012/01/13 0:13, Robert Haas wrote:
On Thu, Jan 12, 2012 at 10:04 AM, Simon Riggs wrote:
On Thu, Jan 12, 2012 at 2:13 PM, Robert Haas wrote:
On Wed, Jan 11, 2012 at 9:01 AM, Simon Riggs wrote:
On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu wrote:
However, I'm a bit afraid th
Tom,
>> Yes. It's pure overhead with no redeeming social value except to those
>> who actually want to look at that sort of stat, and those who do can
>> certainly turn it on for themselves.
I think the stats stuff should be on by default even if it causes
some performance penalty.
Because when
Mark,
Very interesting. I'm looking for such tool.
Unfortunately, I can't compile it on my Solaris right now,
but I hope it will be shipped with PostgreSQL distribution.
Mark Wong wrote:
Hi everyone,
I was playing with converting unixtop (the version of top used in
FreeBSD) to only show Postg
Hi all,
I'm hacking on PalmOS handhelds to implements libpq
called "libpq for PalmOS".
This library provides many compatible libpq functions
to manipulate PostgreSQL server from PalmOS devices
through TCP/IP connection.
Implementation is almost done, but some works are left
to release.
For exa
1 - 100 of 180 matches
Mail list logo
