Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

> > I think the proposed idea of applying record::text explicit coercion to a > whole-row reference in the IS NOT NULL condition in the CASE WHEN > conversion would work as expected as you explained, but I'm concerned that > the cost wouldn't be negligible when the foreign table has a lot of column

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 3:22 PM, Craig Ringer wrote: > > > On 24 June 2016 at 10:28, Michael Paquier wrote: >> >> On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer >> wrote: >> > * Launch a VS x86 command prompt >> > * devenv /debugexe bin\initdb.exe -D test >> > * Set a breakpoint in initdb.

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/22 19:37, Ashutosh Bapat wrote: On Wed, Jun 22, 2016 at 3:57 PM, Etsuro Fujita Maybe I'm confused, but I think that in the system-column case it's the user's responsibility to specify system columns for foreign tables in a local query only when that makes sense on the remot

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:28, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer > wrote: > > * Launch a VS x86 command prompt > > * devenv /debugexe bin\initdb.exe -D test > > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > > * Run > > * When it traps at get_r

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Jun 23, 2016 at 3:51 PM, Michael Paquier wrote: > By the way, do you mind if I add this patch to the next CF? Better not > to lose track of it... Well, I have added an entry here at the end: https://commitfest.postgresql.org/10/654/ Better doing it now before I forget about it... -- Mich

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 13:00, Craig Ringer wrote: > I've now reproduced it with: > I can also confirm that it _doesn't_ crash with the same SDK using a 32-bit build (running under WoW on x64). cl 18.00.40629 for x86, env: %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 12:31, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer > wrote: > > Given that it's only been seen in VS 2013, it's particularly odd that > it's > > not biting woodlouse. > > > > I'd like more details from those whose installs are crashing. What exact >

Re: [HACKERS] Missing checks when malloc returns NULL...

On Wed, Jun 22, 2016 at 10:41 AM, Michael Paquier wrote: > OK, there is not much that we can do here then. What about the rest? > Those seem like legit concerns to me. Registered this one to the next CF as a bug fix: https://commitfest.postgresql.org/10/653/ It would be better not to crash if we

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer wrote: > Given that it's only been seen in VS 2013, it's particularly odd that it's > not biting woodlouse. > > I'd like more details from those whose installs are crashing. What exact > vcvars env did you run under, with which exact cl.exe version? W

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 05:17, Umair Shahid wrote: > >> > It's still strange that it doesn't affect woodlouse. >> >> Or any of the other Windows critters... >> >> > Given that it's only been seen in VS 2013, it's particularly odd that it's not biting woodlouse. I'd like

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

On Thu, Jun 23, 2016 at 8:35 PM, Tom Lane wrote: > We *do* have regression test coverage, but that code is set up to not > kick in at any index scale that would be sane to test in the regression > tests. See > https://www.postgresql.org/message-id/12194.1466724...@sss.pgh.pa.us I'm well aware of

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

Peter Geoghegan writes: > FWIW, I think that that bug tells us a lot about hash index usage in > the field. It took many months for someone to complain about what > ought to have been a really obvious bug. Clearly, hardly anybody is > using hash indexes. I broke hash index tuplesort builds in a si

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote: > I think this may be premature in view of bug #14210. Even if we > don't reinstate use of this function to fix that, I'm not really > convinced we want to get rid of it; it seems likely to me that > we might want it again. Oh, yes; that involves

Re: [HACKERS] Odd behavior with domains

I was the one that reported that on twitter. I have a more detailed message on the general list that I sent before subscribing and probably needs to be moderated (or if it went to /dev/null let me know). On Thu, Jun 23, 2016 at 11:01 PM Tom Lane wrote: > "Joshua D. Drake" writes: > > So this ca

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:51 AM, Tsunakawa, Takayuki wrote: >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier >> Sent: Friday, June 24, 2016 11:37 AM >> On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer >> wrote: >> It might be w

Re: [HACKERS] Odd behavior with domains

"Joshua D. Drake" writes: > So this came across my twitter feed: > https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png public.text can exist in parallel with pg_catalog.text. Nothing to see here, move along. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] Odd behavior with domains

Joshua D. Drake wrote: > Hey, > > So this came across my twitter feed: > > https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png > > I have verified the oddness with a newer version: Well, it's not specifically related to domains -- it's related to the fact that pg_catalog objects mask the domain you

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

Peter Geoghegan writes: > Commit 9f03ca915 removed the only COPYTUP() call that could reach > copytup_index() in practice, making copytup_index() dead code. > The attached patch removes this dead code, I think this may be premature in view of bug #14210. Even if we don't reinstate use of this f

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Sent: Friday, June 24, 2016 11:37 AM > On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer > wrote: > It might be worth testing that out and adding an initdb startup flag > > to creat

