On 2018-Nov-16, Alvaro Herrera wrote:
> On 2017-Nov-04, Fabien COELHO wrote:
>
> > Think of one initialization followed by two appends:
> >
> > SELECT 1 AS x \cset
> > SELECT 2 \; SELECT 3 AS y \cset
> > SELECT 4 \; SELECT 5 \; SELECT 6 AS z \gset
> >
> > In the end, we must have the full
I think this patch's Command->lines would benefit from using PQExpBuffer
(or maybe StringInfo?) for the command string instead of open-coding
string manipulation and allocation.
I'm not sure that Command->first_line is really all that useful. It
seems we go to a lot of trouble to keep it up to da
Hello Alvaro,
Thanks for having a look at this patch.
Think of one initialization followed by two appends:
SELECT 1 AS x \cset
SELECT 2 \; SELECT 3 AS y \cset
SELECT 4 \; SELECT 5 \; SELECT 6 AS z \gset
In the end, we must have the full 6 queries
"SELECT 1 AS x \; SELECT 2 \; SELECT
I think this patch's Command->lines would benefit from using PQExpBuffer
(or maybe StringInfo?) for the command string instead of open-coding
string manipulation and allocation.
Indeed it could be used, but it is not used anywhere in "pgbench": not for
lines, not for variable subtitutions, n
Attached is a v3, where I have updated inaccurate comments.
Attached v4 is a rebase after 409231919443984635b7ae9b7e2e261ab984eb1e
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 73d3de0677..ed6ff75426 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgb
On 2018-Nov-17, Fabien COELHO wrote:
>
> > I think this patch's Command->lines would benefit from using PQExpBuffer
> > (or maybe StringInfo?) for the command string instead of open-coding
> > string manipulation and allocation.
>
> Indeed it could be used, but it is not used anywhere in "pgbenc
On 2018-Nov-17, Haribabu Kommi wrote:
> > Okay, but you haven't answered my question:
> > "how is able to remove the correct statement from hash (it seems
> > statement intended to remove 'SELECT $1 AS "ONE"', but it removed
> > 'SELECT $1 + $2 AS "TWO"')"?
>
> I missed to check that question.
>
On Fri, Nov 16, 2018 at 9:46 AM Dilip Kumar wrote:
>
> On Thu, Nov 15, 2018 at 12:14 PM Dilip Kumar wrote:
> >
> Updated patch (merged latest code from the zheap main branch [1]).
>
Review comments:
---
1.
UndoRecordPrepareTransInfo()
{
..
+ /*
+ * The absence of prev
Adam Brusselback schrieb am Sa., 17. Nov. 2018
um 06:51 Uhr:
> > I don't know how much what I write on this thread is read by others or
> how useful this is for others who are following this work
>
> I've been following this thread and many others like it, silently soaking
> it up, because I don
Looks good to me, save that I would change the API of getHostaddr() to
this:
/* --
* getHostaddr -
* Fills 'host_addr' with the string representation of the currently connected
* socket in 'conn'.
* --
*/
static void
getHostaddr(PGconn *conn, char *host_addr, int host_addr_len
On 2018-Nov-17, Alvaro Herrera wrote:
> Looks good to me, save that I would change the API of getHostaddr() to
> this:
>
> /* --
> * getHostaddr -
> * Fills 'host_addr' with the string representation of the currently connected
> * socket in 'conn'.
> * --
> */
> static void
>
On Sat, Nov 17, 2018 at 4:46 PM Alvaro Herrera wrote:
>
> On 2018-Nov-17, Haribabu Kommi wrote:
>
> > > Okay, but you haven't answered my question:
> > > "how is able to remove the correct statement from hash (it seems
> > > statement intended to remove 'SELECT $1 AS "ONE"', but it removed
> > > '
On 2018-Nov-17, Amit Kapila wrote:
> On Sat, Nov 17, 2018 at 4:46 PM Alvaro Herrera
> wrote:
> > Uh, ouch! Seems to me that this is a high-caliber foot-gun, and will
> > cause nasty suprises when production stats data disappear inadvertently!
>
> What is the alternative in your mind?
Well, a
Is this patch committable now?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, 17 Nov 2018, Alvaro Herrera wrote:
/* --
* getHostaddr -
* Fills 'host_addr' with the string representation of the currently connected
* socket in 'conn'.
* --
*/
static void
getHostaddr(PGconn *conn, char *host_addr, int host_addr_len)
Fabien, are you planning
Fabien, are you planning to fix things per Arthur's review?
Yep, I am.
I will not do the above though, because the PQgetHostaddr API would differ
from all other connection status functions (PQgetHost, PQgetUser...) which
are all "char * PQget(PGconn * conn)"
Sorry, I'm mixing everything,
Hi %,
is this something the configure script needs to take care of?
checking for CFLAGS recommended by Perl... -D_REENTRANT -D_GNU_SOURCE -O2 -g
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -sp
The comment in expand_dbname_patterns is ungrammatical and mentions
"OID" rather than "name", so I suggest
/*
* The loop below might sometimes result in duplicate entries in the
* output name list, but we don't care.
*/
I'm not sure this is grammatical either:
On 2018-Nov-17, Fabien COELHO wrote:
>
> > > Fabien, are you planning to fix things per Arthur's review?
> >
> > Yep, I am.
> >
> > I will not do the above though, because the PQgetHostaddr API would
> > differ from all other connection status functions (PQgetHost,
> > PQgetUser...) which are a
Hello Pavel,
I think so some redundant messages can be reduced - see function
printConnInfo - attached patch
I thought about doing like that, but I made the debatable choice to keep
the existing redundancy because it minimizes diffs and having a
print-to-stdout special function does not lo
Daniel Westermann writes:
> is this something the configure script needs to take care of?
No. If your python is not named "python", you need to do something
like
configure --with-python PYTHON=python3.6
regards, tom lane
Here are versions for branches 10 and 11. The main change is that the
COPY test didn't have the partitioned table, because it was recently
introduced (0d5f05cde011) so I backpatched that part also. It's a bit
useless, but I'd rather backpatch the same thing rather than have
different lines there
On 2018-Nov-17, Fabien COELHO wrote:
> > I think so some redundant messages can be reduced - see function
> > printConnInfo - attached patch
>
> I thought about doing like that, but I made the debatable choice to keep the
> existing redundancy because it minimizes diffs and having a print-to-stdo
FWIW I didn't like the error message:
cannot perform FREEZE on a partitioned table
but then I noticed other messages also say "cannot perform FREEZE". I
think they should all say "cannot perform COPY FREEZE" instead.
Not something for this patch to fix, though, I think.
--
Álvaro Herrera
I think so some redundant messages can be reduced - see function
printConnInfo - attached patch
I thought about doing like that, but I made the debatable choice to keep the
existing redundancy because it minimizes diffs and having a print-to-stdout
special function does not look like a very c
I'm working on improving the patch.
Cool.
Here is the updated v2
- libpq internal function getHostaddr get a length,
and I added an assert about it.
- added a few braces on if/if/else/if/else/else
- added an UNKNOWN_HOST macro to hide "???"
- moved host_addr[] declaration earlier to
On Fri, Nov 16, 2018 at 05:47:24PM -0800, Andres Freund wrote:
> That's probably just the same issue as before, namely random data
> somehow being produced as the result of tuple deforming.
Does this help at all?
ts=# SELECT utrancell FROM child.daily_eric_umts_rnc_utrancell_view_201807
LIMIT 9;
I wrote:
> After still further thought, it seems like "if (bytesread == 0)"
> is the right way to proceed. That protects us against incorrectly
> setting reached_eof if the pipe is being run in unbuffered or
> line-buffered mode. (Which copy.c doesn't do, at the moment,
> but I'd just as soon thi
Thanks, Tom
Daniel Westermann writes: > is this something the configure script needs to
take care of? No. If your python is not named "python", you need to do
something like configure --with-python PYTHON=python3.6 regards, tom lane
Thomas Munro writes:
> On Wed, Nov 7, 2018 at 11:03 PM Etsuro Fujita
> wrote:
>> (2018/11/06 19:50), Thomas Munro wrote:
>>> Why do bgwriter.c,
>>> startup.c, ... set SIGTTIN and SIGTTOU back to SIG_DFL, but not
>>> regular backends?
>> So, we should revert SIGUSR2 as well to default processing?
On 2018-Nov-17, Tom Lane wrote:
> Given the lack of complaints, there's probably no need for back-patch,
> but that's what I'd propose in HEAD to make this saner.
Hmm, but the bug was reported on pg10 ... why wouldn't we backpatch this
fix there?
--
Álvaro Herrerahttps://www.2nd
Alvaro Herrera writes:
> On 2018-Nov-17, Tom Lane wrote:
>> Given the lack of complaints, there's probably no need for back-patch,
>> but that's what I'd propose in HEAD to make this saner.
> Hmm, but the bug was reported on pg10 ... why wouldn't we backpatch this
> fix there?
The complaint was
Should now/current_date be marked leakproof?
I'm trying to push a `WHERE field >= current_date - interval '1 day'` type
of clause into a security_barrier defined view.
--
Rod Taylor
Rod Taylor writes:
> Should now/current_date be marked leakproof?
Since it has no argument, that should be moot.
regards, tom lane
Hi,
On 2018-07-12 11:28:46 -0400, Andrew Dunstan wrote:
> On 07/12/2018 10:38 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> > > On 07/12/2018 10:20 AM, Tom Lane wrote:
> > > > bowerbird and hamerkop have some gripes like this:
> > > >
> > > > bowerbird | c:\perl64\lib\core\win32.h(218): w
Melanie Plageman writes:
> On a separate note, I had one additional code clarity feedback. I felt that
> eqjoinsel could be reorganized a bit for readability/clarity for the reader.
> ...
> Based on this assumption, I've attached a patch with a rough idea for an
> alternative structure that I thin
On Sat, 17 Nov 2018 at 14:32, Tom Lane wrote:
> Rod Taylor writes:
> > Should now/current_date be marked leakproof?
>
> Since it has no argument, that should be moot.
>
Gah, you're right.
It seems to be because the below clause is timestamp without time zone:
WHERE current_date - interval '1 d
Rod Taylor writes:
> So it's the timestamp_%_timestamptz operator functions that are missing the
> flag?
I think those are not marked leakproof because they aren't leakproof;
they can throw errors for some inputs, or at least the required
conversions invoke enough code that it's hard to be sure t
> On 15 Nov 2018, at 22:42, Tom Lane wrote:
> Further point about that: pg_regress's method of creating a temp
> directory under /tmp is secure only on machines with the stickybit
> set on /tmp; otherwise it's possible for an attacker to rename the
> temp dir out of the way and inject his own soc
On 11/8/18 1:07 PM, Tomas Vondra wrote:
> On 11/6/18 6:51 PM, Tomas Vondra wrote:
>> On 11/6/18 6:35 PM, Alvaro Herrera wrote:
>>> On 2018-Nov-06, Tomas Vondra wrote:
>>>
Hi,
I've recently updated to Fedora 28, and in that environment I get
quite a
few new valgrind issues (
> On Fri, 16 Nov 2018 at 16:06, Jesper Pedersen
> wrote:
>
> On 11/15/18 6:41 AM, Alexander Kuzmenkov wrote:
> >>> But having this logic inside _bt_next means that it will make a
> >>> non-skip index
> >>> only scan a bit slower, am I right?
> >>
> >> Correct.
> >
> > Well, it depends on how the
On Fri, Nov 16, 2018 at 10:24:46AM -0600, Justin Pryzby wrote:
> On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote:
> > The table is not too special, but was probably ALTERed to add columns a good
> > number of times by one of our processes. It has ~1100 columns, including
> > arrays,
> On Mon, 16 Jul 2018 at 23:07, Tomas Vondra
> wrote:
>
> On 07/16/2018 05:24 PM, Robert Haas wrote:
> > On Sun, Jul 15, 2018 at 6:53 AM, Vik Fearing
> > wrote:
> >> Hmm. Not sure if that last word should be _sample, _sampling, _rate, or
> >> a combination of those.
> >
> > +1 for rate or sampl
On 2018-Oct-01, Michael Paquier wrote:
> On Tue, Jul 03, 2018 at 01:25:37PM +0300, s.cherkas...@postgrespro.ru wrote:
> > diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
> > index 3ed9021..b699548 100644
> > --- a/doc/src/sgml/catalogs.sgml
> > +++ b/doc/src/sgml/catalogs.sgml
On Fri, Nov 9, 2018 at 9:06 AM Robert Haas wrote:
> On Thu, Nov 8, 2018 at 3:04 PM Thomas Munro
> wrote:
> > My reasoning for choosing bms_join() is that it cannot fail, assuming
> > the heap is not corrupted. It simply ORs the two bit-strings into
> > whichever is the longer input string, and f
We've seen repeated complaints about bogus build warnings when using
"clang": it complains that strlcpy and some related library functions
haven't been declared. Several of the buildfarm animals exhibit such
warnings, for instance. That's because Autoconf's AC_CHECK_DECLS macro
fails to cope with
46 matches
Mail list logo
