On Wed, Feb 8, 2012 at 12:19 PM, Chetan Suttraway <
chetan.suttra...@enterprisedb.com> wrote:
>
>
> On Wed, Feb 8, 2012 at 8:15 AM, Robert Haas wrote:
>
>> On Tue, Feb 7, 2012 at 4:25 PM, Peter Eisentraut wrote:
>> > On ons, 2012-02-01 at 15:53 +0530, Chetan Suttraway wrote:
>> >> This is regard
On Wed, Feb 8, 2012 at 8:15 AM, Robert Haas wrote:
> On Tue, Feb 7, 2012 at 4:25 PM, Peter Eisentraut wrote:
> > On ons, 2012-02-01 at 15:53 +0530, Chetan Suttraway wrote:
> >> This is regarding the TODO item :
> >> "Add SPI_gettypmod() to return a field's typemod from a TupleDesc"
> >
> > My fi
Hello, sujayr06.
You wrote:
s> Hello All,
s>My application has to do a real time data upload to PostgreSQL
s> server.
s>Every time i have to do a real time upload, i do not wish to open
s> new connection.
s>I want to open a connection once [when my applicati
On Tue, Feb 7, 2012 at 8:44 PM, Kevin Grittner
wrote:
> Chetan Suttraway wrote:
>
> > This is regarding the TODO item:
> > "Prevent the specification of conflicting transaction read/write
> > options"
> >
> > listed at:
> > http://wiki.postgresql.org/wiki/Todo
>
> Thanks for chipping away at item
On Feb 8, 2012 5:32 AM, "Tom Lane" wrote:
>
> Bruce Momjian writes:
> > How do people feel about pulling text out of the SGML docs and loading
> > it into the database as table and column comments?
>
> I'm not thrilled by that proposal. The length limits on comments are
> very much shorter than
(2012/02/07 23:44), Marko Kreen wrote:
> On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
>> - What is the right (or recommended) way to prevent from throwing
>> exceptoin in row-processor callback function? When author should use
>> PG_TRY block to catch exception in the callback f
Bruce Momjian writes:
> How do people feel about pulling text out of the SGML docs and loading
> it into the database as table and column comments?
I'm not thrilled by that proposal. The length limits on comments are
very much shorter than what is sensible to use in catalogs.sgml (at
least if yo
Marti Raudsepp writes:
> Case #1 uses the normal textcat(text, text) operator by automatically
> coercing 'x' as text.
> However, case #2 uses the anytextcat(anynonarray, text), which is
> marked as volatile thus acts as an optimization barrier.
Hmm ... since those operators were invented (in 8.3
On Mon, Jan 16, 2012 at 01:01:50PM -0300, Alvaro Herrera wrote:
>
>
> Bruce had a patch to turn SGML descriptions of system view into comments
> via some Perl program or something. He posted it many moons ago and I
> haven't seen an updated version. Bruce, do you have something to say on
> this
On Thu, Jan 19, 2012 at 09:42:52PM -0500, Robert Haas wrote:
> I certainly didn't intend to come across as disparaging your work on
> this topic. I understand that there are big problems with the way
> things work now; I'm just cautious about trying to replace them too
> hastily with something tha
On Thu, Jan 19, 2012 at 05:39:41PM -0500, Greg Smith wrote:
> On 1/19/12 1:10 PM, Robert Haas wrote:
> >I have to say that I find that intensely counterintuitive. The
> >current settings are not entirely easy to tune correctly, but at least
> >they're easy to explain.
>
> I attempt to explain tho
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
> > On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
> > This patch uses FPIs to guard against torn hint writes, even when the
> > checksums are disabled. ?One could not s
On Tue, Feb 7, 2012 at 4:59 PM, Robert Haas wrote:
> It turns out that (as you anticipated) there are some problems with my
> previous proposal.
I assume you're talking to Tom, as my powers of anticipation are
actually quite limited... :-)
> This is not
> quite enough to get rid of g_conn, but i
On Tue, Feb 07, 2012 at 09:38:39PM -0500, Robert Haas wrote:
> So we need some principled way of deciding how much inlining is
> reasonable, because I am 100% certain this is not going to be the last
> time someone discovers that a massive exercise in inlining can yield a
> nifty performance benefi
On Tue, Feb 7, 2012 at 8:02 PM, Bruce Momjian wrote:
> On Wed, Feb 01, 2012 at 08:19:24PM +0200, Peter Eisentraut wrote:
>> On tis, 2012-01-17 at 16:46 +0900, Fujii Masao wrote:
>> > When I tested the patch, "create ta" was converted unexpectedly to
>> > "create TABLE"
>> > though "alter ta" was s
On Tue, Feb 7, 2012 at 4:25 PM, Peter Eisentraut wrote:
> On ons, 2012-02-01 at 15:53 +0530, Chetan Suttraway wrote:
>> This is regarding the TODO item :
>> "Add SPI_gettypmod() to return a field's typemod from a TupleDesc"
>
> My first thought was, this should be spelled SPI_gettypmod(). Not sur
On Tue, Feb 7, 2012 at 8:45 PM, Noah Misch wrote:
> On Tue, Feb 07, 2012 at 12:43:11PM -0500, Robert Haas wrote:
>> I've committed the numeric and varbit patches and will look at the
>> temporal one next.
>
> Thanks. The comment you added to numeric_transform() has a few typos,
> "constained" ->
On Tue, Feb 7, 2012 at 2:39 PM, Jay Levitt wrote:
> Jim "Decibel!" Nasby wrote:
>>
>> I agree that it's probably pretty unusual to index floats.
>
> FWIW: Cubes and points are floats, right? So would spatial indexes benefit
> from this optimization, or is it only raw floats?
Cubes are not floats,
On Tue, Feb 07, 2012 at 12:43:11PM -0500, Robert Haas wrote:
> I've committed the numeric and varbit patches and will look at the
> temporal one next.
Thanks. The comment you added to numeric_transform() has a few typos,
"constained" -> "constrained" and "nodes" -> "notes".
> I did notice one od
On Wed, Feb 01, 2012 at 08:19:24PM +0200, Peter Eisentraut wrote:
> On tis, 2012-01-17 at 16:46 +0900, Fujii Masao wrote:
> > When I tested the patch, "create ta" was converted unexpectedly to
> > "create TABLE"
> > though "alter ta" was successfully converted to "alter table". As far
> > as I read
On Tue, Feb 07, 2012 at 05:06:18PM -0500, Greg Smith wrote:
> On 02/07/2012 03:23 PM, Bruce Momjian wrote:
> >Where did you see that there will be an improvement in the 9.2
> >documentation? I don't see an improvement.
>
> I commented that I'm hoping for an improvement in the documentation
> of h
On Mon, Jan 09, 2012 at 01:32:49PM -0500, Robert Haas wrote:
> > The one other issue I ran into in following the latest pgindent
> > instructions was that I had to add #include to the
> > parse.c file (as included in the pg_bsd_indent-1.1.tar.gz file at
> > ftp://ftp.postgresql.org/pub/dev ). Wit
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an improvement in the documentation of
how much timing overhead impacts attempts to measure this area better.
On 02/07/2012 02:56 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
Here's a possible patch for the exclude-table-data problem along the
lines you suggest.
Should I apply this?
I'm not happy with this yet. My core complaint is that pg_dump used to
On ons, 2012-02-01 at 15:53 +0530, Chetan Suttraway wrote:
> This is regarding the TODO item :
> "Add SPI_gettypmod() to return a field's typemod from a TupleDesc"
My first thought was, this should be spelled SPI_gettypmod(). Not sure
what others think.
--
Sent via pgsql-hackers mailing list
On 02/03/2012 11:41 PM, Jeff Janes wrote:
-The steady stream of backend writes that happen between checkpoints have
filled up most of the OS write cache. A look at /proc/meminfo shows around
2.5GB "Dirty:"
"backend writes" includes bgwriter writes, right?
Right.
Has using a newer kernal wit
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
> On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
>> v7
Thanks very much for the review. Just realised I hadn't actually replied...
> This patch uses FPIs to guard against torn hint writes, even when the
> checksums are disabled. O
On 02/07/2012 03:36 PM, Marti Raudsepp wrote:
On Tue, Feb 7, 2012 at 22:31, Andrew Dunstan wrote:
It gets worse if you replace the expression with a call to a (non-sql)
function returning text, which was in fact the original use case. Then
you're pretty much hosed.
Oh, if it's a non-SQL fun
On Tue, Feb 7, 2012 at 22:31, Andrew Dunstan wrote:
> It gets worse if you replace the expression with a call to a (non-sql)
> function returning text, which was in fact the original use case. Then
> you're pretty much hosed.
Oh, if it's a non-SQL function then marking it as STABLE/IMMUTABLE
sho
On 02/07/2012 03:18 PM, Marti Raudsepp wrote:
Hi list,
Andrew Dunstan reported an awkward-seeming case on IRC where shifting
around a concatenation expression in a view made the planner choose a
good or a bad execution plan.
Simplified, it boils down to this:
db=# create table foo(i int);
db
On Wed, Jan 11, 2012 at 08:26:52AM +, Benedikt Grundmann wrote:
> (replying just to you)
> On 10/01/12 15:22, Greg Smith wrote:
> > On 1/5/12 5:04 AM, Benedikt Grundmann wrote:
> > That sort of thing is one reason why all attempts so far to set
> > random_page_cost based on physical characteris
Hi list,
Andrew Dunstan reported an awkward-seeming case on IRC where shifting
around a concatenation expression in a view made the planner choose a
good or a bad execution plan.
Simplified, it boils down to this:
db=# create table foo(i int);
db=# explain verbose select i from (select i, i::tex
Andrew Dunstan writes:
> On 02/07/2012 12:47 PM, Tom Lane wrote:
>> In general I think we'd have to require that colnames be supplied in all
>> RowExprs if we go this way. Anyplace that's trying to slide by without
>> will have to be fixed. I don't recall how many places that is.
> I just had a
Andrew Dunstan writes:
> On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
>> Here's a possible patch for the exclude-table-data problem along the
>> lines you suggest.
> Should I apply this?
I'm not happy with this yet. My core complaint is that pg_dump used to
consider that creation of a TableDa
On 02/07/2012 12:47 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/16/2011 10:38 PM, Tom Lane wrote:
Upon further review, this patch would need some more work even for the
RowExpr case, because there are several places that build RowExprs
without bothering to build a valid colnames list.
Jim "Decibel!" Nasby wrote:
I agree that it's probably pretty unusual to index floats.
FWIW: Cubes and points are floats, right? So would spatial indexes benefit
from this optimization, or is it only raw floats?
Jay Levitt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 2/6/12 3:19 PM, Bruce Momjian wrote:
> While we're waiting for anyone else to weigh in with an opinion on the
> right place to draw the line here, do you want to post an updated
> patch with the changes previously discussed?
Well, I think we have to ask not only how many people are using
f
Jay Levitt wrote:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
And I bet you'll want the test script... sigh. attached.
\c postgres
drop database if exists slowcube;
create database slowcube;
\c slowcube
\timing
crea
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
NOTABLE PROBLEMS
1. In 9.1.2, inserting 10x rows takes 19x the time.
- 9.1-HEAD and 9.2 "fix" this; it now slows down linearly
- but: 10s > 8s > 5s!
- but: compar
On Wed, Jan 04, 2012 at 01:44:07PM -0500, Robert Haas wrote:
> On Tue, Jan 3, 2012 at 9:23 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Jan 3, 2012 at 7:39 PM, Peter Geoghegan
> >> wrote:
> >>> Yes, I know that these only appeared in GCC 4.6+ and as such are a
> >>> relatively recen
Andrew Dunstan writes:
> On 11/16/2011 10:38 PM, Tom Lane wrote:
>> Upon further review, this patch would need some more work even for the
>> RowExpr case, because there are several places that build RowExprs
>> without bothering to build a valid colnames list. It's clearly soluble
>> if anyone c
On Tue, Jan 3, 2012 at 10:31 AM, Robert Haas wrote:
> On Sat, Dec 31, 2011 at 7:36 PM, Noah Misch wrote:
>> Building on commit 8f9fe6edce358f7904e0db119416b4d1080a83aa, this adds
>> protransform functions to the length coercions for numeric, varbit,
>> timestamp,
>> timestamptz, time, timetz and
On 01/24/2012 03:53 PM, Robert Haas wrote:
There are two graphs for each branch. The first is a scatter plot of
latency vs. transaction time. I found that graph hard to understand,
though; I couldn't really tell what I was looking at. So I made a
second set of graphs which graph number of comp
On 26-01-2012 06:19, Fujii Masao wrote:
Thanks for your review. Comments below.
> When I compiled the source with xlogdiff.patch, I got the following warnings.
>
> xlogfuncs.c:511:2: warning: format '%lX' expects argument of type
> 'long unsigned int *', but argument 3 has type 'uint64 *' [-Wfor
On 02/07/2012 12:09 AM, Dan Scales wrote:
So, yes, good point -- double writes cannot replace the functionality of
full_page_writes for base backup. If double writes were in use, they might be
automatically switched over to full page writes for the duration of the base
backup. And the double
Robert Haas writes:
> most places that issue queries can simply use those routines without
> needing to peek under the hood into the ArchiveHandle. This is not
> quite enough to get rid of g_conn, but it's close: the major stumbling
> block at this point is probably exit_nicely(). The gyrations
On Tue, Feb 7, 2012 at 17:29, Heikki Linnakangas
wrote:
> On 07.02.2012 16:55, Tom Lane wrote:
>>
>> (The integer vs float TimestampTz issue is a kind of portability
>> problem, but we've already bought into the assumption that sender and
>> receiver must be built with the same choice, no?)
>
>
>
On 07.02.2012 16:55, Tom Lane wrote:
(The integer vs float TimestampTz issue is a kind of portability
problem, but we've already bought into the assumption that sender and
receiver must be built with the same choice, no?)
Hmm, true. In hindsight, I think that was a bad choice, but it's a bit
l
On Sun, Feb 5, 2012 at 12:44 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> Yeah, I think we need to preserve that property. Unexpectedly
>> executing query (which may have side-effects) is a very dangerous
>> thing. People are used to the idea that ANALYZE == execute, and
>> adding random oth
On Fri, Feb 3, 2012 at 10:43 AM, Joachim Wieland wrote:
> On Fri, Feb 3, 2012 at 7:52 AM, Robert Haas wrote:
>> If you're OK with that much I'll go do it.
>
> Sure, go ahead!
It turns out that (as you anticipated) there are some problems with my
previous proposal. For one thing, an Archive isn'
On Tue, Feb 7, 2012 at 9:44 AM, Marko Kreen wrote:
>> - What is the right (or recommended) way to prevent from throwing
>> exceptoin in row-processor callback function? When author should use
>> PG_TRY block to catch exception in the callback function?
>
> When it calls backend functions that can
Hello All,
My application has to do a real time data upload to PostgreSQL
server.
Every time i have to do a real time upload, i do not wish to open
new connection.
I want to open a connection once [when my application comes up]
and periodically check if the conne
>> I think it is a good idea, and can help double-writes perform better in the
>> case of lots of backend evictions.
I don't understand this point, because from the data in your mail, it
appears that when shared buffers are less means when more evictions can happen,
the performance is less.
Chetan Suttraway wrote:
> This is regarding the TODO item:
> "Prevent the specification of conflicting transaction read/write
> options"
>
> listed at:
> http://wiki.postgresql.org/wiki/Todo
Thanks for chipping away at items on the list.
> Please pass on any inputs on the patch.
Right now
Simon Riggs writes:
> So ISTM that we should just strip out the OID handling code and just
> have a system sequence defined like this
I think this is a pretty poor idea, because the overhead of nextval()
is quite a lot larger than the overhead to get an OID.
regards, tom
Heikki Linnakangas writes:
> On 07.02.2012 09:03, Fujii Masao wrote:
>> What about changing receivelog.c so that it uses time_t instead of
>> TimestampTz? Which would make the code simpler, I think.
> Hmm, that would reduce granularity to seconds.
It also creates portability issues that I'd just
On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
> (2012/02/02 23:30), Marko Kreen wrote:
> > On Thu, Feb 02, 2012 at 04:51:37PM +0900, Kyotaro HORIGUCHI wrote:
> >> Hello, This is new version of dblink.c
> >>
> >> - Memory is properly freed when realloc returns NULL in storeHandler(
On Tue, Feb 07, 2012 at 05:56:52AM -0800, David Fetter wrote:
> On Mon, Feb 06, 2012 at 06:25:33PM -0500, Jay Levitt wrote:
> > I have a rough proof-of-concept for getting nearest-neighbor
> > searches working with cubes.
>
> Please attach such patches to the email when posting them :)
And here's
Excerpts from Simon Riggs's message of mar feb 07 10:46:09 -0300 2012:
> Recent events have made me notice the OID handling.
>
> AFAICS, OIDs are just a sequence with a max value that fits in a uint.
>
> So ISTM that we should just strip out the OID handling code and just
> have a system sequenc
On Tue, Feb 7, 2012 at 3:48 AM, Heikki Linnakangas
wrote:
> On 03.02.2012 22:57, Robert Haas wrote:
>>
>> I think I recommended a bad name for this function. It's really
>> LWLockAcquireOrWaitUntilFree. Can we rename that?
>
> Agreed, that's better. Although quite long. "LWLockAcquireOrWait" per
On Mon, Feb 06, 2012 at 06:25:33PM -0500, Jay Levitt wrote:
> I have a rough proof-of-concept for getting nearest-neighbor
> searches working with cubes.
Please attach such patches to the email when posting them :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: d
Recent events have made me notice the OID handling.
AFAICS, OIDs are just a sequence with a max value that fits in a uint.
So ISTM that we should just strip out the OID handling code and just
have a system sequence defined like this
CREATE SEQUENCE _pg_oid
MINVALUE 0
MAXVALUE 4294967296
On Tue, Feb 7, 2012 at 7:06 PM, Magnus Hagander wrote:
> On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
> wrote:
>> On 07.02.2012 11:35, Magnus Hagander wrote:
>>>
>>> On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
>>> wrote:
So, --statusint needs to be in milliseconds. And while
Hi,
This is regarding the TODO item:
"Prevent the specification of conflicting transaction read/write options"
listed at:
http://wiki.postgresql.org/wiki/Todo
The issue is :
SET TRANSACTION read only read write read only;
The fix involved iteration over transaction_mode_list and checking for
d
On Thu, Jan 26, 2012 at 10:00 PM, Dimitri Fontaine
wrote:
> Dimitri Fontaine writes:
>>> Really I think there is not any single point where you can put the
>>> command-trigger hook and be done. In almost every case, the right
>>> place is going to be buried somewhere within the execution of the
On Tue, Feb 7, 2012 at 5:44 PM, Kevin Grittner
wrote:
> "Kevin Grittner" wrote:
>
> > moved this to "Replication and Recovery"
>
> Oh, that was a different patch -- I didn't see yours.
>
> (It's early, and the caffeine isn't working yet.)
>
> Anyway, you should have plenty of options now.
>
> -Ke
"Kevin Grittner" wrote:
> moved this to "Replication and Recovery"
Oh, that was a different patch -- I didn't see yours.
(It's early, and the caffeine isn't working yet.)
Anyway, you should have plenty of options now.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Chetan Suttraway wrote:
> Robert Haas wrote:
>> Please add this to the next CommitFest:
>>
>> https://commitfest.postgresql.org/action/commitfest_view/open
> At the given link, I am able to choose only "System administration"
> under commitfest topic.
> I think there has to be "server feature
On tis, 2012-01-24 at 22:05 +0200, Peter Eisentraut wrote:
> > > One thing that is perhaps worth thinking about: Currently, we just
> > > ignore missing root.crt and root.crl files. With this patch, we still
> > > do this, even if the user has given a specific nondefault location.
> > > That seem
Hi,
http://www.depesz.com/2012/02/03/waiting-for-9-2-pg_basebackup-from-slave/
> =$ time pg_basebackup -D /home/pgdba/slave2/ -F p -x stream -c fast -P -v -h
> 127.0.0.1 -p 5921 -U replication
> xlog start point: 2/AC4E2600
> pg_basebackup: starting background WAL receiver
> 692447/692447 kB (100
On Tue, Feb 7, 2012 at 3:03 AM, Tom Lane wrote:
> Pavan Deolasee writes:
>> If I run the following sequence of commands, I get an assertion
>> failure in current HEAD.
>
>> postgres=# BEGIN;
>> BEGIN
>> postgres=# SELECT 1/0;
>> ERROR: division by zero
>> postgres=# ROLLBACK TO A;
>> ERROR: no
On tor, 2012-01-26 at 19:00 +0530, Abhijit Menon-Sen wrote:
> At issue are (at least) these three lines from print_unaligned_text in
> src/bin/psql/print.c:
>
> 358 /* the last record needs to be concluded with a newline
> */
> 359 if (need_recordsep)
> 360 fputc('\n
(2012/02/02 23:30), Marko Kreen wrote:
> On Thu, Feb 02, 2012 at 04:51:37PM +0900, Kyotaro HORIGUCHI wrote:
>> Hello, This is new version of dblink.c
>>
>> - Memory is properly freed when realloc returns NULL in storeHandler().
>>
>> - The bug that free() in finishStoreInfo() will be fed with
>>
On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
wrote:
> On 07.02.2012 11:35, Magnus Hagander wrote:
>>
>> On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
>> wrote:
>>>
>>> So, --statusint needs to be in milliseconds. And while we're at it, how
>>>
>>> difficult would be to ask the server for
On 07.02.2012 11:35, Magnus Hagander wrote:
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
wrote:
So, --statusint needs to be in milliseconds. And while we're at it, how
difficult would be to ask the server for the current value of
replication_timeout, and set --statusint automatically based
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
wrote:
> On 07.02.2012 09:03, Fujii Masao wrote:
>>
>> On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao wrote:
>>>
>>> When I compiled HEAD with --disable-integer-datetimes and tested
>>>
>>> pg_receivexlog, I encountered unexpected replication timeout.
On 07.02.2012 09:03, Fujii Masao wrote:
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao wrote:
When I compiled HEAD with --disable-integer-datetimes and tested
pg_receivexlog, I encountered unexpected replication timeout. As
far as I read the pg_receivexlog code, the cause of this problem is
that p
On 03.02.2012 22:57, Robert Haas wrote:
I think I recommended a bad name for this function. It's really
LWLockAcquireOrWaitUntilFree. Can we rename that?
Agreed, that's better. Although quite long. "LWLockAcquireOrWait" perhaps?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprised
On 04.02.2012 07:24, Jeff Janes wrote:
Is it safe to assume that, under "#ifdef LWLOCK_STATS", a call to
LWLockAcquire will always precede any calls to LWLockWaitUntilFree
when a new process is started, to calloc the stats assays?
>
I guess it is right now, because the only user is WALWrite, wh
79 matches
Mail list logo