Re: [HACKERS] Odd behavior with domains

On Thu, Jun 23, 2016 at 10:16 PM, Joshua D. Drake wrote: > Hey, > > So this came across my twitter feed: > > https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png > > I have verified the oddness with a newer version: > > psql -U postgres > psql (9.5.3) > Type "help" for help. > > postgres=# create doma

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer wrote: > Yes, quite possibly, actually. I should've just got Haroon to build me a new > initdb without the priv setting and with creation of crashdumps/ . > > It might be worth testing that out and adding an initdb startup flag to > create the directo

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:28, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer > wrote: > > * Launch a VS x86 command prompt > > * devenv /debugexe bin\initdb.exe -D test > > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > > * Run > > * When it traps at get_r

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:21, Craig Ringer wrote: > * To get a backtrace, I had to: > > * Launch a VS x86 command prompt > * devenv /debugexe bin\initdb.exe -D test > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > * Run > * When it traps at get_restricted_token(), manually move th

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer wrote: > * Launch a VS x86 command prompt > * devenv /debugexe bin\initdb.exe -D test > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > * Run > * When it traps at get_restricted_token(), manually move the execution > pointer over the

Re: [HACKERS] Hash Indexes

On Thu, Jun 23, 2016 at 10:56 PM, Robert Haas wrote: > On Wed, Jun 22, 2016 at 10:13 PM, Amit Kapila wrote: >>> A scan that has seen the flag won't look at the >>> tuple in any case. >> >> Why so? Assume that scan started on new bucket where >> split-in-progress flag was set, now it will not lo

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 05:17, Umair Shahid wrote: > On Fri, Jun 24, 2016 at 2:14 AM, Umair Shahid < > umair.sha...@2ndquadrant.com> wrote: > >> >> -- Forwarded message -- >> From: Tom Lane >> Date: Thu, Jun 23, 2016 at 9:32 PM >> Subject: Re: [pgsql-packagers] PG 9.6beta2 tarballs ar

[HACKERS] Odd behavior with domains

Hey, So this came across my twitter feed: https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png I have verified the oddness with a newer version: psql -U postgres psql (9.5.3) Type "help" for help. postgres=# create domain text char(3); CREATE DOMAIN postgres=# create domain text char(2); ERROR: t

[HACKERS] tuplesort.c's copytup_index() is dead code

Commit 9f03ca915 removed the only COPYTUP() call that could reach copytup_index() in practice, making copytup_index() dead code. The attached patch removes this dead code, in line with the existing copytup_datum() case, where tuplesort.c also doesn't directly support COPYTUP() (due to similar cons

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 24, 2016 at 4:33 AM, Andres Freund wrote: > On 2016-06-23 18:59:57 -0400, Alvaro Herrera wrote: >> Andres Freund wrote: >> >> > I'm looking into three approaches right now: >> > >> > 3) Use WAL logging for the already_marked = true case. >> >> >> > 3) This approach so far seems the bes

Re: [HACKERS] Rethinking representation of partial-aggregate steps

On 24 June 2016 at 05:55, Tom Lane wrote: > #define AGGOP_COMBINESTATES 0x1 > #define AGGOP_SERIALIZESTATES 0x2 > #define AGGOP_DESERIALIZESTATES 0x4 > #define AGGOP_FINALIZEAGGS 0x8 > > typedef enum AggPartialMode > { > AGGPARTIAL_SIMPLE = AGGOP_FINALIZEAGGS, > AGGPARTIAL_PARTIAL = AGGOP_

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer Now, what I do think we need is to give the client the ability to determine whether one of its xacts actually committed or not when it lost the session after dispatching COMMIT but befo

Re: [HACKERS] Rethinking representation of partial-aggregate steps

David Rowley writes: > As for the above proposal, I do agree that it'll be cleaner with bit > flags, I just really don't see the need for the AGGTYPE_* alias > macros. For me it's easier to read if each option is explicitly listed > similar to how pull_var_clause() is done, e.g: That does not sou

Re: [HACKERS] Rethinking representation of partial-aggregate steps

On 24 June 2016 at 05:12, Robert Haas wrote: > I do agree, however, that the three Boolean flags don't make the code > entirely easy to read. What I might suggest is that we replace the > three Boolean flags with integer flags, something like this: > > #define AGGOP_COMBINESTATES 0x1 > #define

Re: [HACKERS] Reviewing freeze map code

