On 22 January 2014 09:54, David Rowley wrote:
> I've performed some more benchmarks on this patch tonight. The results and
> full recreation scripts are attached along with the patch it was tested
> against.
>
I noticed that the rate of changes to this patch has dropped off,
which I took as sign
Hi.
I can't apply the patch.
$ git apply --stat ~/Downloads/extension_control_path.v0.patch
fatal: unrecognized input
2014/1/14 Dimitri Fontaine
> Hi,
>
> Please find attached to this email a patch implementing a new GUC that
> allows users to setup a list of path where PostgreSQL will search
On Fri, Jan 24, 2014 at 6:48 AM, Tomas Vondra wrote:
> I plan to do more thorough testing over the weekend, but I'd like to
> make sure I understand what to expect. My understanding is that this
> patch should:
>
> - give the same results as the current code (e.g. the fulltext should
> not retu
On 24/01/2014 05:28, Andrew Dunstan wrote:
On 01/23/2014 10:50 PM, Bruce Momjian wrote:
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
Bruce Momjian writes:
Andrew, should this configuration/code patch be applied to 9.4?
http://www.postgresql.org/message-id/51b59794.3000...@gm
On Wed, Jan 15, 2014 at 6:57 AM, Simon Riggs wrote:
> v15 to fix the above problem.
Minor quibble: I get a compiler warning with the patch applied.
"relcache.c: In function ‘RememberToFreeTupleDescAtEOX’:
relcache.c:2317:3: warning: ISO C90 forbids mixed declarations and
code [-Werror=declaration
On Fri, Jan 24, 2014 at 4:22 AM, Tom Lane wrote:
> "MauMau" writes:
>> From: "Tom Lane"
>>> I'm still not clear on why we can't just use the port number.
>
>> To use port, we have to tell the location of $PGDATA to regsvr32.exe.
>
> [ scratches head... ] Exactly which of the other proposals *do
On Fri, Jan 24, 2014 at 12:33 AM, Craig Ringer wrote:
> On 01/24/2014 11:32 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Claudio Freire escribió:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
>>
On 01/23/2014 10:50 PM, Bruce Momjian wrote:
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
Bruce Momjian writes:
Andrew, should this configuration/code patch be applied to 9.4?
http://www.postgresql.org/message-id/51b59794.3000...@gmail.com
I think we would have to make Cy
On Thu, Jan 23, 2014 at 10:39:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have developed the attached patch to fix this problem. Do I need to
> > say "invalid user or invalid or expired password"?
>
> I'm not convinced that this improves anything. The problem might not in
> fact b
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew, should this configuration/code patch be applied to 9.4?
>
> > http://www.postgresql.org/message-id/51b59794.3000...@gmail.com
>
> > I think we would have to make Cygwin-specific regression output to
Bruce Momjian writes:
> Andrew, should this configuration/code patch be applied to 9.4?
> http://www.postgresql.org/message-id/51b59794.3000...@gmail.com
> I think we would have to make Cygwin-specific regression output to
> handle the regression failures, but frankly I am not even sure if
Craig Ringer escribió:
> On 01/24/2014 11:32 AM, Tom Lane wrote:
> > The hard part of this is that shutting down autovacuum during heavy
> > load may be exactly the wrong thing to do.
>
> Yep. In fact, it may be appropriate to limit or stop autovacuum's work
> on some big tables, while pushing it
On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas wrote:
> On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote:
>> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
>>> Amit Kapila writes:
On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
> So? Anything which can know the value of a GUC par
Bruce Momjian writes:
> I have developed the attached patch to fix this problem. Do I need to
> say "invalid user or invalid or expired password"?
I'm not convinced that this improves anything. The problem might not in
fact be either of the things you mention, in which case the new message
is
On Thu, 23 Jan 2014 13:19:37 +0200
Marti Raudsepp wrote:
> Resending to Tatsuo Ishii and Yugo Nagata, your email server was
> having problems yesterday:
Thanks for resending!
>
> This is the mail system at host sraigw2.sra.co.jp.
>
> : mail for srasce.sra.co.jp loops back to myself
> : mail f
On Mon, Jun 10, 2013 at 11:08:36AM +0200, marco atzeri wrote:
> Il 3/6/2013 11:46 PM, Andrew Dunstan ha scritto:
> >
> >Excellent. Will test it out soon.
> >
> >cheers
> >
> >andrew
> >
>
> Andrew,
> please find attached a full patch for cygwin relative to 9.3beta1 :
>
> - DLLTOLL/DLLWRAP are not
On 01/24/2014 11:32 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Claudio Freire escribió:
>>> If you ask me, I'd like autovac to know when not to run (or rather
>>> wait a bit, not forever), perhaps by checking load factors or some
>>> other tell-tale of an already-saturated I/O system.
>
>> W
Alvaro Herrera writes:
> Claudio Freire escribió:
>> If you ask me, I'd like autovac to know when not to run (or rather
>> wait a bit, not forever), perhaps by checking load factors or some
>> other tell-tale of an already-saturated I/O system.
> We had a proposed design to tell autovac when not
Claudio Freire escribió:
> If you ask me, I'd like autovac to know when not to run (or rather
> wait a bit, not forever), perhaps by checking load factors or some
> other tell-tale of an already-saturated I/O system.
We had a proposed design to tell autovac when not to run (or rather,
when to swi
On 01/24/2014 10:12 AM, Craig Ringer wrote:
> (Re-sending; I forgot to cc the list)
>
> On 01/20/2014 02:15 PM, Craig Ringer wrote:
>> On 01/20/2014 09:58 AM, Craig Ringer wrote:
>>> As it is I'm spending today reworking the RLS patch on top of the new
>>> approach to updatable security barrier vi
On Wed, Jun 19, 2013 at 01:27:39PM -0700, Joshua D. Drake wrote:
>
> On 06/19/2013 01:18 PM, Markus Wanner wrote:
>
> >>"Authentication failed or password has expired for user \"%s\""
> >>
> >>Authentication failed covers any combination of a username/password
> >>being wrong and obviously passwo
On 23.1.2014 17:22, Heikki Linnakangas wrote:
> On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
>> Attached version is rebased against last version of packed posting lists.
>
> Thanks!
>
> I think we're missing a trick with multi-key queries. We know that when
> multiple scan keys are used, the
On Thu, Jan 23, 2014 at 10:38 PM, Craig Ringer wrote:
>>>
>>> Stops excessive bloat - clearly autovacuum *is* able to vacuum pg_attribute
>>> in this case. Back to drawing board for a test case.
>>
>> Well, I think quite many people don't realize it might be necessary to
>> tune autovac on busy wo
On 01/24/2014 07:52 AM, Andres Freund wrote:
> On 2014-01-24 12:49:57 +1300, Mark Kirkwood wrote:
>> autovacuum_max_workers = 4
>> autovacuum_naptime = 10s
>> autovacuum_vacuum_scale_factor = 0.1
>> autovacuum_analyze_scale_factor = 0.1
>> autovacuum_vacuum_cost_delay = 0ms
>>
>> Stops excessive bl
Andres Freund writes:
> On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
>> I concur with the other reports that the main problem in this test case is
>> just that the default cost delay settings throttle autovacuum so hard that
>> it has no chance of keeping up. If I reduce autovacuum_vacuum_cost_d
On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
> I saw at most two pages skipped per vacuum, and
> usually none; so there's no way that a whole lot of tuples are going
> unvacuumed because of this. (I wonder though if we ought to add such
> counting as a permanent feature ...)
I generally think we
Andres Freund writes:
> On 2014-01-23 16:15:50 -0500, Tom Lane wrote:
>> [ thinks... ] It's possible that what you saw is not the
>> kick-out-autovacuum-entirely behavior, but the behavior added in commit
>> bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it
>> can't immedia
Andres Freund writes:
> Do we have a real policy against indenting nested preprocessor
> statments? Just so I don't do those in future patches...
Indent 'em if you like, but pgindent will undo it. I ran the patch
through pgindent to see what it would do with those, and it left-justified
them, so
On 2014-01-23 16:15:50 -0500, Tom Lane wrote:
> [ thinks... ] It's possible that what you saw is not the
> kick-out-autovacuum-entirely behavior, but the behavior added in commit
> bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it
> can't immediately get an exclusive buffer
On 2014-01-24 12:49:57 +1300, Mark Kirkwood wrote:
> autovacuum_max_workers = 4
> autovacuum_naptime = 10s
> autovacuum_vacuum_scale_factor = 0.1
> autovacuum_analyze_scale_factor = 0.1
> autovacuum_vacuum_cost_delay = 0ms
>
> Stops excessive bloat - clearly autovacuum *is* able to vacuum pg_attri
On 24/01/14 12:28, Mark Kirkwood wrote:
On 24/01/14 12:13, Jeff Janes wrote:
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
On 2014-01-23 17:21:11 -0500, Tom Lane wrote:
> I wrote:
> > the idea that we might get many dozen such warnings on more-current
> > compilers is scarier, as that might well interfere with people's
> > ability to do development on, say, Windows. Could somebody check
> > whether MSVC for instance c
On 2014-01-23 13:56:49 +0100, Simon Riggs wrote:
> IMHO we need to resolve the deadlock inherent in the
> disk-full/WALlock-up/checkpoint situation. My view is that can be
> solved in a similar way to the way the buffer pin deadlock was
> resolved for Hot Standby.
I don't think that approach works
Hi,
On 2014-01-23 16:04:10 -0500, Robert Haas wrote:
> Patch 0001:
>
> +errmsg("could not find free replication
> slot"),
>
> Suggest: all replication slots are in use
That sounds better indeed.
> + elog(ERROR, "cannot aquire a slot while another
On 24/01/14 12:13, Jeff Janes wrote:
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
On 24/01/14 09:49, Tom Lane wrot
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
> On 24/01/14 10:16, Mark Kirkwood wrote:
>
>> On 24/01/14 10:09, Robert Haas wrote:
>>
>>> On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
>>> wrote:
>>>
On 24/01/14 09:49, Tom Lane wrote:
> 2. Wh
On 01/23/2014 02:55 PM, Josh Berkus wrote:
> On 01/23/2014 02:17 PM, Magnus Hagander wrote:
>> FWIW, I have a patch around somewhere that I never cleaned up properly for
>> submissions that simply added a counter to pg_stat_user_tables indicating
>> how many times vacuum had aborted on that specifi
On 01/23/2014 02:17 PM, Magnus Hagander wrote:
> FWIW, I have a patch around somewhere that I never cleaned up properly for
> submissions that simply added a counter to pg_stat_user_tables indicating
> how many times vacuum had aborted on that specific table. If that's enough
> info (it was for my
"MauMau" writes:
> From: "Tom Lane"
>> I'm still not clear on why we can't just use the port number.
> To use port, we have to tell the location of $PGDATA to regsvr32.exe.
[ scratches head... ] Exactly which of the other proposals *doesn't*
require that? Certainly anything that involves par
From: "Tom Lane"
I'm still not clear on why we can't just use the port number.
It will be possible to use port to set the default value of event_source GUC
when starting postmaster. But using port during event source registration
will involve much more.
To use port, we have to tell the loca
I wrote:
> the idea that we might get many dozen such warnings on more-current
> compilers is scarier, as that might well interfere with people's
> ability to do development on, say, Windows. Could somebody check
> whether MSVC for instance complains about format strings using "z"?
> Or shall I ju
On Thu, Jan 23, 2014 at 10:00 PM, Harold Giménez wrote:
> On Thu, Jan 23, 2014 at 12:53 PM, Josh Berkus wrote:
> > On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
> >>
> >> Hello,
> >>
> >> I have run into yet again another situation where there was an
> >> assumption that autovacuum was keeping
Heikki Linnakangas writes:
> On 01/23/2014 10:37 PM, Tom Lane wrote:
>> The problem appears to be due to the misaligned "plist" pointer
>> (0xc39efac1 here).
> Ah, thanks! Looks like I removed a SHORTALIGN from ginFormTuple that was
> in fact very much necessary.. Fixed now, let's see if that pa
Alvaro Herrera writes:
> Tom Lane escribió:
>> That particular ID would be a horrid choice, because we don't try very
>> hard to ensure it's unique. In particular, a standby server on the same
>> machine as the master (not an uncommon case, at least for testing
>> purposes) would be a guaranteed
> I wonder if it wouldn't be better to get rid of the subdirectories for
> the individual slots, and just have a file pg_replslot/$SLOTNAME, or
> not. I know there are later patches that need subdirectories for
> their own private data, but they could just create
> pg_replslot/$SLOTNAME.dir and pu
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute?
That seems like a pretty unfriendly behavior in itself
On Thu, Nov 14, 2013 at 9:23 AM, Heikki Linnakangas
wrote:
> Ok, here's a new version of the patch to handle incomplete B-tree splits.
I finally got around to taking a look at this. Unlike with the as-yet
uncommitted "Race condition in b-tree page deletion" patch that Kevin
looked at, which there
Tom Lane escribió:
> Peter Eisentraut writes:
> > On 1/23/14, 4:08 PM, Robert Haas wrote:
> >> Why wouldn't that be necessary with your approach, too? I mean, if
> >> there's a GUC that controls the event source name, then it can be
> >> changed between restarts, regardless of what you call it.
>
Peter Eisentraut writes:
> On 1/23/14, 4:08 PM, Robert Haas wrote:
>> Why wouldn't that be necessary with your approach, too? I mean, if
>> there's a GUC that controls the event source name, then it can be
>> changed between restarts, regardless of what you call it.
> I don't know if it's practi
On 1/23/14, 4:08 PM, Robert Haas wrote:
> Why wouldn't that be necessary with your approach, too? I mean, if
> there's a GUC that controls the event source name, then it can be
> changed between restarts, regardless of what you call it.
I don't know if it's practical, but the logical conclusion h
From: "Amit Kapila"
How about below message:
event source "" is already registered.
OK, I added several lines for this. Please check the attached patch.
What I had in mind was to change it during initdb, we are already doing it
for some other parameter (unix_socket_directories), please re
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards, tom lane
I've seen this sort
Mark Kirkwood writes:
> On 24/01/14 09:49, Tom Lane wrote:
>> 2. What have you got that is requesting exclusive lock on
>> pg_attribute? That seems like a pretty unfriendly behavior in itself.
> I've seen this sort of problem where every db session was busily
> creating temporary tables. I nev
Dne 23.1.2014 22:04 "Mark Kirkwood"
napsal(a):
>
> On 24/01/14 09:49, Tom Lane wrote:
>>
>> 2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards, tom lane
>
>
> I've seen this sort of problem where every db session
On 01/23/2014 01:03 PM, Mark Kirkwood wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
regards, tom lane
I've seen this sort of problem where every db session was busily
c
On 1/20/14 9:46 AM, Mel Gorman wrote:
They could potentially be used to evalate any IO scheduler changes.
For example -- deadline scheduler with these parameters has X
transactions/sec throughput with average latency of Y millieseconds
and a maximum fsync latency of Z seconds. Evaluate how well
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
> On 24/01/14 09:49, Tom Lane wrote:
>> 2. What have you got that is requesting exclusive lock on pg_attribute?
>> That seems like a pretty unfriendly behavior in itself. regards, tom lane
>
> I've seen this sort of problem where every db sessi
On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote:
> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
>> Amit Kapila writes:
>>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
So? Anything which can know the value of a GUC parameter can certainly
know the selected port number.
>>
On 01/23/2014 10:37 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 01/23/2014 09:18 PM, Stefan Kaltenbrunner wrote:
it seems that this commit made spoonbill an unhappy animal:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2014-01-23%2000%3A00%3A04
Hmm, all the Sparcs. So
Patch 0001:
+errmsg("could not find free replication slot"),
Suggest: all replication slots are in use
+ elog(ERROR, "cannot aquire a slot while another slot
has been acquired");
Suggest: this backend has already acquired a replication slot
Or demo
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
regards, tom lane
I've seen this sort of problem where every db session was busily
creating temporary tables. I never got to the
On Thu, Jan 23, 2014 at 12:53 PM, Josh Berkus wrote:
> On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
>>
>> Hello,
>>
>> I have run into yet again another situation where there was an
>> assumption that autovacuum was keeping up and it wasn't. It was caused
>> by autovacuum quitting because anothe
On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
>
> Hello,
>
> I have run into yet again another situation where there was an
> assumption that autovacuum was keeping up and it wasn't. It was caused
> by autovacuum quitting because another process requested a lock.
>
> In turn we received a ton o
"Joshua D. Drake" writes:
> I have run into yet again another situation where there was an
> assumption that autovacuum was keeping up and it wasn't. It was caused
> by autovacuum quitting because another process requested a lock.
> In turn we received a ton of bloat on pg_attribute which cause
Heikki Linnakangas writes:
> On 01/23/2014 09:18 PM, Stefan Kaltenbrunner wrote:
>> it seems that this commit made spoonbill an unhappy animal:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2014-01-23%2000%3A00%3A04
> Hmm, all the Sparcs. Some kind of an alignment issue, perha
Hello,
I have run into yet again another situation where there was an
assumption that autovacuum was keeping up and it wasn't. It was caused
by autovacuum quitting because another process requested a lock.
In turn we received a ton of bloat on pg_attribute which caused all
kinds of other is
Alvaro Herrera writes:
> So, the reason for doing things this way is to handle cases like
> "varchar(10)" being turned into "character varying"; and that name
> requires that the typename NOT be schema-qualified, otherwise it fails.
> But thinking about this again, I don't see a reason why this ca
On 01/23/2014 08:41 PM, Tom Lane wrote:
The rather ancient gcc on my HPUX box is complaining thusly about HEAD:
ginbtree.c: In function `ginPlaceToPage':
ginbtree.c:602: warning: control reaches end of non-void function
I would imagine this would happen on any compiler that doesn't recognize
th
I wrote:
> I checked on my HPUX box and find that what it prints for "%zu" is
> "zu", confirming my thought that it'd just abandon processing of the
> %-sequence. (Interesting that it doesn't eat the "z" while doing
> so, though.)
Further testing on that box shows that its ancient gcc (2.95.3) do
On 01/23/2014 09:18 PM, Stefan Kaltenbrunner wrote:
On 01/22/2014 06:28 PM, Heikki Linnakangas wrote:
Compress GIN posting lists, for smaller index size.
GIN posting lists are now encoded using varbyte-encoding, which allows them
to fit in much smaller space than the straight ItemPointer array
On 12/06/2013 09:16 AM, MauMau wrote:
> Hello,
>
> According to this page,
>
> http://www.postgresql.org/docs/current/static/install-procedure.html
>
> client-only installation is possible on UNIX/Linux like this:
>
> gmake -C src/bin install
> gmake -C src/include install
> gmake -C src/interface
On 01/22/2014 06:28 PM, Heikki Linnakangas wrote:
> Compress GIN posting lists, for smaller index size.
>
> GIN posting lists are now encoded using varbyte-encoding, which allows them
> to fit in much smaller space than the straight ItemPointer array format used
> before. The new encoding is used
Andres Freund escribió:
> * Why must we not schema qualify system types
> (c.f. expand_jsonval_typename)? It seems to be perfectly sensible to
> me to just use pg_catalog there.
So, the reason for doing things this way is to handle cases like
"varchar(10)" being turned into "character varying
The rather ancient gcc on my HPUX box is complaining thusly about HEAD:
ginbtree.c: In function `ginPlaceToPage':
ginbtree.c:602: warning: control reaches end of non-void function
I would imagine this would happen on any compiler that doesn't recognize
the hint about elog(ERROR) not returning. C
Andrew Dunstan writes:
> I have committed this. It's in the commitfest as a bug fix, but I don't
> think it's strictly a bug. OTOH, it's pretty harmless. Do we want to
> backpatch it?
Given the lack of field complaints, I'd say it's not worth the trouble.
regards, tom lan
Andres Freund writes:
> On 2014-01-23 12:54:22 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
>> Actually, that coding isn't gonna work at all on platforms where size_t
>> isn't the same size as uint64. We could make it work by explicitly
>>
Alvaro Herrera wrote:
> With apologies to our beloved commitfest-mace-wielding CFM, commitfest
> 2013-11 intentionally still contains a few open patches. I think that
> CF is largely being ignored by most people now that we have CF 2014-01
> in progress. If we don't want to do anything about thes
Pavel Stehule escribió:
> I though about it too. But I didn't continue - reasons was named by Dean -
> and RemoveObjects are not difficult code - lot of code is mechanical - and
> it is not on critical path.
I have pushed it after some editorialization.
--
Álvaro Herrerahttp://w
On 2014-01-23 12:54:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
>
> Actually, that coding isn't gonna work at all on platforms where size_t
> isn't the same size as uint64. We could make it work by explicitly
> casting the argument to w
Andres Freund writes:
> snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
Actually, that coding isn't gonna work at all on platforms where size_t
isn't the same size as uint64. We could make it work by explicitly
casting the argument to whatever type we've decided to use as uint64
... but unless
On Wed, Dec 4, 2013 at 9:21 PM, MauMau wrote:
> Hello,
>
> I've found a bug that psql's \conninfo displays incorrect information on
> Windows. Please find attached the patch and commit this.
>
> [Problem]
> When I run "psql postgres" on Windows and execute \conninfo, it outputs the
> text below.
On Wed, Jan 22, 2014 at 11:48 PM, Fujii Masao wrote:
> Hi,
>
> I reported in other thread that PQhost() has three problems.
>
> http://www.postgresql.org/message-id/cahgqgwe77akyabywde5+8bjldopthp7cnswao_syedjogyv...@mail.gmail.com
>
> (1) PQhost() can return Unix-domain s
On 01/13/2014 10:49 PM, Dilip kumar wrote:
>
> As per current behavior if user want to build in debug mode in
> windows, then he need to give debug in capital letters (DEBUG),
>
> I think many user will always make mistake in giving this option, in
> my opinion we can make it case insensitive.
>
>
On 2014-01-23 11:50:57 -0500, Robert Haas wrote:
> On Thu, Jan 23, 2014 at 7:05 AM, Andres Freund wrote:
> > I don't think shared buffers fsyncs are the apt comparison. It's more
> > something like UpdateControlFile(). Which PANICs.
> >
> > I really don't get why you fight PANICs in general that m
On 2014-01-23 11:25:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I was wondering more about the nature of the runtime check than the fact
> > that it's a runtime check at all... E.g. snprintf.c simply skips over
> > unknown format characters and might not have been detected as faulty on
>
On Thu, Jan 23, 2014 at 7:05 AM, Andres Freund wrote:
> I don't think shared buffers fsyncs are the apt comparison. It's more
> something like UpdateControlFile(). Which PANICs.
>
> I really don't get why you fight PANICs in general that much. There are
> some nasty PANICs in postgres which can ha
On Jan23, 2014, at 17:20 , Tom Lane wrote:
> Florian Pflug writes:
>> Is there a particular reason why the "direct" arguments of ordered-set
>> aggregates are not passed to the transition function too?
>
> Because they have to be evaluated only once.
>
> I did consider evaluating them once at t
Andres Freund writes:
> I was wondering more about the nature of the runtime check than the fact
> that it's a runtime check at all... E.g. snprintf.c simply skips over
> unknown format characters and might not have been detected as faulty on
> 32bit platforms by that check. Which might be conside
Florian Pflug writes:
> Is there a particular reason why the "direct" arguments of ordered-set
> aggregates are not passed to the transition function too?
Because they have to be evaluated only once.
I did consider evaluating them once at the start and saving the values,
but that's a bit problem
On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
Attached version is rebased against last version of packed posting lists.
Thanks!
I think we're missing a trick with multi-key queries. We know that when
multiple scan keys are used, they are ANDed together, so we can do the
skip optimization
Andres Freund writes:
> So, here's a patch adding %z support to port/snprintf.c including a
> configure check to test whether we need to fall back.
OK, I'll take a look.
> I am not too
> happy about the runtime check as the test isn't all that meaningful, but
> I couldn't think of anything bette
On 2014-01-23 11:14:05 -0500, Tom Lane wrote:
> OK, I'll take a look.
Thanks.
> > I am not too
> > happy about the runtime check as the test isn't all that meaningful, but
> > I couldn't think of anything better.
>
> Yeah, it's problematic for cross-compiles, but no more so than configure's
> ex
Hi,
Is there a particular reason why the "direct" arguments of ordered-set
aggregates are not passed to the transition function too? It seems that
evaluating of some ordered-set aggregates would be much cheaper if we did
that.
For example, dense_rank() would then just need to count the number of
On Wed, Jan 22, 2014 at 12:42 PM, Andres Freund wrote:
> On 2014-01-22 12:40:34 -0500, Robert Haas wrote:
>> On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane wrote:
>> > Andres Freund writes:
>> >> Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid
>> >> breaking external code us
On 2014-01-21 11:33:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
> >> How difficult would it be to have expand_fmt_string deal with positional
> >> modifiers? I don't think we need anything from it other than the %n$
> >> notation, so p
On 01/23/2014 08:11 AM, Peter Eisentraut wrote:
We started this commit fest with 103 patches and got off to a flyer,
with 20 patches committed during the first week. Somehow we ended up
with 113 patches at the end of the first week, but let's please leave it
at that.
I'm tracking down patch au
On 01/22/2014 11:33 PM, KONDO Mitsumasa wrote:
(2014/01/23 12:00), Andrew Dunstan wrote:
On 01/22/2014 08:28 PM, KONDO Mitsumasa wrote:
(2014/01/22 22:26), Robert Haas wrote:
On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa
wrote:
OK, Kondo, please demonstrate benchmarks that show we have <
On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
>>> So? Anything which can know the value of a GUC parameter can certainly
>>> know the selected port number.
>
>> 1. In case of registration of event source, either user
2014/1/23 Andres Freund :
> On 2014-01-23 23:03:40 +0900, Kohei KaiGai wrote:
>> Isn't it necessary to have an interface to initialize LWLock structure being
>> allocated on a dynamic shared memory segment?
>> Even though LWLock structure is exposed at lwlock.h, we have no common
>> way to initiali
On 2014-01-23 23:03:40 +0900, Kohei KaiGai wrote:
> Isn't it necessary to have an interface to initialize LWLock structure being
> allocated on a dynamic shared memory segment?
> Even though LWLock structure is exposed at lwlock.h, we have no common
> way to initialize it.
There's LWLockInitialize
1 - 100 of 114 matches
Mail list logo
