On Tue, Oct 2, 2018 at 10:07 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Tue, Oct 2, 2018 at 9:38 AM Tom Lane wrote:
> >> (But it might be worth choosing slightly less
> >> generic object names, to avoid a conflict against other sub-tests
> >> later in that script.)
>
> > The function
On Fri, Sep 28, 2018 at 9:37 PM Thomas Munro
wrote:
> The other patches in this tarball are all as posted already, but are
> now rebased and assembled in one place. Also pushed to
> https://github.com/macdice/postgres/tree/fsyncgate .
Here is a new version that fixes an assertion failure during
On Thu, Jul 12, 2018 at 03:07:33PM -0400, Robbie Harwood wrote:
> This patch looks good to me. +1; Álvaro, please update the CF entry
> when you're also satisfied.
The patch set does not apply anymore, so I have moved it to next CF,
waiting on author.
--
Michael
signature.asc
Description: PGP
On Tue, Jul 17, 2018 at 08:21:20PM +0300, Heikki Linnakangas wrote:
> Oh, is that all it does? That's disappointing, because that's a lot less
> powerful than how I understand chained transactions. And at the same time
> relieving, because that's a lot simpler to implement :-).
>
> In Gray &
On Sun, Sep 09, 2018 at 01:25:49PM +0700, John Naylor wrote:
> I'm interested in this feature, so I've signed up to help review.
> Given the above, I thought it appropriate to mark the patch Waiting on
> Author.
I find this feature interesting as well. The patch has been waiting on
author input
On Tue, Oct 02, 2018 at 01:50:46PM +0900, Etsuro Fujita wrote:
> Sorry, I forgot to add the pointer for [1]:
>
> https://www.postgresql.org/message-id/CAFjFpRfcgwsHRmpvoOK-GUQi-n8MgAS%2BOxcQo%3DaBDn1COywmcg%40mail.gmail.com
OK, thanks for your update!
--
Michael
signature.asc
Description: PGP
On Sat, Aug 11, 2018 at 05:20:57AM +0200, Mark Rofail wrote:
> I am still having problems rebasing this patch. I can not figure it out on
> my own.
Okay, it's been a couple of months since this last email, and nothing
has happened, so I am marking it as returned with feedback.
--
Michael
On Fri, Aug 17, 2018 at 01:39:11PM +0900, Michael Paquier wrote:
> The point about the header matching mentioned upthread is quite
> interesting as it could make the proposed feature way more useful, and
> it has not really been discussed. As far as I can see this adds more
> sanity checks in
On Thu, Mar 01, 2018 at 06:16:17PM -0500, David Steele wrote:
> That was the right thing to do, thank you!
This patch has been waiting on author for a couple of months and does
not apply anymore, so I am marking as returned with feedback. If you
can rebase, please feel free to resubmit.
--
On Sat, Mar 03, 2018 at 03:52:40PM +0100, Tomas Vondra wrote:
> Yeah, that's due to fd1a421fe66 which changed columns in pg_proc.h.
> Attached is a rebased patch, fixing this.
The latest patch set does not apply anymore, and had no activity for the
last two months, so I am marking it as returned
(2018/10/01 21:54), Etsuro Fujita wrote:
(2018/10/01 19:42), Michael Paquier wrote:
On Mon, Jul 23, 2018 at 02:17:38PM +0530, Ashutosh Bapat wrote:
I used perform instead of execute since the later is usually
associated with local operation. I added "foreign" in the name of the
function to
On Tue, Aug 14, 2018 at 10:00:49AM +0900, Masahiko Sawada wrote:
> I might be missing something but I think the setting either 0 or
> negative values to it solves this problem. Since the upto_nchanges is
> int32 we cannot build if somebody reverted
> 0ab9d1c4b31622e9176472b4276f3e9831e3d6ba.
I
On Fri, Sep 14, 2018 at 09:30:25PM +0300, Nikolay Shaplov wrote:
> BTW this commit shows why do this patch is important: 857f9c36 adds new
> option
> for b-tree indexes. But thanks to the StdRdOptions this option will exist for
> no practical use in all heaps that has just any option set to
On Mon, Jul 16, 2018 at 03:35:57PM +0800, Haozhou Wang wrote:
> +1, I also think that we may not change the previous behavior of plpython.
> @Nikita Glukhov maybe we just check the
> whether pyobject is int or long only in related conversion functions, and
> fallback otherwise?
This patch was
Amit Kapila writes:
> On Tue, Oct 2, 2018 at 9:38 AM Tom Lane wrote:
>> (But it might be worth choosing slightly less
>> generic object names, to avoid a conflict against other sub-tests
>> later in that script.)
> The function name and statement name seems okay to me. How about
> changing the
On Mon, Jul 16, 2018 at 02:11:57PM +0300, Michail Nikolaev wrote:
> Thanks a lot for your feedback. I'll try to update patch in few days
> (currently stuck at small performance regression in unknown place).
Okay, it has been more than a couple of days and the patch has not been
updated, so I am
On Wed, Sep 12, 2018 at 11:43:09AM +0300, Konstantin Knizhnik wrote:
> Looks like this qual is considered for choosing optimal path before it is
> removed from list of quals in set_append_rel_size.
Hm... The latest reviews have not been addressed yet, so I have marked
this as returned with
On Tue, Oct 2, 2018 at 9:38 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Tue, Oct 2, 2018 at 9:22 AM Tom Lane wrote:
> >> (I think we could drop the savepoint
> >> too, no?)
>
> > One advantage of keeping the savepoint is that we don't need to
> > explicitly drop the objects which we have
On Tue, Oct 2, 2018 at 9:11 AM Michael Paquier wrote:
>
> On Fri, Sep 28, 2018 at 01:53:14PM +0900, Masahiko Sawada wrote:
> > I agree. Can we fix this simply by the attached patch?
>
> Thanks for sending a patch.
>
> +/* autovacuum cannot be anti-wraparound and not aggressive vacuum */
> +
Amit Kapila writes:
> On Tue, Oct 2, 2018 at 9:22 AM Tom Lane wrote:
>> (I think we could drop the savepoint
>> too, no?)
> One advantage of keeping the savepoint is that we don't need to
> explicitly drop the objects which we have created temporarily for this
> test.
They'll go away anyway at
On Tue, Oct 2, 2018 at 9:22 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Tue, Oct 2, 2018 at 7:08 AM Tom Lane wrote:
> >> Also, I believe
> >> that coding the test this way makes the leader send the param values to
> >> multiple workers, which would flush out any problems with serializing
On Thu, Sep 20, 2018 at 9:50 AM Kevin Grittner wrote:
> On Tue, Jul 10, 2018 at 8:58 PM Masahiko Sawada wrote:
> > I looked at this patches. The latest patch can build without any
> > errors and warnings and pass all regression tests. I don't see
> > critical bugs but there are random comments.
Amit Kapila writes:
> On Tue, Oct 2, 2018 at 7:08 AM Tom Lane wrote:
>> Also, I believe
>> that coding the test this way makes the leader send the param values to
>> multiple workers, which would flush out any problems with serializing a
>> value multiple times. As against that, there's a
On Tue, Oct 2, 2018 at 7:08 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > I think if we do Analyze on the table after populating rows, it should
> > use just one worker and that should be sufficient to hit the case
> > being discussed. I would like to change the test so that it uses just
> >
On Fri, Jul 13, 2018 at 04:20:15PM -0400, Dave Cramer wrote:
> However it would be far better to have a startup parameter which indicated
> that we wanted to connect to a read only database. At that point
> pools could redirect to a secondary. Given the proliferation of cloud based
>
On Fri, Jul 27, 2018 at 02:19:27PM +0530, Ashutosh Bapat wrote:
> [ removal of latest arguments ]
> +1, if we could do that.
The patch seems to have stuck a bit, so I am marking it as returned with
feedback because of no activity.
--
Michael
signature.asc
Description: PGP signature
Hi John,
On Mon, Jul 02, 2018 at 01:59:03PM +0700, John Naylor wrote:
> I've attached v4, which is a rebase plus some comment revisions.
v4 does not apply anymore. I am moving this patch to next commit fest,
waiting on author.
--
Michael
signature.asc
Description: PGP signature
On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
> The libpmem's pmem_map_file() supported 2M/1G(the size of huge page)
> alignment, since it could reduce the number of page faults.
> In addition, libpmem's pmem_memcpy_nodrain() is the function
> to copy data using single
Hi Tomas,
On Mon, Jun 25, 2018 at 02:14:20AM +0200, Tomas Vondra wrote:
> OK, here is a version tweaked to use floor()/ceil() instead of round().
> Let's see if the Windows machine likes that more.
The latest patch set does not apply cleanly. Could you rebase it? I
have moved the patch to CF
On Thu, Jun 28, 2018 at 04:20:53PM +0900, Masahiko Sawada wrote:
> If there is an up-to-date information meaning either that there is no
> tables needing vacuum or that there is only table needing vacuum but
> being vacuumed by other worker, AV launcher can launches new one to
> other database.
I
On Sat, Sep 08, 2018 at 02:21:27AM +0300, Nikita Glukhov wrote:
> Attached 18th version of the patches rebased onto the current master.
Nikita, this version fails to apply, as 0004 has conflicts with some
regression tests. Could you rebase? I am moving the patch to CF
2018-11, waiting for your
On Mon, Jul 02, 2018 at 05:49:06PM -0400, Andrew Dunstan wrote:
> There doesn't seem to have been any progress since this email.
Indeed, none. I am marking it as returned with feedback... The patch
has rotten quite some time ago as well.
--
Michael
signature.asc
Description: PGP signature
Hi Marina,
On Thu, May 24, 2018 at 04:00:33PM +0300, Marina Polyakova wrote:
> Here there's a 9-th version of the patches for the precalculation of stable
> or immutable functions, stable or immutable operators and other nonvolatile
> expressions. This is a try to execute cached expressions as
Kyotaro HORIGUCHI writes:
> At Tue, 25 Sep 2018 16:45:09 -0700, Andres Freund wrote
> in <20180925234509.3hrrf6tmvy5tf...@alap3.anarazel.de>
>> On 2018-09-04 18:35:34 +0530, Amit Khandekar wrote:
>>> Pack the boolean members in TupleTableSlot into a 16 bit tts_flags.
>>> This reduces the size
On 19 July 2018 at 06:27, Robert Haas wrote:
> On Mon, Jul 9, 2018 at 5:08 AM, David Rowley
>> "LazyMaterialize" seems like a good option for a name. It seems better
>> than "LazyHash" since you may not want to restrict it to a hash table
>> based cache in the future. A binary search tree may be
On Sat, Jun 30, 2018 at 09:19:13AM +1200, Gavin Flower wrote:
> Additionally put an upper limit threshold on the number of combinations to
> check, fairly large by default?
>
> If first threshold is exceeded, could consider checking out a few more
> selected at random from paths not yet checked,
On Mon, Jul 09, 2018 at 09:08:07PM +1200, David Rowley wrote:
> I'll mark as waiting on author in the meantime.
>
> It's great to see someone working on this.
Not that actively unfortunately. The patch status has remained
unchanged since, so I am marking it as returned with feedback.
--
Michael
On Fri, Aug 03, 2018 at 04:50:11PM +0200, Antonin Houska wrote:
> Antonin Houska wrote:
>
> > I didn't have enough time to separate "your functionality" and can do it
> > when
> > I'm back from vacation.
>
> So I've separated the code that does not use the 2-stage replication (and
> therefore
On Sun, Jul 22, 2018 at 10:22:10PM +0200, Tomas Vondra wrote:
> Could you perhaps summarize the reasoning or at least point me to the
> relevant parts of the sources, so that I know which parts to focus on?
Teodor, this patch is waiting for some input from you. I have moved it
to next CF for
On Mon, Jul 02, 2018 at 09:37:31AM +1200, David Rowley wrote:
> Now that the September 'fest is open for new patches I'm going to move
> this patch over there. This patch has become slightly less important
> than some other stuff, but I'd still like to come back to it.
Please note that the
On Fri, Aug 03, 2018 at 11:08:57PM +0200, Fabien COELHO wrote:
> Patch applies cleanly, compiles, and works for me.
Last review has not been addressed, so please note that this has been
marked as returned with feedback.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 16, 2018 at 02:33:17PM -0400, Andrew Dunstan wrote:
> Ah, ok. Thanks. ignore the email I just sent about that.
So... This thread has basically died of inactivity, while there have
been a couple of interesting things discussed, like the version from
Heikki here:
At Tue, 25 Sep 2018 16:45:09 -0700, Andres Freund wrote in
<20180925234509.3hrrf6tmvy5tf...@alap3.anarazel.de>
> Hi,
>
> On 2018-09-04 18:35:34 +0530, Amit Khandekar wrote:
> > Subject: [PATCH 05/14] Use tts_flags instead of previous bool members
> >
> > Pack the boolean members in
Amit Kapila writes:
> I think if we do Analyze on the table after populating rows, it should
> use just one worker and that should be sufficient to hit the case
> being discussed. I would like to change the test so that it uses just
> one worker.
I thought that adding an ANALYZE would make the
On Mon, Aug 06, 2018 at 05:23:28PM -0400, Robbie Harwood wrote:
> If you're in a position where you're using Kerberos (or most other
> things from the GSSAPI) for authentication, the encryption comes at
> little to no additional setup cost. And then you get all the security
> benefits outlined in
Michael Paquier writes:
> On Mon, Sep 03, 2018 at 06:59:10PM -0700, Noah Misch wrote:
>> If you're going to keep this highly-simplified estimate, please expand the
>> comment to say why it doesn't matter or what makes it hard to do better. The
>> non-planunionor.c path for the same query
On Fri, Apr 06, 2018 at 03:03:30PM +0200, Julian Markwort wrote:
> As I see it, planning duration, first date, and last update date would
> be columns added to the pg_stat_statements view, i.e. they are tracked
> for each kind of a (jumbled) query -- just as the good and bad plans,
> their
On Tue, Oct 2, 2018 at 5:31 AM Tom Lane wrote:
>
> Thomas Munro writes:
> > On Tue, Oct 2, 2018 at 9:49 AM Tom Lane wrote:
> >> Apparently the only somewhat-modern architecture that is resolutely
> >> unaligned-unfriendly is MIPS.
>
> > It's been a few years now since I worked on that
On 2018/10/02 10:20, Michael Paquier wrote:
> On Sat, Sep 29, 2018 at 07:00:02PM +0530, Dilip Kumar wrote:
>> I think we can delay allocating memory for rel->part_rels? And we can
>> allocate in add_rel_partitions_to_query only
>> for those partitions which survive pruning.
>
> This last review
On Sat, Sep 29, 2018 at 07:00:02PM +0530, Dilip Kumar wrote:
> I think we can delay allocating memory for rel->part_rels? And we can
> allocate in add_rel_partitions_to_query only
> for those partitions which survive pruning.
This last review set has not been answered, and as it is recent I am
On Thu, Sep 13, 2018 at 02:56:42PM -0600, Jerry Jelinek wrote:
> I'll take a look at that. I had been trying to keep the patch as minimal as
> possible, but I'm happy to work through this.
(Please be careful with top-posting)
Jerry, the last status was from three weeks ago with the patch waiting
On Mon, Aug 06, 2018 at 11:12:00PM +0500, Andrey Borodin wrote:
> Done. Added function bms_make_empty(int size)
Andrey, your latest patch does not apply. I am moving this to the next
CF, waiting for your input.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 03, 2018 at 06:59:10PM -0700, Noah Misch wrote:
> If you're going to keep this highly-simplified estimate, please expand the
> comment to say why it doesn't matter or what makes it hard to do better. The
> non-planunionor.c path for the same query computes its own estimate of the
>
Andres Freund writes:
> On 2018-10-01 20:19:16 -0400, Tom Lane wrote:
>> That patch takes the memset out of the main line, but it'd still be
>> a performance problem for formats using argument reordering; and the
>> stack-space concern would remain the same.
> What I mean is that it shouldn't be
Hi,
On 2018-10-01 17:46:55 -0700, Andres Freund wrote:
> On 2018-10-01 20:19:16 -0400, Tom Lane wrote:
> > argtypes is only a small part of the stack-space issue, there's also
> > argvalues which is (at least) twice as big. I don't think second-guessing
> > the compiler about the most efficient
Hi,
On 2018-10-01 20:19:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-10-01 19:52:40 -0400, Tom Lane wrote:
> >> Ouch indeed. Quite aside from cycles wasted, that's way more stack than
> >> we want this to consume. I'm good with forcing this to 16 or so ...
> >> any objections?
Thomas Munro writes:
> PrintfArgType is an enum, and we define NL_ARGMAX as 16 if the OS
> didn't already define it. On FreeBSD 11, NL_ARGMAX was defined as 99
> in . On FreeBSD 12, it is defined as 65536... ouch. On a
> Debian box I see it is 4096.
Some further research:
* My Red Hat boxes
On Mon, Oct 01, 2018 at 02:37:42PM +0200, Daniel Gustafsson wrote:
>> On 1 Oct 2018, at 01:19, Michael Paquier wrote:
>> Looking at the refactoring patch 0001, wouldn't signalfuncs.c make a
>> better name for the new file? There are already multiple examples of
>> this type, like logicalfuncs.c,
Andres Freund writes:
> On 2018-10-01 19:52:40 -0400, Tom Lane wrote:
>> Ouch indeed. Quite aside from cycles wasted, that's way more stack than
>> we want this to consume. I'm good with forcing this to 16 or so ...
>> any objections?
> Especially after your performance patch, shouldn't we
On Fri, Sep 28, 2018 at 01:53:14PM +0900, Masahiko Sawada wrote:
> I agree. Can we fix this simply by the attached patch?
Thanks for sending a patch.
+/* autovacuum cannot be anti-wraparound and not aggressive vacuum */
+Assert(aggressive);
+msgfmt = _("automatic aggressive vacuum to
On Mon, Oct 01, 2018 at 03:37:01PM +, Bossart, Nathan wrote:
> Good idea. This patch looks good to me.
Thanks, I have pushed this one now.
> Without the find_all_inheritors() stuff, I think we would just need to
> modify the ANALYZE documentation patch to say something like
>
>
Thomas Munro writes:
> On Tue, Oct 2, 2018 at 9:49 AM Tom Lane wrote:
>> Apparently the only somewhat-modern architecture that is resolutely
>> unaligned-unfriendly is MIPS.
> It's been a few years now since I worked on that architecture, but
> Sparc is somewhat-modern and resolutely
Hi,
On 2018-10-01 19:52:40 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Mateusz Guzik was benchmarking PostgreSQL on FreeBSD investigating the
> > kqueue thread and complained off-list about a lot of calls to memset()
> > of size 256KB from dopr() in our snprintf.c code.
>
> > Yeah, that
Thomas Munro writes:
> Mateusz Guzik was benchmarking PostgreSQL on FreeBSD investigating the
> kqueue thread and complained off-list about a lot of calls to memset()
> of size 256KB from dopr() in our snprintf.c code.
> Yeah, that says:
> PrintfArgType argtypes[NL_ARGMAX + 2];
> ...
>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Having said that, I'm fine with having it return NULL if the given
>> attname matches an attisdropped column.
> Ok, that's really all I was asking about.
Ah, we were just talking past each other then :-(. That behavior existed
Hello hackers,
Mateusz Guzik was benchmarking PostgreSQL on FreeBSD investigating the
kqueue thread and complained off-list about a lot of calls to memset()
of size 256KB from dopr() in our snprintf.c code.
Yeah, that says:
PrintfArgType argtypes[NL_ARGMAX + 2];
...
MemSet(argtypes, 0,
On Tue, Oct 2, 2018 at 9:49 AM Tom Lane wrote:
> Apparently the only somewhat-modern architecture that is resolutely
> unaligned-unfriendly is MIPS.
It's been a few years now since I worked on that architecture, but
Sparc is somewhat-modern and resolutely unaligned-unfriendly. It's
just that
Wow, Tom. This is great stuff. Thanks for it.
Lou Picciano
> On Sep 9, 2018, at 11:27 PM, Tom Lane wrote:
>
> I wondered why buildfarm member chipmunk has been failing hard
> for the last little while. Fortunately, it's supplying us with
> a handy backtrace:
>
> Program terminated with
On Tue, Oct 2, 2018 at 10:55 AM Andrew Dunstan
wrote:
> On 10/01/2018 12:50 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
> >>> Yeah. So our choices are
> >>>
> >>> (1) Retain the current restriction on what sort comparators can
> >>> produce.
On 2018-Oct-01, Peter Eisentraut wrote:
> The following appears to work:
>
> CREATE FUNCTION evt_automatic_restart_point() RETURNS event_trigger
> LANGUAGE plpgsql
> AS $$
> BEGIN
> PERFORM pg_create_restore_point(tg_tag);
> END
> $$;
>
> CREATE EVENT TRIGGER automatic_restart_point ON
On 10/01/2018 12:50 PM, Tom Lane wrote:
Andres Freund writes:
On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
Yeah. So our choices are
(1) Retain the current restriction on what sort comparators can
produce. Find all the places where memcmp's result is returned
directly, and fix them. (I
> On 1 Oct 2018, at 22:21, Peter Eisentraut
> wrote:
>
> There have been some requests to be able to select the TLS versions
> PostgreSQL is using. We currently only hardcode that SSLv2 and SSLv3
> are disabled, but there is also some interest now in disabling TLSv1.0
> and TLSv1.1. Also,
David Rowley writes:
> On 1 October 2018 at 19:39, Amit Langote
> wrote:
>> For this and the other cases (AcquireRewriteLocks, AcquireExecutorLocks,
>> etc.), I wonder whether we couldn't just *not* recalculate the lock mode
>> based on inspecting the query tree to cross-check with rellockmode?
On Mon, Oct 01, 2018 at 05:11:02PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 10/01/2018 11:58 AM, Tom Lane wrote:
> >> Oooh ... apparently, on that platform, memcmp() is willing to produce
> >> INT_MIN in some cases. That's not a safe value for a sort comparator
> >> to produce ---
Andrew Dunstan writes:
> On 10/01/2018 11:58 AM, Tom Lane wrote:
>> Oooh ... apparently, on that platform, memcmp() is willing to produce
>> INT_MIN in some cases. That's not a safe value for a sort comparator
>> to produce --- we explicitly say that somewhere, IIRC. I think we
>> implement
On 10/01/2018 11:58 AM, Tom Lane wrote:
Mark Wong writes:
a | a |
uuid_cmp
--+--+-
---- |
I wrote:
> The attached revised patch contains a test case that demonstrably triggers
> the problem on gaur's host. Oddly, I do not get a crash either on a PPC
> Mac or a Raspberry Pi 3 running Raspbian. I'm not very sure why; I traced
> through things with gdb and it's definitely calling
On 10/01/2018 11:45 AM, Justin Pryzby wrote:
On Thu, Sep 27, 2018 at 06:32:59PM +0300, Alexander Kuzmenkov wrote:
It just has to checkout the remote branch as-is.
It doesn't clean files, but I would suggest:
git checkout -B branch remote/branch
You can see what was done in yesterday's
Stephen Frost writes:
> My complaint is specifically trying to do something like:
> =*# select *
> from
> pg_class
> join pg_attribute on (pg_class.oid = pg_attribute.attrelid)
> join pg_namespace on (pg_class.relnamespace =
Amit Kapila writes:
> On Sun, Sep 30, 2018 at 10:44 AM Amit Kapila wrote:
>> Attached is a patch along these lines, let me know if you have
>> something else in mind? I have manually verified this with
>> force_parallel_mode=regress configuration in my development
>> environment. I don't have
There have been some requests to be able to select the TLS versions
PostgreSQL is using. We currently only hardcode that SSLv2 and SSLv3
are disabled, but there is also some interest now in disabling TLSv1.0
and TLSv1.1. Also, I've had some issues in some combinations with the
new TLSv1.3, so
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> You can't have it both ways. Either you throw an error if the name's
> >> not there, or you don't.
>
> > I'm not following why we couldn't handle a dropped column
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> You can't have it both ways. Either you throw an error if the name's
>> not there, or you don't.
> I'm not following why we couldn't handle a dropped column differently.
Different from what? A name-based lookup isn't going to
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> The general plan in the has_foo_privilege functions is to throw errors for
> >> failing name-based lookups, but return null for failing numerically-based
> >> lookups (object
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The general plan in the has_foo_privilege functions is to throw errors for
>> failing name-based lookups, but return null for failing numerically-based
>> lookups (object OID or column number). I'm inclined to think we should
>>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> But it's not quite clear to me what we want the behavior for bad column
> >> name to be. A case could be made for either of:
> >>
> >> * If either the table OID is bad, or
On 1 October 2018 at 19:39, Amit Langote wrote:
> For this and the other cases (AcquireRewriteLocks, AcquireExecutorLocks,
> etc.), I wonder whether we couldn't just *not* recalculate the lock mode
> based on inspecting the query tree to cross-check with rellockmode? Why
> not just use
On 10/01/2018 02:41 PM, Stephen Frost wrote:
> Tom Lane (t...@sss.pgh.pa.us) wrote:
>> But it's not quite clear to me what we want the behavior for bad column
>> name to be. A case could be made for either of:
>>
>> * If either the table OID is bad, or the OID is OK but there's no such
>>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> But it's not quite clear to me what we want the behavior for bad column
>> name to be. A case could be made for either of:
>>
>> * If either the table OID is bad, or the OID is OK but there's no such
>> column, return null.
>>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Jaime Casanova writes:
> >> sqlsmith made it again, attached is the query (run against regression
> >> database) that makes the assert fail and the backtrace.
> >> this happens in head only (or at least 11 is fine).
>
> > Ah.
I wrote:
> Jaime Casanova writes:
>> sqlsmith made it again, attached is the query (run against regression
>> database) that makes the assert fail and the backtrace.
>> this happens in head only (or at least 11 is fine).
> Ah. Looks like the has_column_privilege stuff is incautious about
On 2018-10-01 19:25:45 +0200, Matteo Beccati wrote:
> On 01/10/2018 01:09, Thomas Munro wrote:
> > I don't know why the existence of the kqueue should make recvfrom()
> > slower on the pgbench side. That's probably something to look into
> > off-line with some FreeBSD guru help. Degraded
Andres Freund writes:
> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
>> Yeah. So our choices are
>>
>> (1) Retain the current restriction on what sort comparators can
>> produce. Find all the places where memcmp's result is returned
>> directly, and fix them. (I wonder if strcmp has same
On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
> >> Oooh ... apparently, on that platform, memcmp() is willing to produce
> >> INT_MIN in some cases. That's not a safe value for a sort comparator
> >> to produce --- we
Andres Freund writes:
> On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
>> Oooh ... apparently, on that platform, memcmp() is willing to produce
>> INT_MIN in some cases. That's not a safe value for a sort comparator
>> to produce --- we explicitly say that somewhere, IIRC.
> Hm, that'd be pretty
On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
> Mark Wong writes:
> > a | a
> > | uuid_cmp
> > --+--+-
> >
Moving this to documentation due to a general consensus that abstracting this
is not necessarily worth it.
If we don't want to refactor and abstract this, it is worth documenting the
design as to how things work now so that others who face bugs can consult docs
instead of trying to determine
Mark Wong writes:
> a | a
> | uuid_cmp
> --+--+-
> ---- | ----
> |
On Sun, Sep 30, 2018 at 12:38:46AM +0100, Andrew Gierth wrote:
> > "Andrew" == Andrew Dunstan writes:
>
> >> What is the size of a C "int" on this platform?
>
> Andrew> 4.
>
> Hmm.
>
> Because int being more than 32 bits is the simplest explanation for this
> difference.
>
> How about
On Thu, Sep 27, 2018 at 06:32:59PM +0300, Alexander Kuzmenkov wrote:
> It just has to checkout the remote branch as-is.
It doesn't clean files, but I would suggest:
git checkout -B branch remote/branch
Justin
1 - 100 of 145 matches
Mail list logo