On 2016-06-23 18:59:57 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > > I'm looking into three approaches right now: > > > > 3) Use WAL logging for the already_marked = true case. > > > > 3) This approach so far seems the best. It's possible to reuse the > > xl_heap_lock record (in an

Re: [HACKERS] Reviewing freeze map code

Andres Freund wrote: > I'm looking into three approaches right now: > > 3) Use WAL logging for the already_marked = true case. > 3) This approach so far seems the best. It's possible to reuse the > xl_heap_lock record (in an afaics backwards compatible manner), and in > most cases the overhead

Re: [HACKERS] Rethinking representation of partial-aggregate steps

On 24 June 2016 at 05:25, Tom Lane wrote: > Robert Haas writes: >> Hmm, well I guess I would have to disagree with the idea that those >> other modes aren't useful. I seem to recall that David had some >> performance results showing that pushing partial aggregate steps below >> an Append node res

Re: [HACKERS] Reviewing freeze map code

On 2016-06-21 16:32:03 -0400, Robert Haas wrote: > On Tue, Jun 21, 2016 at 3:46 PM, Andres Freund wrote: > > On 2016-06-21 15:38:25 -0400, Robert Haas wrote: > >> On Tue, Jun 21, 2016 at 1:49 PM, Andres Freund wrote: > >> >> I'm also a bit dubious that LockAcquire is safe to call in general > >>

Re: [HACKERS] Questionabl description in datatype.sgml

> On Sat, Jun 18, 2016 at 11:58:58AM -0400, Tom Lane wrote: >> Tatsuo Ishii writes: >> > In "8.13.2. Encoding Handling" >> > >> > When using binary mode to pass query parameters to the server >> > and query results back to the client, no character set conversion >> > is performed,

Re: [HACKERS] Protocol buffer support for Postgres

On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote: > On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote: >> >> I'd love to talk more about this. > > I thought quite a bit about this a few years ago but never really > picked up it to work on. > > Another option would be to allow the output of yo

[HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 2:14 AM, Umair Shahid wrote: > > -- Forwarded message -- > From: Tom Lane > Date: Thu, Jun 23, 2016 at 9:32 PM > Subject: Re: [pgsql-packagers] PG 9.6beta2 tarballs are ready > To: Magnus Hagander > Cc: Umair Shahid , Dave Page < > dp...@postgresql.org>,

Re: [HACKERS] Protocol buffer support for Postgres

On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote: > > I'd love to talk more about this. I thought quite a bit about this a few years ago but never really picked up it to work on. There are different use cases where this could be useful and different approaches that could be useful for the di

Re: [HACKERS] Protocol buffer support for Postgres

On Tue, Apr 26, 2016 at 2:40:49PM -0700, David Fetter wrote: > Should we see about making a more flexible serialization > infrastructure? What we have is mostly /ad hoc/, and has already > caused real pain to the PostGIS folks, this even after some pretty > significant and successful efforts were

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 2:00 PM, Robert Haas wrote: > On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston > wrote: > >> Sheesh. Who put you in charge of this? You basically seem like you > >> are trying to shut up anyone who supports this change, and I don't > >> think that's right. > > > > I'm

Re: [HACKERS] Bug in to_timestamp().

On 6/23/16 12:29 PM, Alvaro Herrera wrote: David G. Johnston wrote: On Thursday, June 23, 2016, Alex Ignatov wrote: Arguing just like that one can say that we don't even need exception like "division by zero". Just use well-formed numbers in denominator... Input data sometimes can be generat

Re: [HACKERS] Rethinking representation of partial-aggregate steps

Alvaro Herrera writes: > Tom Lane wrote: >> Yeah, that's another way we could go. I had been considering a variant >> of that, which was to assign specific code values to the enum constants >> and then invent macros that did bit-anding tests on them. That ends up >> being just about what you pro

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote: >> At the very least I'd want to see a thought-through proposal that >> addresses all three of these interrelated points: >> >> * what should a space in the format match >> * what should a non-space, non-format-code character

Re: [HACKERS] Rethinking representation of partial-aggregate steps

Tom Lane wrote: > What I'm imagining is, say, > > #define AGGOP_COMBINESTATES 0x1 > #define AGGOP_SERIALIZESTATES 0x2 > #define AGGOP_DESERIALIZESTATES 0x4 > #define AGGOP_FINALIZEAGGS 0x8 > > typedef enum AggPartialMode > { > AGGPARTIAL_SIMPLE = AGGOP_FINALIZEAGGS, > AGGPARTIAL_PARTIAL

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston wrote: >> Sheesh. Who put you in charge of this? You basically seem like you >> are trying to shut up anyone who supports this change, and I don't >> think that's right. > > I'm all for a change in this area - though I'm not impacted enough to >

Re: [HACKERS] Rethinking representation of partial-aggregate steps

On 23 June 2016 at 18:31, Robert Haas wrote: > > Sure, but aggregating as early as possible will often have the effect > of dramatically reducing the number of tuples that have to pass > through upper levels of the plan tree, which seems it would frequently > far outweigh those considerations. >

Re: [HACKERS] Bug in to_timestamp().

On Thursday, June 23, 2016, Robert Haas wrote: > On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston > > wrote: > > to_timestamp with its present behavior is, IMO, a poorly designed > function > > that would never be accepted today. Concrete proposals for either > fixing or > > deprecating (or bo

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston >> wrote: >>> My understanding is that is not going to change for 9.6. > >> That's exactly what is under discussion here. > > I would definitely agree with David on that p

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston > wrote: >> My understanding is that is not going to change for 9.6. > That's exactly what is under discussion here. I would definitely agree with David on that point. Making to_timestamp noticeably better on this score s

Re: [HACKERS] Rethinking representation of partial-aggregate steps

Tom Lane wrote: > Robert Haas writes: > > I do agree, however, that the three Boolean flags don't make the code > > entirely easy to read. What I might suggest is that we replace the > > three Boolean flags with integer flags, something like this: > > Yeah, that's another way we could go. I ha

Re: [HACKERS] Rethinking representation of partial-aggregate steps

On Thu, Jun 23, 2016 at 1:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 23, 2016 at 12:26 PM, Tom Lane wrote: >>> I'm inclined to think that we should aggressively simplify here, perhaps >>> replacing all three of these flags with a three-way enum, say >>> >>> PARTIALAGG_NORMAL

Re: [HACKERS] Bug in to_timestamp().

David G. Johnston wrote: > On Thursday, June 23, 2016, Alex Ignatov wrote: > > > Arguing just like that one can say that we don't even need exception like > > "division by zero". Just use well-formed numbers in denominator... > > Input data sometimes can be generated automagically. Without excep

Re: [HACKERS] Hash Indexes

On Wed, Jun 22, 2016 at 10:13 PM, Amit Kapila wrote: >> A scan that has seen the flag won't look at the >> tuple in any case. > > Why so? Assume that scan started on new bucket where > split-in-progress flag was set, now it will not look at tuples that > are marked as moved-by-split in this buck

Re: [HACKERS] Rethinking representation of partial-aggregate steps

Robert Haas writes: > On Thu, Jun 23, 2016 at 12:26 PM, Tom Lane wrote: >> I'm inclined to think that we should aggressively simplify here, perhaps >> replacing all three of these flags with a three-way enum, say >> >> PARTIALAGG_NORMAL /* simple aggregation */ >> PARTIALAGG_PARTIAL /

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston wrote: > to_timestamp with its present behavior is, IMO, a poorly designed function > that would never be accepted today. Concrete proposals for either fixing or > deprecating (or both) are welcome. Fixing it should not cause unnecessary > error

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 12:37 PM, David G. Johnston wrote > To be honest I don't see how this is relevant to quoted content. And you've > already made this point quite clearly - repeating it isn't constructive. > This behavior has existed for a long time and I don't see that changing it > is a wo

Re: [HACKERS] Bug in to_timestamp().

On Thursday, June 23, 2016, Alex Ignatov wrote: > Arguing just like that one can say that we don't even need exception like > "division by zero". Just use well-formed numbers in denominator... > Input data sometimes can be generated automagically. Without exception > throwing debugging stored fu

Re: [HACKERS] Rethinking representation of partial-aggregate steps

On Thu, Jun 23, 2016 at 12:26 PM, Tom Lane wrote: > I really dislike this aspect of the partial-aggregate patch: > > typedef struct Agg > { > ... > boolcombineStates; /* input tuples contain transition states */ > boolfinalizeAggs; /* should we call the finalfn on ag

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 19:37, David G. Johnston wrote: On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov mailto:a.igna...@postgrespro.ru>>wrote: On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: On Monday, 20 June 2016 8:53 PM, A

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov wrote: > > On 23.06.2016 16:30, Bruce Momjian wrote: > >> On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: >> >>> On Monday, 20 June 2016 8:53 PM, Alex Ignatov >>> wrote: >>> >>> >>> On 13.06.2016 18:52, amul sul wrote: > And it wo

[HACKERS] Rethinking representation of partial-aggregate steps

I really dislike this aspect of the partial-aggregate patch: typedef struct Agg { ... boolcombineStates; /* input tuples contain transition states */ boolfinalizeAggs; /* should we call the finalfn on agg states? */ boolserialStates; /* should agg state

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote: On 13.06.2016 18:52, amul sul wrote: And it wont stop on some simple whitespace. By using to_timestamp you can get any output results by

Re: [HACKERS] Parallelized polymorphic aggs, and aggtype vs aggoutputtype

David Rowley writes: > On 23 June 2016 at 11:22, Tom Lane wrote: >> The behavior that I'd expect (and that I documented) for a deserialization >> function is that it just allocates its result in the current, short-lived >> memory context, since it will be the combine function's responsibility to

Re: [HACKERS] how is the WAL receiver process stopped and restarted when the network connection is broken and then restored?

Thank you Craig for your suggestion. I followed the clue and spent the whole day digging into the code. Finally I figured out how the WAL receiver exits and restarts. Question-1. How the WAL receiver process exits === When the network connection is bro

Re: [HACKERS] PQconnectdbParams vs PQconninfoParse

Craig Ringer writes: > While writing some code that takes a connstring and adds some parameters, I > noticed that PQconninfoParse doesn't play well with PQconnectdbParams. > PQconnectdbParams takes a pair of equal-length arrays, one for keys and one > for values, each terminated by null elements.

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: > On Monday, 20 June 2016 8:53 PM, Alex Ignatov > wrote: > > > >>On 13.06.2016 18:52, amul sul wrote: > >And it wont stop on some simple whitespace. By using to_timestamp you > >can get any output results by providing illegal input para

Re: [HACKERS] Question and suggestion about application binary compatibility policy

On Thu, Jun 23, 2016 at 06:42:57AM +, Tsunakawa, Takayuki wrote: > > From: Bruce Momjian [mailto:br...@momjian.us] > > We have this text in src/tools/RELEASE_CHANGES: > > ... > > This is saying running against a mismatched minor version should be fine > > for a binary. > > Thanks for a good ra

[HACKERS] Extract Jsonb key and values

Hi all, I am having jsonb as C character string received by WAL decoding and want to extract all its key and value pairs. Which is the best approach for extracting keys and its values? i) Converting the C string to a PostgreSQL jsonb object ii) Using open-source json-c

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

On 23 June 2016 at 17:34, Terje Elde wrote: > > But what if there’s a bug making a call to the external service? Most of > the time, you’ll trap the error and set status to something sane, but what > if there’s a crash-bug in the SDK implementing it, or some other situation > where things go ve

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

> On 23 Jun 2016, at 11:50, Marko Tiikkaja wrote: > > Comparing these two; how is the latter any better? It's the same number of > commands, except it's holding a transaction open for longer, it's using a > non-standard concept and it's arguably more complex. Same number of commands, but hal

Re: [HACKERS] Requesting external_pid_file with postgres -C when not initialized lead to coredump

Testing that external_pid_file was not null didn't seem necessary to me because it's initialized to '' and background workers could only start after the startup piece of code. If external_pid_file is set to null while the server run, then I prefer to not hide the problem as it would only be report

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

On 2016-06-23 12:34, Terje Elde wrote: Typically the flow would be something like: BEGIN; SELECT id FROM targets WHERE status=‘scheduled’ FOR UPDATE SKIP LOCKED LIMIT 1; UPDATE targets SET status=‘in-flight’ WHERE id =%(id); COMMIT; — Do the work. BEGIN; UPDATE targets SET status=‘completed’ WHE

[HACKERS] Feature suggestions: "dead letter"-savepoint.

Hi all, I’d like to pitch the idea of supporting “dead letter”-savepoints, similar to the way you have “dead letter”-exchanges in message-queue systems, etc. The idea is basically that a client can publish a message, but in such a away that it only ever actually gets published if the client di

[HACKERS] PQconnectdbParams vs PQconninfoParse

Hi all While writing some code that takes a connstring and adds some parameters, I noticed that PQconninfoParse doesn't play well with PQconnectdbParams. PQconnectdbParams takes a pair of equal-length arrays, one for keys and one for values, each terminated by null elements. But PQconninfoParse

Re: [HACKERS] Bug in to_timestamp().

On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote: >>On 13.06.2016 18:52, amul sul wrote: >And it wont stop on some simple whitespace. By using to_timestamp you >can get any output results by providing illegal input parameters values: >postgres=# SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'Y

[HACKERS] Comment and function argument names are mismatched in bugmgr.c.

Hi all, By commit 428b1d6b, function WritebackContextInit is added but the comment of this function seems to be incorrect. *max_coalesce variable doesn't exist at anywhere. Also, I think it should be fixed that the argument name of this function does not match function declare in buf_internal.h. P