We got the following assertion failure at our buildfarm of master branch
of Postgres in contrib/test_decoding regression tests:
2018-05-07 19:50:07.241 MSK [5af083bf.54ae:49] DETAIL: Streaming transactions
committing after 0/2A0, reading WAL from 0/29FFF1C.
2018-05-07 19:50:07.241 MSK [5af
Previous code uses BasicOpenFile() + close().
access() should be faster than BasicOpenFile()+close() and access()
should be more correct since BasicOpenFile() could fail for various
cases (e.g. due to file permission, etc) even the file exists.
access() is supported on Linux/Unix. I do not have a
On 17.05.2018 05:19, Andres Freund wrote:
On 2018-05-16 22:11:22 -0400, Tom Lane wrote:
David Rowley writes:
On 17 May 2018 at 11:00, Andres Freund wrote:
Wonder if we shouldn't just cache an estimated relation size in the
relcache entry till then. For planning purposes we don't need to be
Hello, as in pgsql-bug ML.
https://www.postgresql.org/message-id/20180517.170021.24356216.horiguchi.kyot...@lab.ntt.co.jp
Master can go into infinite loop on shutdown. But it is caused by
a broken database like storage rolled-back one. (The steps to
replay this is shown in the above mail.)
I thi
Thanks. I tentatively submitted a patch (See the attachment).
By the way, current pg_upgrade test script depends on the left data on test
database, but it seems that
a lot of tables are dropped in those test SQL files so this affects the
pg_upgrade test coverage much.
Maybe this needs to be addres
On Thu, May 3, 2018 at 12:19 AM, John Naylor wrote:
> Attached is a draft patch to do this, along with the conversion script
> used to create the entries. In writing this, a few points came up that
> are worth bringing up:
Hi John,
This failed for my patch testing robot on Windows, with this mes
At Wed, 16 May 2018 12:37:48 -0400, Robert Haas wrote
in
> On Wed, May 16, 2018 at 11:28 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, May 15, 2018 at 4:46 AM, Ideriha, Takeshi
> >> wrote:
> >>> I noticed that if log_min_messages is set to ‘debug2’, it shows ‘debug’
> >>> instead o
On Thu, May 17, 2018 at 04:09:27PM +0800, Paul Guo wrote:
> Previous code uses BasicOpenFile() + close().
>
> access() should be faster than BasicOpenFile()+close() and access()
> should be more correct since BasicOpenFile() could fail for various
> cases (e.g. due to file permission, etc) even th
F_OK seems to be better than R_OK because we want to check file existence
(not read permission) before creating the relation file with the path
later.
2018-05-17 17:09 GMT+08:00 Michael Paquier :
> On Thu, May 17, 2018 at 04:09:27PM +0800, Paul Guo wrote:
> > Previous code uses BasicOpenFile() +
On 17.05.2018 10:45, Konstantin Knizhnik wrote:
We got the following assertion failure at our buildfarm of master
branch of Postgres in contrib/test_decoding regression tests:
2018-05-07 19:50:07.241 MSK [5af083bf.54ae:49] DETAIL: Streaming transactions
committing after 0/2A0, reading W
Hi
just for curiosity - I tested simple script
postgres=# do
$$
declare s bigint = 0;
begin
for i in 1..10 loop
s := s + i;
end loop;
raise notice '%', s;
end;
$$;
to see a overhead of some components
5,72% plpgsql.so [.] exec_assign_value
5,
Hi,
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> David Rowley writes:
> > On 16 May 2018 at 02:01, Tom Lane wrote:
> >> I'm not particularly fussed about getting credit for that. However,
> >> looking again at how that patch series turned out --- ie, that we
> >> ensured POSIX behavior for N
2018-05-17 11:32 GMT+02:00 Pavel Stehule :
> Hi
>
> just for curiosity - I tested simple script
>
> postgres=# do
> $$
> declare s bigint = 0;
> begin
> for i in 1..10 loop
> s := s + i;
> end loop;
> raise notice '%', s;
> end;
> $$;
>
> to see a overhead of some components
>
>
Konstantin Knizhnik writes:
> I think that using restart_lsn instead of confirmed_flush is not right
> approach.
> If restart_lsn is not available and confirmed_flush is pointing to page
> boundary, then in any case we should somehow handle this case and adjust
> startlsn to point on the valid
(2018/05/16 22:49), Ashutosh Bapat wrote:
On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita
wrote:
However, considering that
pull_var_clause is used in many places where partitioning is *not* involved,
I still think it's better to avoid spending extra cycles needed only for
partitioning in that f
On Thu, May 17, 2018 at 12:31:09PM +0300, Konstantin Knizhnik wrote:
> I wonder who is now maintaining logical replication stuff and whether this
> bug is going to be fixed?
I haven't looked at your problem in details so I cannot give a sure
conclusion, but when it comes to pg_replication_slot_adv
On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote:
> On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
>> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
>>> SCRAM-with-binding is the first password method that attempts to avoid
>>> man-in-the-middle attack
(2018/05/17 14:19), Amit Langote wrote:
Looking at this for a bit, I wondered if this crash wouldn't have occurred
if the "propagation" had also considered join relations in addition to
simple relations. For example, if I changed inheritance_planner like the
attached (not proposing that we consi
On 5/12/18 17:25, Tom Lane wrote:
> Anyway, attached is a revised patch. I found a test case for
> expanded_record_set_fields(), too.
Thank you for fixing this up.
In reviewing the committed patch, I noticed that in ER_get_flat_size()
you have removed the PG_DETOAST_DATUM() call and let
expanded
On Thu, May 17, 2018 at 05:23:28PM +0800, Paul Guo wrote:
> F_OK seems to be better than R_OK because we want to check file existence
> (not read permission) before creating the relation file with the path
> later.
Please do not top-post, this breaks the discussion logic of the thread.
Perhaps To
On Thu, May 17, 2018 at 4:20 AM, Paul Guo wrote:
> Thanks. I tentatively submitted a patch (See the attachment).
You probably want to add this to the next Commitfest.
> By the way, current pg_upgrade test script depends on the left data on test
> database, but it seems that
> a lot of tables are
On Wed, May 16, 2018 at 3:20 PM, Robert Haas wrote:
> On Wed, May 16, 2018 at 2:28 PM, David Rowley
> wrote:
>> Thanks for committing. Although, I disagree with your tweak:
>>
>> +* 1-based index into the *pds list.
>>
>> I think that's making the same mistake as the last comment did. You
>>
On Thu, May 17, 2018 at 4:58 AM, Kyotaro HORIGUCHI
wrote:
> It's not about me, but without knowing the history, "debug" can
> look as if it is less chatty than "debug2" or even "debug1". All
> log level of "debugN" are seen as DEBUG in log lines. Thus
> showing "debug2" as just "debug" may obfusca
Hi Bruce,
Here is some bonus feedback.
On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> I expect a torrent of feedback. ;-)
I have just noticed that this entry does not have the correct author
(guess who?):
Add libpq option to support channel binding when using SCRAM
Hi all,
I've got some question about XML OPTION and pg_restore.
In a xml type column are stored documents.
When restoring a plain SQL dump, we got the message :
/ERROR: invalid XML content//
//DETAIL: line 1: StartTag: invalid element name//
//http://mrcc.com/qgis.dtd' 'SYSTEM'>//
// ^//
//C
On Thu, May 17, 2018 at 2:56 AM, Michael Paquier
wrote:
> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> > SCRAM-with-binding is the first password method that attempts to avoid
> > man-in-the-middle attacks, and therefore is much less likely to be able
> > to trust what the end
Hello,
Earlier this week we have split our Postgres 9.6.8 shards, each having two
databases, into one database per shard setup. This was done by promoting
replicas and subsequently removing unused databases.
Immediately afterwards we have discovered repeated 'tuple concurrently updated'
errors on
On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote:
> > > FYI, I think the server could also require channel binding for SCRAM. We
> > > already have scram-sha-256 in pg_hba.conf, and I think
> > > scram-sha-256-plus would be reasonable.
> >
> > Noted as well. There is of course the qu
On Thu, May 17, 2018 at 09:48:54PM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote:
> > On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
> >> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> >>> SCRAM-with-binding is the
On Wed, May 16, 2018 at 4:42 PM, Arthur Zakirov
wrote:
> I haven't deep knowledge about guts of invalidation callbacks. It seems
> that there is problem with it. Tom pointed above:
>
>> > I'm not sure that I understood the second case correclty. Can cache
>> > invalidation help in this case? I don
On Thu, May 17, 2018 at 03:38:36PM +0200, Magnus Hagander wrote:
> What's the take of others? Magnus, Stephen or Heikki perhaps (you've
> been the most involved with SCRAM early talks)?
>
> Saw it by luck. It would probably be better if it wasn't hidden deep in a
> thread about release no
Peter Eisentraut writes:
> In reviewing the committed patch, I noticed that in ER_get_flat_size()
> you have removed the PG_DETOAST_DATUM() call and let
> expanded_record_set_field_internal() do the de-toasting work. I had
> considered that too, but my impression is that the purpose of the
> PG_D
Robert Haas writes:
> Hang on, I can't be wrong (famous last words). If the negative
> indexes were 0-based, that would mean that the first element of the
> list was referenced by -0, which obviously can't be true, because 0 =
> -0. In other words, we can't be using 0-based indexing for both the
Robert Haas writes:
> ... Assuming that we can
> convince ourselves that that much is OK, I don't see why using a
> syscache callback to help ensure that the mappings are blown away in
> an at-least-somewhat-timely fashion is worse than any other approach.
I think the point you've not addressed i
On Thu, May 17, 2018 at 4:50 PM, Etsuro Fujita
wrote:
> (2018/05/16 22:49), Ashutosh Bapat wrote:
>>
>> On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita
>> wrote:
>>>
>>> However, considering that
>>> pull_var_clause is used in many places where partitioning is *not*
>>> involved,
>>> I still thin
On Thu, May 17, 2018 at 12:04 AM, David Rowley
wrote:
>> Append
>> Execution-Time Pruning: order_lines (at executor startup)
>> -> Index Scan ...
>
> Perhaps Append should be shown as "Unordered Partitioned Table Scan on
> ". That seems more aligned to how else we show which relation a
> node
On Thu, May 17, 2018 at 10:29 PM, Robert Haas wrote:
> Unless the indexing system actually can't reference the first element
> of *pds, and -1 means the second element. But then I think we need a
> more verbose explanation here.
First element in *pds list (and the array subsequently created from
Huong Dangminh writes:
> Thank you. The patch looks fine to me.
> Also, I have done the "make check" in Windows and Linux environment with no
> problem.
Pushed, thanks for reviewing/testing.
regards, tom lane
> "Tom" == Tom Lane writes:
Tom> What amcanbackward is about is whether the index can support
Tom> reversing direction mid-scan, as would be required to support
Tom> FETCH FORWARD followed by FETCH BACKWARD in a cursor. That's
Tom> actually independent of whether the index can implement a
Andrew Gierth writes:
> Ugh, so the docs for amutils get this wrong, and if I'd looked at this
> more carefully when doing them to begin with I'd have given the
> 'backwards_scan' property a better name or omitted it entirely.
Ooops.
> I'll fix the docs accordingly. I'm referring specifically to
On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote:
> Andrew Gierth writes:
> > I'll fix the docs accordingly. I'm referring specifically to this bit:
> > https://www.postgresql.org/docs/current/static/functions-
> info.html#FUNCTIONS-INFO-INDEX-PROPS
> > which I think should say "Can the scan dire
"David G. Johnston" writes:
> On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote:
>> Maybe "Can the scan direction be reversed in mid-scan?". I'm not
>> absolutely sure that that's better ...
> A cursory read might conclude that "reversing" can only happen once while
> they will likely understand
Hi,
On 2018-05-17 17:19:00 +0900, Kyotaro HORIGUCHI wrote:
> Hello, as in pgsql-bug ML.
>
> https://www.postgresql.org/message-id/20180517.170021.24356216.horiguchi.kyot...@lab.ntt.co.jp
>
> Master can go into infinite loop on shutdown. But it is caused by
> a broken database like storage rolled
On Thu, May 17, 2018 at 09:57:59AM -0400, Robert Haas wrote:
> I think you and Tom have misunderstood each other somehow. If you
> look at CommitTransaction(), you will see a comment that says:
Oh, I understood. You are right.
> Also, there is no absolute prohibition on kernel calls in post-comm
Hi,
On 2018-05-10 09:50:03 +0800, Craig Ringer wrote:
> while ((src = (RewriteMappingFile *) hash_seq_search(&seq_status)) !=
> NULL)
> {
> if (FileSync(src->vfd, WAIT_EVENT_LOGICAL_REWRITE_SYNC) != 0)
> - ereport(ERROR,
> + erepor
On 2018-May-17, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote:
> >> Maybe "Can the scan direction be reversed in mid-scan?". I'm not
> >> absolutely sure that that's better ...
>
> > A cursory read might conclude that "reversing" can only ha
On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> ... Assuming that we can
>> convince ourselves that that much is OK, I don't see why using a
>> syscache callback to help ensure that the mappings are blown away in
>> an at-least-somewhat-timely fashion is worse than any
> "Alvaro" == Alvaro Herrera writes:
>> "Can the scan direction be changed in mid-scan (to support FETCH
>> FORWARD and FETCH BACKWARD on a cursor)?"
How about,
"Can the scan direction be changed in mid-scan (to support FETCH
BACKWARD on a cursor without needing materialization)?"
Alvar
Alvaro Herrera writes:
> To make matters worse, IIUC it's actually fine to read the cursor in one
> direction to completion, then in the other direction to completion,
> without this flag, right?
In principle that'd be possible without amcanbackward if you were to
shut down the plan at the end of
Robert Haas writes:
> On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote:
>> I think the point you've not addressed is that "syscache callback
>> occurred" does not equate to "object was dropped". Can the code
>> survive having this occur at any invalidation point?
>> (CLOBBER_CACHE_ALWAYS testing
On Thu, May 17, 2018 at 1:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote:
>>> I think the point you've not addressed is that "syscache callback
>>> occurred" does not equate to "object was dropped". Can the code
>>> survive having this occur at
On Thu, May 17, 2018 at 12:44 PM, Andres Freund wrote:
> Hi,
>
> On 2018-05-10 09:50:03 +0800, Craig Ringer wrote:
>> while ((src = (RewriteMappingFile *) hash_seq_search(&seq_status)) !=
>> NULL)
>> {
>> if (FileSync(src->vfd, WAIT_EVENT_LOGICAL_REWRITE_SYNC) != 0)
>> -
On Thu, May 17, 2018 at 10:36 AM, Amit Langote wrote:
> On Thu, May 17, 2018 at 10:29 PM, Robert Haas wrote:
>> Unless the indexing system actually can't reference the first element
>> of *pds, and -1 means the second element. But then I think we need a
>> more verbose explanation here.
>
> Firs
On Thu, May 17, 2018 at 10:35:53PM +0900, Michael Paquier wrote:
> Hi Bruce,
>
> Here is some bonus feedback.
>
> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > I expect a torrent of feedback. ;-)
>
> I have just noticed that this entry does not have the correct author
> (gu
On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat
wrote:
> The second would mean that SELECT * from foreign table reports
> remotetableoid as well, which is awkward.
No it wouldn't. You'd just make the additional column resjunk, same
as we do for wholerow.
> Anyway, my comment to which you have r
On 2018-May-17, Tom Lane wrote:
> Robert Haas writes:
> > Hang on, I can't be wrong (famous last words). If the negative
> > indexes were 0-based, that would mean that the first element of the
> > list was referenced by -0, which obviously can't be true, because 0 =
> > -0. In other words, we c
> "Charles" == Charles Cui writes:
Charles> I have the requirements to return a bytea array for some
Charles> functions in pg_thrift plugin.
If you mean you want the return value to be of type bytea[], i.e. an SQL
array of bytea values, then you need to be using construct_array to
construc
Peter Eisentraut writes:
> I think I have made a mistake here. I was reading in between the lines
> of a competitor's documentation that they have functions and procedures
> in different name spaces, which made me re-read the SQL standard, which
> appears to support that approach.
> So I'm propo
On 18 May 2018 at 06:21, Robert Haas wrote:
> All right, so let's just say that explicitly. Maybe something like
> the attached.
That looks fine to me.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Robert Haas writes:
> Yeah, but I'm not sure I like that solution very much. I don't think
> abusing the tableoid to store a remote table OID is very nice.
I'd say it's totally unacceptable. Tableoid *has to* be something
that you can look up in the local pg_class instance, or serious
confusion
On 2018-May-17, Tom Lane wrote:
> Robert Haas writes:
> > Yeah, but I'm not sure I like that solution very much. I don't think
> > abusing the tableoid to store a remote table OID is very nice.
>
> I'd say it's totally unacceptable. Tableoid *has to* be something
> that you can look up in the
Hello
This is still listed as an open item, though the patch proposed by Peter
upthread has been committed. If I understand correctly, ilmari was
going to propose another patch. Or is the right course of action to set
the open item as resolved?
On 2018-May-02, Dagfinn Ilmari Mannsåker wrote:
On 18 May 2018 at 02:13, Tom Lane wrote:
> Maybe what you need is a redesign. This convention seems impossibly
> confusing and hence error-prone. What about using a separate bool to
> indicate which list the index refers to?
While I agree that the coding is a bit unusual, I think it's also good
Alvaro Herrera writes:
> Can we just add a new junk attr, with its own fixed system column
> number? I think that's what Robert was proposing.
Junk attr yes, "fixed system column number" no. That's not how
junk attrs work. What it'd need is a convention for the name of
these resjunk attrs (cor
Alvaro Herrera writes:
> This is still listed as an open item, though the patch proposed by Peter
> upthread has been committed. If I understand correctly, ilmari was
> going to propose another patch. Or is the right course of action to set
> the open item as resolved?
AIUI, ilmari complained a
I regularly track the number of items documented in each major release.
I use the attached script. You might be surprised to learn that PG 11
has the lowest feature count of any release back through 7.4:
7.4 280
8.0 238
8.1 187
8.2 230
8.3
On 18 May 2018 at 11:29, Bruce Momjian wrote:
> I regularly track the number of items documented in each major release.
> I use the attached script. You might be surprised to learn that PG 11
> has the lowest feature count of any release back through 7.4:
Interesting. I wonder how much of that
David Rowley writes:
> On 18 May 2018 at 11:29, Bruce Momjian wrote:
>> I regularly track the number of items documented in each major release.
>> I use the attached script. You might be surprised to learn that PG 11
>> has the lowest feature count of any release back through 7.4:
> Interesting
On 2018-05-17 19:56:43 -0400, Tom Lane wrote:
> David Rowley writes:
> > On 18 May 2018 at 11:29, Bruce Momjian wrote:
> >> I regularly track the number of items documented in each major release.
> >> I use the attached script. You might be surprised to learn that PG 11
> >> has the lowest featu
On 18/05/18 11:29, Bruce Momjian wrote:
I regularly track the number of items documented in each major release.
I use the attached script. You might be surprised to learn that PG 11
has the lowest feature count of any release back through 7.4:
7.4 280
8.0 238
8.1
On Thu, May 17, 2018 at 05:01:17PM -0700, Andres Freund wrote:
> On 2018-05-17 19:56:43 -0400, Tom Lane wrote:
> > David Rowley writes:
> > > On 18 May 2018 at 11:29, Bruce Momjian wrote:
> > >> I regularly track the number of items documented in each major release.
> > >> I use the attached scri
At Thu, 17 May 2018 09:20:01 -0700, Andres Freund wrote in
<20180517162001.rzd7l6g2h66hv...@alap3.anarazel.de>
> Hi,
>
> On 2018-05-17 17:19:00 +0900, Kyotaro HORIGUCHI wrote:
> > Hello, as in pgsql-bug ML.
> >
> > https://www.postgresql.org/message-id/20180517.170021.24356216.horiguchi.kyot...
>-Original Message-
>From: Robert Haas [mailto:robertmh...@gmail.com]
>OK, I'm happy enough to commit it then, barring other objections. I was just
>going to
>just do that but then I realized we're in feature freeze right now, so I
>suppose this
>should go into the next CommitFest.
Than
On Fri, May 4, 2018 at 03:25:15PM -0400, Robert Haas wrote:
> On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote:
> > If we are breaking 1:1 backend:session relationship, what controls
> > would we have to manage resource consumption?
>
> I mean, if you have a large number of sessions open, i
On Thu, May 17, 2018 at 02:23:00PM -0400, Bruce Momjian wrote:
> On Thu, May 17, 2018 at 10:35:53PM +0900, Michael Paquier wrote:
> > Hi Bruce,
> >
> > Here is some bonus feedback.
> >
> > On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > > I expect a torrent of feedback. ;-)
>
On 2018/05/18 6:14, David Rowley wrote:
> On 18 May 2018 at 02:13, Tom Lane wrote:
>> Maybe what you need is a redesign. This convention seems impossibly
>> confusing and hence error-prone. What about using a separate bool to
>> indicate which list the index refers to?
>
> While I agree that th
On Thu, May 17, 2018 at 10:05:25AM -0400, Bruce Momjian wrote:
> Agreed. The problem was so glaring that I assumed I was not
> understanding it. I have modified this email subject so users will
> hopefully read back in this thread to see the details.
Okay, let's use this new thread then for the
On 2018/05/18 5:56, David Rowley wrote:
> On 18 May 2018 at 06:21, Robert Haas wrote:
>> All right, so let's just say that explicitly. Maybe something like
>> the attached.
>
> That looks fine to me.
Me too, except:
+* *pds list is the root partition, so 0 always means the first leaf.
On 5/17/18 17:11, Alvaro Herrera wrote:
> This is still listed as an open item, though the patch proposed by Peter
> upthread has been committed. If I understand correctly, ilmari was
> going to propose another patch. Or is the right course of action to set
> the open item as resolved?
The items
On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
> I do have a real concern about the long term attractiveness of the
> project to new developers, especially younger ones as time passes.
> It's not a secret that people will just avoid creaky old projects, and
> for Postgres old out of
On Fri, May 18, 2018 at 10:46:46AM +0900, Michael Paquier wrote:
> On Thu, May 17, 2018 at 10:05:25AM -0400, Bruce Momjian wrote:
> > Agreed. The problem was so glaring that I assumed I was not
> > understanding it. I have modified this email subject so users will
> > hopefully read back in this
On 5/17/18 16:54, Tom Lane wrote:
> TBH, this is several months too late for v11.
Maybe, but ...
You're talking about a
> really fundamental redesign, at least if it's done right and not as a
> desperate last-minute hack (which is what this looks like). The points
> you make here are just the ti
On Fri, May 18, 2018 at 10:46:46AM +0900, Michael Paquier wrote:
> From a security point of view, 1) is important for libpq, but I am not
> much enthusiast about 2) as a whole. The backend has proper support for
> channel binding, hence other drivers speaking the protocol could have
> their own re
On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote:
>On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
>> I do have a real concern about the long term attractiveness of the
>> project to new developers, especially younger ones as time passes.
>> It's not a secret that people will j
On 18 May 2018 at 11:10, Andres Freund wrote:
>
>
> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote:
> >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
> >> I do have a real concern about the long term attractiveness of the
> >> project to new developers, especially younger on
On Thu, May 17, 2018 at 11:56 PM, Robert Haas wrote:
> On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat
> wrote:
>> The second would mean that SELECT * from foreign table reports
>> remotetableoid as well, which is awkward.
>
> No it wouldn't. You'd just make the additional column resjunk, same
>
2018-05-18 5:50 GMT+02:00 Craig Ringer :
> On 18 May 2018 at 11:10, Andres Freund wrote:
>
>>
>>
>> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote:
>> >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote:
>> >> I do have a real concern about the long term attractiveness of the
>>
At Thu, 17 May 2018 13:54:07 +0300, Arseny Sher wrote
in <87in7md034.fsf@ars-thinkpad>
>
> Konstantin Knizhnik writes:
>
> > I think that using restart_lsn instead of confirmed_flush is not right
> > approach.
> > If restart_lsn is not available and confirmed_flush is pointing to page
> > bou
Hi,
On 2018-05-18 11:50:47 +0800, Craig Ringer wrote:
> Also - mailing lists. We're an ageing community and a lot of younger people
> just don't like or use mailing lists, let alone like to work *only* on
> mailing lists without forums, issue trackers, etc etc.
Can't see getting rid of those enti
H, Bruce!
> 11 мая 2018 г., в 20:08, Bruce Momjian написал(а):
>
> I expect a torrent of feedback. ;-)
I'm not sure it is usefull in release notes since it is more about API, and not
user-facing change. Just in case.
GiST opclasses now can omit compress and decompress functions. If compress
Hello
I think it is better to add freeing operation of output SQLDA to the current
PostgreSQL documentation.
As far as I can see src/interfaces/ecpg/ecpglib/execute.c,
if a previously existing sqlda is set to output SQLDA,
then a previously existing sqlda is freed.
But, the new output SQLDA's me
2018-05-17 21:18 GMT+08:00 Michael Paquier :
> On Thu, May 17, 2018 at 05:23:28PM +0800, Paul Guo wrote:
> > F_OK seems to be better than R_OK because we want to check file existence
> > (not read permission) before creating the relation file with the path
> > later.
>
> Please do not top-post, th
92 matches
Mail list logo
