On 2020-08-12 10:18, Marco Atzeri wrote:
On 12.08.2020 09:12, Peter Eisentraut wrote:
There are two ancient hacks in the cygwin and solaris ports that appear
to have been solved more than 10 years ago, so I think we can remove
them. See attached patches.
Hi Peter,
This is really archeology
On 2020-08-13 05:22, Noah Misch wrote:
On Wed, Aug 12, 2020 at 09:12:07AM +0200, Peter Eisentraut wrote:
There are two ancient hacks in the cygwin and solaris ports that appear to
have been solved more than 10 years ago, so I think we can remove them. See
attached patches.
+1 for removing the
On 2020-08-12 21:54, Robert Haas wrote:
One problem with this, which I think Tom pointed out before, is that
it might make it to handle some forward-compatibility problems. In
other words, if something that the server is generating needs to be
modified for compatibility with a future release, it'
On Thu, Aug 13, 2020 at 6:47 PM Amit Kapila wrote:
>
> On Thu, Aug 13, 2020 at 12:08 PM Amit Kapila wrote:
> >
> > On Fri, Aug 7, 2020 at 2:04 PM Dilip Kumar wrote:
> > >
> > > On Thu, Aug 6, 2020 at 2:43 PM Amit Kapila
> > > wrote:
> > > >
> > ..
> > > > This patch's functionality can be inde
On 2020-08-13 00:34, Andres Freund wrote:
I e.g. just re-indented patch 0001 of my GetSnapshotData() series and
most of the hunks were entirely unrelated. Despite the development
window for 14 having only relatively recently opened. Based on my
experience it tends to get worse over time.
Do we
Peter Eisentraut writes:
> On 2020-08-12 21:54, Robert Haas wrote:
>> One problem with this, which I think Tom pointed out before, is that
>> it might make it to handle some forward-compatibility problems. In
>> other words, if something that the server is generating needs to be
>> modified for co
I wrote:
> I wouldn't say that it's *fundamentally* new, but nonethless it disturbs
> me that this proposal has pg_dump assembling CREATE FUNCTION commands in
> very different ways depending on the server version. I'd rather see us
> continuing to build the bulk of the command the same as before,
hyrax's latest report suggests that this patch has issues under
CLOBBER_CACHE_ALWAYS:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax&dt=2020-08-13%2005%3A09%3A58
Hard to tell whether there's an actual bug there or just test instability,
but either way it needs to be resolved.
We have two essentially identical buildfarm failures since these patches
went in:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2020-08-15%2011%3A27%3A32
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus&dt=2020-08-15%2003%3A09%3A14
They're both in the same
Dmitry Dolgov wrote
>> On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
>>
>> Then I think about implementing ideas of LSM using standard Postgres
>> nbtree.
>>
>> We need two indexes: one small for fast inserts and another - big
>> (main) index. This top index is small enough t
Hi,
On 2020-08-15 11:10:51 -0400, Tom Lane wrote:
> We have two essentially identical buildfarm failures since these patches
> went in:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2020-08-15%2011%3A27%3A32
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=perip
Hi,
On 2020-08-15 13:47:41 +0200, Peter Eisentraut wrote:
> On 2020-08-13 00:34, Andres Freund wrote:
> > I e.g. just re-indented patch 0001 of my GetSnapshotData() series and
> > most of the hunks were entirely unrelated. Despite the development
> > window for 14 having only relatively recently o
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> At Mon, 03 Aug 2020 16:20:40 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Thanks for the opinion. I'll continue working on this.
>
> This is it, but..
Thanks!
> Looking closer I realized that certificates are verified in eac
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > I wouldn't say that it's *fundamentally* new, but nonethless it disturbs
> > me that this proposal has pg_dump assembling CREATE FUNCTION commands in
> > very different ways depending on the server version. I'd rather see us
> > con
Andres Freund writes:
> One thing is that some here are actively against manually adding entries
> to typedefs.list.
I've been of the opinion that it's pointless to do so under the current
regime where (a) only a few people do that and (b) we only officially
re-indent once a year anyway. When I
15 matches
Mail list logo