On Wed, Jul 16, 2014 at 2:29 AM, Sawada Masahiko wrote:
> On Tue, Jul 15, 2014 at 7:38 PM, Fujii Masao wrote:
>> On Thu, Jul 10, 2014 at 11:10 PM, Sawada Masahiko
>> wrote:
>>> Hi,
>>>
>>> At 1047 line of receivelog.c:CopyStreamPoll(), we set NULL to
>>> timeoutptr variable.
>>> if the value of
Hi
2014-07-24 3:49 GMT+02:00 Charlie Holleran :
> postgres has fantastic date-time parsing. I've tried some Java libraries
> that advertise amazing time parsing. But nothing seems to match postgres's
> time parsing. I started peeking through the source to find a reference to
> a library that
On Wed, Jul 23, 2014 at 8:52 PM, Amit Kapila wrote:
> As such there is no problem in saying the way you have mentioned, but
> I feel it would be better if we can mention the mechanism of _bt_search()
> as quoted by you upthread in the first line.
> "> In more concrete terms, _bt_search() releases
On Wed, Jul 23, 2014 at 11:02 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Tom Lane wrote:
> > >> No, ALTER SYSTEM is there now and it needs to work right in its first
> > >> release. I will go fix this if nobody else does.
> >
> > > Just checking -- you didn't ge
On Wed, Jul 23, 2014 at 11:19 AM, Peter Geoghegan wrote:
> On Tue, Jul 22, 2014 at 8:59 PM, Amit Kapila
wrote:
> > Okay, but how does this justify to add below new text in README.
> > + Even with these read locks, Lehman and Yao's approach obviates the
> > + need of earlier schemes to hold multip
postgres has fantastic date-time parsing. I've tried some Java libraries
that advertise amazing time parsing. But nothing seems to match postgres's
time parsing. I started peeking through the source to find a reference to
a library that postgres might be using for time parsing. no luck. Where
w
On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> I'd suggest something like:
>
> UPSERT table SET col = value [, ...] WHERE predicate;
I think I see another problem with this. The UPDATE must provide a
WHERE clause Var on a unique indexed column (let's say it's
constrained to provide a "(Var
Noah Misch writes:
> On Tue, Jul 22, 2014 at 11:51:18AM -0400, Tom Lane wrote:
>> Hmm. I'm pretty sure it is not considered good style to drop AC_DEFUN
>> blocks right into configure.in; at least, we have never done that before.
>> PGAC_LDAP_SAFE should get defined somewhere in config/*.m4, inste
On Tue, Jul 22, 2014 at 11:51:18AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Diagnose incompatible OpenLDAP versions during build and test.
>
> Hmm. I'm pretty sure it is not considered good style to drop AC_DEFUN
> blocks right into configure.in; at least, we have never done that before.
Magnus Hagander wrote:
> I think it would be very useful to have. Given how long it takes to
> build not all the time, but running it every couple of days or weekly
> or so would be quite useful. Then we'd catch things earlier and not
> have to spend as much time trying to figure out exactly what
On Wed, Jul 23, 2014 at 3:27 PM, Robert Haas wrote:
> To the last question, yes. To the first point, I'm not bent on this
> particular syntax, but I am +1 for the idea that the command is
> something specifically upsert-like rather than something more generic
> like an ON CONFLICT SELECT that let
Robert Haas wrote:
> On Wed, Jul 23, 2014 at 4:05 PM, Peter Geoghegan wrote:
> > On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> >> 2. If you find more than one tuple that is visible to your scan, error.
> >
> > This point seems to concern making the UPSERT UPDATE only affect zero
> > or o
Peter Geoghegan wrote:
> Maybe that would be marginally better than classic Levenshtein
> distance, but I doubt it would pay for itself. It's just more code to
> maintain. Are we really expecting to not get the best possible
> suggestion due to some number of transposition errors very frequently?
On Thu, Jul 24, 2014 at 1:09 AM, Tom Lane wrote:
> Robert Haas writes:
> > There are several possible methods of doing that, but I think the best
> > one is just to leave the SQL-callable C functions in fuzzystrmatch and
> > move only the underlying code that supports into core.
>
> I hadn't bee
On Wed, Jul 23, 2014 at 3:01 PM, Kevin Grittner wrote:
> Could you clarify that? Does this mean that you feel that we
> should write to the heap before reading the index to see if the row
> will be a duplicate? If so, I think that is a bad idea, since this
> will sometimes be used to apply a new
Peter Geoghegan-3 wrote
>> with semantics like this:
>>
>> 1. Search the table, using any type of scan you like, for a row
>> matching the given predicate.
>
> Perhaps I've misunderstood, but this is fundamentally different to
> what I'd always thought would need to happen. I always understood tha
On 23 July 2014 22:16, Tom Lane wrote:
> Krystian Bigaj writes:
> > - when pg_console_handler receives CTRL_SHUTDOWN_EVENT from OS, then it
> > calls pg_queue_signal(SIGINT).
>
> > Problems:
> > - when OS is in shutdown path, then it sends CTRL_SHUTDOWN_EVENT, and
> *all*
> > Postgres processes
On Wed, Jul 23, 2014 at 4:05 PM, Peter Geoghegan wrote:
> On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
>> This all seems completely to one side of Andres's point. I think what
>> he's saying is: don't implement an SQL syntax of the form INSERT ON
>> CONFLICT and let people use that to imp
On Wed, Jul 23, 2014 at 4:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jul 21, 2014 at 10:52 AM, Emre Hasegeli wrote:
>>> The first two shapes on src/test/regress/sql/polygon.sql do not make
>>> sense to me.
>
>> Well, I think the number of tabs that makes them look best depends on
>>
Peter Geoghegan wrote:
> I still strongly feel it ought to be driven by an insert
Could you clarify that? Does this mean that you feel that we
should write to the heap before reading the index to see if the row
will be a duplicate? If so, I think that is a bad idea, since this
will sometimes b
On Wed, Jul 23, 2014 at 5:58 PM, Robert Haas wrote:
> I'd suggest something like:
>
> UPSERT table SET col = value [, ...] WHERE predicate;
I don't think this is actually good enough. Typical use cases are
things like "increment this counter or insert a new one starting at
0".
--
greg
--
Sen
On Thu, Apr 17, 2014 at 9:15 PM, Michael Paquier
wrote:
>
> On Fri, Apr 18, 2014 at 4:29 AM, Fabrízio de Royes Mello
> wrote:
> >
> > On Thu, Apr 17, 2014 at 12:46 PM, Bruce Momjian
wrote:
> >>
> >> On Thu, Apr 17, 2014 at 11:44:37AM -0400, Tom Lane wrote:
> >> > Bruce Momjian writes:
> >> > >
On Tue, Jul 22, 2014 at 3:29 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Tue, Jul 22, 2014 at 12:01 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> >
> >
> >
> > On Thu, Jul 17, 2014 at 8:02 PM, Andres Freund
wrote:
> > >
> > > > That means should I "FlushR
On Wed, Jul 23, 2014 at 1:10 PM, Alvaro Herrera
wrote:
> I had two thoughts:
>
> 1. Should we consider making levenshtein available to frontend programs
> as well as backend?
I don't think so. Why would that be useful?
> 2. Would it provide better matching to use Damerau-Levenshtein[1] instead
>
On Wed, Jul 23, 2014 at 10:15 PM, Andrew Dunstan wrote:
>
> On 07/23/2014 06:31 AM, Magnus Hagander wrote:
>>
>>
>>
>> Do we actually have any buildfarm boxes building the PDFs? And if so,
>> any idea why they didn't catch it?
>
>
>
> AFAIK, nobody's ever asked for such a thing. The docs optional
Krystian Bigaj writes:
> - when pg_console_handler receives CTRL_SHUTDOWN_EVENT from OS, then it
> calls pg_queue_signal(SIGINT).
> Problems:
> - when OS is in shutdown path, then it sends CTRL_SHUTDOWN_EVENT, and *all*
> Postgres processes (main and sub/forked) will call pg_queue_signal(SIGINT)
On 07/23/2014 06:31 AM, Magnus Hagander wrote:
Do we actually have any buildfarm boxes building the PDFs? And if so,
any idea why they didn't catch it?
AFAIK, nobody's ever asked for such a thing. The docs optional step just
builds the default docs target, which is simply the HTML docs.
Peter Geoghegan wrote:
> For some reason I thought that that was what Michael was proposing - a
> more comprehensive move of code into core than the structuring that I
> proposed. I actually thought about a Levenshtein distance operator at
> one point months ago, before I entirely gave up on that.
Robert Haas writes:
> On Mon, Jul 21, 2014 at 10:52 AM, Emre Hasegeli wrote:
>> The first two shapes on src/test/regress/sql/polygon.sql do not make
>> sense to me.
> Well, I think the number of tabs that makes them look best depends on
> your tab-stop setting. At present, I find that with 8-sp
On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> This all seems completely to one side of Andres's point. I think what
> he's saying is: don't implement an SQL syntax of the form INSERT ON
> CONFLICT and let people use that to implement upsert. Instead,
> directly implement an SQL command c
Hi All,
On Wed, Jul 23, 2014 at 5:01 PM, Rohit Goyal wrote:
> Hi All,
>
> I am doing programming with postgresql source code. I want to find out the
> function which can give me Least active transaction id currenty in the
> system.
>
> Is there any function which can give me that?
>
> Regards,
>
On Mon, Jul 21, 2014 at 10:52 AM, Emre Hasegeli wrote:
> The first two shapes on src/test/regress/sql/polygon.sql do not make
> sense to me. They look more like polygons with some more tabs,
> but still did not match the coordinates. I changed them to make
> consistent with the shapes. I believ
On Mon, Jul 21, 2014 at 4:16 AM, Amit Kapila wrote:
> During internals tests, it is observed that checkpointer
> is getting crashed on slave with below log on slave in
> windows:
>
> LOG: checkpointer process (PID 4040) was terminated by exception 0xC005
> HINT: See C include file "ntstatus.
On Wed, Jul 23, 2014 at 8:57 AM, Robert Haas wrote:
> There are several possible methods of doing that, but I think the best
> one is just to leave the SQL-callable C functions in fuzzystrmatch and
> move only the underlying code that supports into core.
For some reason I thought that that was wh
Jonathan S. Katz wrote:
> Well that definitely answers "how hard would it be." - before
> embarking on something laborious (as even just indexing is
> nontrivial), I think it would be good to figure out how people are
> using IS [NOT] DISTINCT FROM and if there is interest in having it be
> indexa
I wrote:
> Oh ... the TUG page now has a recipe for finding the problem less
> painfully, which I don't recall having seen before:
> http://ftp.tug.org/mail-archives/pdftex/2002-February/002216.html
> In short, you can add a "draft" option that lets PDF output get generated
> anyway, and then you c
Jonathan S. Katz wrote:
> before embarking on something laborious (as even just indexing
> is nontrivial), I think it would be good to figure out how people
> are using IS [NOT] DISTINCT FROM and if there is interest in
> having it be indexable, let alone used in a JOIN optimization.
> It could b
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> No, ALTER SYSTEM is there now and it needs to work right in its first
> >> release. I will go fix this if nobody else does.
>
> > Just checking -- you didn't get around to dealing with this, right?
>
> Not yet... do you want it?
> That seems like a nonstarter :-(. Index-only scans don't have a license
> to return approximations. If we drop the behavior for circles, how much
> functionality do we have left?
It should work with exact operator classes, box_ops, point_ops,
range_ops, inet_ops.
--
Sent via pgsql-hackers m
On Sat, Jul 19, 2014 at 10:04 PM, Peter Geoghegan wrote:
> On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund
> wrote:
>> Meh. A understandable syntax wouldn't require the pullups with a special
>> scan node and such.
>
> Well, in general ExecModifyTable()/ExecUpdate() trusts the tid passed
> to ma
Hello Robert,
Some review comments:
Thanks a lot for your return.
Please find attached two new parts of the patch (A for setrandom
extension, B for pgbench embedded test case extension).
1. I suggest that getExponentialrand and getGaussianrand be renamed to
getExponentialRand and getGaus
From: "Tom Lane"
This seems like a pretty unsafe suggestion, because the smgr level doesn't
know or care whether relations are temp; files are files. In any case it
would only paper over one specific instance of whatever problem you're
worried about, because sinval messages definitely do need t
Robert Haas writes:
> There are several possible methods of doing that, but I think the best
> one is just to leave the SQL-callable C functions in fuzzystrmatch and
> move only the underlying code that supports into core.
I hadn't been paying close attention to this thread, but I'd just assumed
On Thu, Jul 17, 2014 at 9:34 AM, Michael Paquier
wrote:
> Patch 1 does a couple of things:
> - fuzzystrmatch is dumped to 1.1, as Levenshtein functions are not part of
> it anymore, and moved to core.
> - Removal of the LESS_EQUAL flag that made the original submission patch
> harder to understand
On Thu, Jul 17, 2014 at 12:09 AM, Fabien COELHO wrote:
> pgbench with gaussian & exponential, part 1 of 2.
>
> This patch is a subset of the previous patch which only adds the two
> new \setrandom gaussian and exponantial variants, but not the
> adapted pgbench test cases, as suggested by Fujii Ma
On 23 July 2014 15:14, Michael Paquier wrote:
> I have spent some time digging more into this idea and finished with the
> patch attached
Thank you for investigating the idea. I'll review by Monday.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Sup
"MauMau" writes:
> Looking at smgrtruncate(), the sinval message is sent even when the
> truncated relation is a temporary relation. However, I think the sinval
> message is not necessary for temp relations, because each session doesn't
> see the temp relations of other sessions.
This seems l
Hi All,
I am doing programming with postgresql source code. I want to find out the
function which can give me Least active transaction id currenty in the
system.
Is there any function which can give me that?
Regards,
Rohit Goyal
Magnus Hagander writes:
> Have you figured out any way to actually track down which para has the
> problem itself, or is it all manual work?
Oh ... the TUG page now has a recipe for finding the problem less
painfully, which I don't recall having seen before:
http://ftp.tug.org/mail-archives/pdft
Magnus Hagander writes:
> On Wed, Jul 23, 2014 at 4:06 PM, Tom Lane wrote:
>> A more robust fix would be to identify the para where the problem actually
>> is and re-word it so that the link doesn't cross a *line* boundary (in
>> either US or A4). That makes it safe as long as that particular pa
Hello,
I'm investigating a mysterious hang problem on PostgreSQL 9.2.8. If many
sessions use temporary tables whose rows are deleted on commit, the hang
occurs. I'd like to show you the stack trace, but I'm trying to figure out
how to reproduce the problem. IIRC, the stack trace was as foll
On Wed, Jul 23, 2014 at 11:22 PM, Tom Lane wrote:
> Was that a backend that you directly killed? Or the postmaster? The
> subsequent connection failures suggest it was the postmaster. Killing
> the postmaster is not a supported operation, not on Windows and not
> anywhere else either. It's in
Michael Paquier writes:
> While playing on Windows with services, I noticed an inconsistent behavior
> in the way failures are handled when using a service for a Postgres
> instance.
> ...
> However when a backend process is directly killed something different
> happens.
Was that a backend that y
On Tue, Jul 22, 2014 at 4:49 PM, Michael Paquier
wrote:
> Then, looking at the code, we would need to tweak XLogInsert for the
> WAL record construction to always do a FPW and to update
> XLogCheckBufferNeedsBackup. Then for the redo part, we would need to
> do some extra operations in the area o
On Wed, Jul 23, 2014 at 4:06 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander
>> wrote:
>>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than
>>> \pd
>
>> Additional point of info - the -US pdf's do build on this versi
Magnus Hagander writes:
> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander wrote:
>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than
>> \pd
> Additional point of info - the -US pdf's do build on this version,
> just not the -A4.
> And with even more of those entrie
On Wed, Jul 23, 2014 at 3:15 PM, Magnus Hagander wrote:
> On Wed, Jul 23, 2014 at 1:31 PM, Magnus Hagander wrote:
>> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander
>> wrote:
>>> It seems at least the 9.0 PDFs are broken (trying to build for the release):
>>>
>>> Lots of errors/warnings (and
On Wed, Jul 23, 2014 at 1:31 PM, Magnus Hagander wrote:
> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander wrote:
>> It seems at least the 9.0 PDFs are broken (trying to build for the release):
>>
>> Lots of errors/warnings (and AFAIK no way to see which is which in the
>> output), but It hink t
On Sun, Jun 29, 2014 at 9:01 PM, Thomas Munro wrote:
>
> Please find attached a rebased version of my SKIP LOCKED
> patch (formerly SKIP LOCKED DATA), updated to support only the
> Oracle-like syntax.
>
>
Hi Thomas,
Apologies for taking this long to get to reviewing this, I'd gotten a bit
side t
On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander wrote:
> It seems at least the 9.0 PDFs are broken (trying to build for the release):
>
> Lots of errors/warnings (and AFAIK no way to see which is which in the
> output), but It hink this is the telltale as usual:
>
> Overfull \hbox (7.12454pt too
It seems at least the 9.0 PDFs are broken (trying to build for the release):
Lots of errors/warnings (and AFAIK no way to see which is which in the
output), but It hink this is the telltale as usual:
Overfull \hbox (7.12454pt too wide) in paragraph at lines 88092--88092
[]\T1/pcr/m/n/9 CREATE FU
Re: Viswanatham kirankumar 2014-07-23
> 3) Host name is not a SQL object so it will be treated as case-sensitive
>except for all, samehost, samenet are considered as keywords.
>For these user need to use quotes to differentiate between hostname and
> keywords.
DNS is case-insensitive,
I'm trying to understand what would it take to have this patch in an
acceptable form before the next commitfest. Both Abhijit and Andres has
done some extensive review of the patch and have given many useful
suggestions to Rahila. While she has incorporated most of them, I feel we
are still some di
2014-07-23 8:38 GMT+02:00 Tomas Vondra :
> On 23 Červenec 2014, 7:36, Pavel Stehule wrote:
> >
> > updated version is in attachment
>
> OK, thanks. The new version seems OK to me.
>
Thank you
Pavel
>
> Tomas
>
>
64 matches
Mail list logo
