Hi,
I'm thinking of adding new probes to trace smgr activities.
In this implementation, I just found that md.c has its own probes
within it, but I'm wondering why we do not have those probes
within the generic smgr routines itself.
Which would be a better choice?
Any ideas or comments?
From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
on behalf of Peter Eisentraut [pete...@gmx.net]
Sent: Friday, July 27, 2012 10:39 AM
It seems strange that the external_pid_file is never removed. There is
even a C comment about it:
/* Should we remove the pid
On Fri, Jul 27, 2012 at 08:29:20AM -0400, Robert Haas wrote:
Yes, that would be a problem because the WAL records are deleted by
pg_upgrade. Does a shutdown of the standby not already replay all WAL
logs? We could also just require them to just start the standby in
master mode and shut
Hello
2012/7/27 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2012/7/26 David Fetter da...@fetter.org:
How about
\gset var1,,,var2,var3...
I don't like this - you can use fake variable - and ignoring some
variable has no big effect on client
Why assign to a
Satoshi Nagayasu sn...@uptime.jp writes:
Hi,
I'm thinking of adding new probes to trace smgr activities.
In this implementation, I just found that md.c has its own probes
within it, but I'm wondering why we do not have those probes
within the generic smgr routines itself.
IMV smgr is pretty
Amit kapila amit.kap...@huawei.com writes:
I think it should be removed with proc_exit hook just like the main
postmaster.pid file.
external_pid_file is created first time when it is enabled in postgresql.conf
I think it should be removed once the parameter external_pid_file is unset;
On Jul 27, 2012, at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm. We have seen similar symptoms reported by people using broken
openssl installations. I've never tracked down the details but I
suspect header-vs-library mismatches. Is it possible there are some
pre-ML openssl-related
On Fri, 2012-07-27 at 15:27 -0500, Merlin Moncure wrote:
The covering index/uniqueness use case adds
legitimacy to the INDEX clause of exclusion constraints IMNSHO.
Yes, I think it would be worth revisiting the idea.
One point of concern though is that (following a bit of testing)
alter
The bitmap heap scan can benefit quite a bit from
effective_io_concurrency on RAID system (and to some extent even on
single spindle systems)
However, the planner isn't aware of this. So you have to just be
lucky to have it choose the bitmap heap scan instead of something else
that can't benefit
On 23.07.2012 10:37, Alexander Korotkov wrote:
On Fri, Jul 20, 2012 at 3:48 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would be nice to have an introduction, perhaps as a file comment at the
top of rangetypes_spgist.c, explaining how the quad tree works. I have a
On Fri, Jul 27, 2012 at 1:27 PM, Merlin Moncure mmonc...@gmail.com wrote:
One point of concern though is that (following a bit of testing)
alter table foo add exclude using btree (id with =);
...is always strictly slower for inserts than
alter table foo add primary key(id);
This is probably
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Also, I wonder if we really need to reconstruct the previous value in
a RANGESTRAT_ADJACENT search. ISTM we only need to remember which of the
two lines we are chasing. For example, if you descend to quadrant 2
because there
On 29.07.2012 00:50, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Also, I wonder if we really need to reconstruct the previous value in
a RANGESTRAT_ADJACENT search. ISTM we only need to remember which of the
two lines we are chasing. For example, if you
On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu sn...@uptime.jp 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 hold all over the cluster, because the counter
was allocated in the local
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 29.07.2012 00:50, Tom Lane wrote:
We could possibly extend the API to allow a different type to be used
for this, but then it wouldn't be reconstructed data in any sense of
the word; so I think it'd be abuse of the concept ---
On 28 July 2012 17:15, Tom Lane t...@sss.pgh.pa.us wrote:
IMV smgr is pretty vestigial. I wouldn't recommend loading more
functionality onto that layer, because it's as likely as not that
we'll just get rid of it someday.
Agreed. I recently found myself reading a paper written by Stonebraker
Peter Geoghegan pe...@2ndquadrant.com writes:
On 28 July 2012 17:15, Tom Lane t...@sss.pgh.pa.us wrote:
IMV smgr is pretty vestigial. I wouldn't recommend loading more
functionality onto that layer, because it's as likely as not that
we'll just get rid of it someday.
Agreed. I recently
From: Tom Lane [t...@sss.pgh.pa.us]
Sent: Saturday, July 28, 2012 9:46 PM
Amit kapila amit.kap...@huawei.com writes:
I think it should be removed with proc_exit hook just like the main
postmaster.pid file.
external_pid_file is created first time when it is enabled in postgresql.conf
I think
Hello
I am returning to topic, that I opened with discussion about enhancing
protocol to support access to host variables.
There was a second idea about joining host variables and session
variables. This can be implemented without protocol enhancing, but it
is only one way tool - we are able
19 matches
Mail list logo
