Resending to -hackers as I realized this isn't a documentation issue so not
appropriate or apparently interesting to readers of -doc.
Inspired by David's patch [0], find attached fixing words duplicated, across
line boundaries.
I should probably just call the algorithm proprietary, but if you
>I have committed just the libpq change. The documentation change was
>redundant, because the documentation already stated that all libpq options are
>accepted. (Arguably, the documentation was wrong before.) Also, the proposed
>test change didn't >seem to add much. It just checked that the
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Comments?
> +1 to backpatching it all, including the initialization in SPI_connect.
Done.
regards, tom lane
Bruce Momjian writes:
> On Fri, Sep 7, 2018 at 06:43:52PM -0400, Tom Lane wrote:
>> AFAICS there are no internal-to-the-C-code search path dependencies
>> in earthdistance.c, so it's not the same problem.
> Uh, there is an SQL function that calls functions from the module that
> fail. It would
On Fri, Sep 7, 2018 at 06:43:52PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > If we are going down this route, is there any thought of handling
> > earchdistance the same way?
> > https://www.postgresql.org/message-id/20180330205229.gs8...@momjian.us
>
> AFAICS there are no
On Thu, Sep 06, 2018 at 05:18:10PM +0100, Andrew Gierth wrote:
> Yeah; I checked the other constructs I used for what version they were
> added in, but that one slipped through. Fix coming shortly.
For the sake of the archives, Andrew has pushed 7b6b167 to address the
issue, which looks fine at
Bruce Momjian writes:
> If we are going down this route, is there any thought of handling
> earchdistance the same way?
> https://www.postgresql.org/message-id/20180330205229.gs8...@momjian.us
AFAICS there are no internal-to-the-C-code search path dependencies
in earthdistance.c, so it's
Commit 37c54863c removed the code in StandbyAcquireAccessExclusiveLock
that checked the return value of LockAcquireExtended. AFAICS this was
flat out wrong, because it's still passing reportMemoryError = false
to LockAcquireExtended, meaning there are still cases where
LOCKACQUIRE_NOT_AVAIL will
On Wed, Sep 5, 2018 at 06:37:00PM -0400, Tom Lane wrote:
> [ redirecting to pgsql-hackers ]
>
> I wrote:
> > Gunnlaugur Thor Briem writes:
> >> SET search_path = "$user"; SELECT public.unaccent('foo');
> >> SET
> >> ERROR: text search dictionary "unaccent" does not exist
>
> > Meh. I think
I went ahead and pushed this, since the window for getting buildfarm
testing done before Monday's wrap is closing fast. We can always
improve on it later, but I think beta3 ought to carry some fix
for the problem.
regards, tom lane
On Thu, Sep 6, 2018 at 5:36 PM Thomas Munro
wrote:
> On Thu, Sep 6, 2018 at 12:01 PM Peter Eisentraut
> wrote:
> > Also, note that this mechanism only applies to collation objects, not to
> > database-global locales. So most users wouldn't be helped by this approach.
>
> Yeah, right, that would
Hello Michael,
Hmmm. It does apply on a test I just did right know...
That's weird, it does not apply for me either with patch -p1 and there
is on conflict in fe-connect.c, which looks easy enough to fix by the
way.
Weird indeed. However, even if the patch applied cleanly for me, it was
Peter Eisentraut writes:
> On 07/09/2018 16:19, Tom Lane wrote:
>> Somehow or other, the changes you made in dfmgr.c's #include lines
>> have made it so that find_rendezvous_variable's local "bool found"
>> variable is actually of type _Bool (which is word-wide on these
>> machines).
> Ah
On Fri, Sep 07, 2018 at 05:13:17PM +0200, Fabien COELHO wrote:
> Hmmm. It does apply on a test I just did right know...
That's weird, it does not apply for me either with patch -p1 and there
is on conflict in fe-connect.c, which looks easy enough to fix by the
way.
--
Michael
signature.asc
Bruce Momjian writes:
> On Sun, Sep 2, 2018 at 01:27:25PM -0400, Tom Lane wrote:
>> If we do do a bump for beta4, I'd be strongly tempted to address the
>> lack of a unique index for pg_constraint as well, cf
>> https://www.postgresql.org/message-id/10110.1535907...@sss.pgh.pa.us
> Uh, if we
Bruce Momjian writes:
> So, are we going to output a notice if a non-100% fill factor is
> specified?
I would not think that's helpful.
regards, tom lane
On 2018-Sep-07, Bruce Momjian wrote:
> On Sun, Sep 2, 2018 at 01:27:25PM -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > This requires a catversion bump, for which it may seem a bit late;
> > > however I think it's better to release pg11 without a useless catalog
> > > column only to
On Sun, Sep 2, 2018 at 01:27:25PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > This requires a catversion bump, for which it may seem a bit late;
> > however I think it's better to release pg11 without a useless catalog
> > column only to remove it in pg12 ...
>
> Catversion bumps during
On Thu, Sep 6, 2018 at 04:16:45PM +0900, Kyotaro HORIGUCHI wrote:
> Hello.
>
> > Just my 2 cents: that was a hacky use case for development reasons.
>
> I know. So I intended to preserve the parameter with default of 100% if no
> one strongly objects to preserve. Then I abandoned that since I
I benchmarked this, using your testbed and comparing to libc sprintf
(Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all
compiled with gcc 5.4.0 with -O2. I used bigger decimals in one of the
formats, but otherwise they are the same as yours. Here is the table of
conversion
On Fri, Aug 17, 2018 at 07:56:00AM +0900, Michael Paquier wrote:
> As this is a data corruption issue, are there any objections if I patch
> and back-patch? I also would like to get this stuff in first as I have
> other refactoring work which would shave some more code.
I looked at this patch
Hi!
On Fri, Sep 7, 2018 at 3:17 PM Adrien NAYRAT wrote:
> I was faced on $SUBJECT on an heavily updated table and the same table
> heavily accessed on standby server.
>
> I notice autovacuum try to take an AEL in lazy_truncate_heap(). On
> primary we try during
Hi,
On 2018-09-07 17:57:05 +0200, Chris Travers wrote:
> Attached is the patch we are fully testing at Adjust.
For the future, please don't start a separate threads from the bugreport
/ original discussion. Makes it much harder to follow.
Greetings,
Andres Freund
On 07/09/2018 16:19, Tom Lane wrote:
> Somehow or other, the changes you made in dfmgr.c's #include lines
> have made it so that find_rendezvous_variable's local "bool found"
> variable is actually of type _Bool (which is word-wide on these
> machines). However, hash_search thinks its output
On 09/07/2018 06:05 PM, Peter Eisentraut wrote:
On 07/09/2018 11:59, Maksim Milyutin wrote:
OK. However I think it would be helpful to leave the mention about
setting necessary owner for tablespace directory. My final version of
hint is "You might need to fix permissions on this directory or
Hi;
Attached is the patch we are fully testing at Adjust. There are a few
non-obvious aspects of the code around where the patch hits.I have run
make check on Linux and MacOS, and make check-world on Linux (check-world
fails on MacOS on all versions and all branches due to ecpg failures).
Yeah, chances are that someone is going to make a change that will
require for example 8.4, and nobody would update this because the
differences between 8.2 and 8.4 are long forgotten.
It seems there is more enthusiasm on the side of not documenting it, so
I'll close this commit fest entry.
Hello Peter,
The timeout is set to 2, and the port directive is silently ignored.
However, URL parsing is stricter, eg on "port".
The attached patch checks integer syntax errors and overflows, and report
errors.
This looks useful and the patch looks reasonable, but it doesn't apply
On 07/09/2018 11:59, Maksim Milyutin wrote:
> OK. However I think it would be helpful to leave the mention about
> setting necessary owner for tablespace directory. My final version of
> hint is "You might need to fix permissions on this directory or its
> parents or install the PostgreSQL
2018-09-07 14:34 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> here is updated patch - I wrote some transactional support
>>
>> I am not sure how these new features are understandable and if these
>> features does it better or not.
>>
>
> There are possibility to reset to default value when
>>
Peter Eisentraut writes:
> On 07/09/2018 08:30, Tom Lane wrote:
>> Buildfarm member locust doesn't like this much. I've been able to
>> reproduce the problem on an old Mac laptop running the same macOS release,
>> viz 10.5.8. (Note that we're not seeing it on earlier or later releases,
>> which
On 30/08/2018 08:39, Peter Eisentraut wrote:
> On 29/08/2018 21:48, Andres Freund wrote:
>> I'd vote for not adding it. It seems almost guaranteed to get out of
>> date without anybody noticing so. Maybe that's overly pragmatic, but I
>> really can't see the harm of not documenting which precise
On 17/08/2018 12:13, Fabien COELHO wrote:
>sh> psql "connect_timeout=2,port=5433"
>
> The timeout is set to 2, and the port directive is silently ignored.
> However, URL parsing is stricter, eg on "port".
>
> The attached patch checks integer syntax errors and overflows, and report
>
On 04/09/2018 02:29, Iwata, Aya wrote:
> Since I'd like to monitor the information the server and the client exchange,
> I think monitoring protocol messages is good.
>
> When a slow query is occurs, we check this client side trace log.
> The purpose of this log acquisition I thought is to
On 05/09/2018 18:46, Peter Eisentraut wrote:
> On 01/09/2018 06:33, Shinoda, Noriyoshi (PN Japan GCS Delivery) wrote:
>> Certainly the PQconndefaults function specifies Debug flag for the "options"
>> option.
>> I think that eliminating the Debug flag is the simplest solution.
>> For attached
Hello Pavel,
here is updated patch - I wrote some transactional support
I am not sure how these new features are understandable and if these
features does it better or not.
There are possibility to reset to default value when
a) any transaction is finished - the scope of value is limited
Hello hackers,
I was faced on $SUBJECT on an heavily updated table and the same table
heavily accessed on standby server.
I notice autovacuum try to take an AEL in lazy_truncate_heap(). On
primary we try during VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL (50ms) and we
failed after several attempts.
On 01/26/2018 07:55 AM, Peter Moser wrote:
We have now a new approach to plan and execute NORMALIZE as a special
join node of type NORMALIZE, an append-plan on the inner join path,
and a merge-join executor. For the latter, we would need to
extend nodeMergejoin.c with an
Fwiw, I was doing some tests with LC_COLLATE last year:
https://github.com/ChristophBerg/lc_collate_testsuite
Iirc the outcome was that everything except de_DE.UTF-8 was stable.
Christoph
Hi,
I am getting cache lookup failed for constraint error on master and 11beta3
with below test case.
[edb@localhost bin]$ ./psql postgres
psql (11beta3)
Type "help" for help.
postgres=# CREATE TABLE non_part (a INT,PRIMARY KEY(a));
CREATE TABLE
postgres=# CREATE TABLE part (a INT REFERENCES
On 08/31/2018 04:59 PM, Tom Lane wrote:
Maksim Milyutin writes:
30.08.2018 19:52, Peter Eisentraut wrote:
I think the hint is backwards. When you don't have permission to chmod
the tablespace directory, you probably want to fix the permissions on
the tablespace directory or its parent.
In
On 07/09/2018 08:30, Tom Lane wrote:
> Peter Eisentraut writes:
>> Refactor dlopen() support
>
> Buildfarm member locust doesn't like this much. I've been able to
> reproduce the problem on an old Mac laptop running the same macOS release,
> viz 10.5.8. (Note that we're not seeing it on
On 30/08/2018 22:14, Andres Freund wrote:
> I think we should have as rules:
>
> 1) Members should be defined in the same order as in the struct, that's
>the requirement C++ standard is going to impose. Think it's also
>reasonable stylistically.
> 2) It's OK to omit setting members if
Hi,
I found that a argument "filename" is not used in execute_sql_string()
although the comment says "filename is used only to report errors.",
so I think we can remove this argument as done in the patch I attached.
Regards,
--
Yugo Nagata
diff --git a/src/backend/commands/extension.c
While reviewing some other patches to improve partitioning performance
I noticed that one of the loops in ExecFindInitialMatchingSubPlans()
could be coded a bit more efficiently. The current code loops over
all the original subplans checking if the subplan is newly pruned, if
it is, the code sets
Peter Eisentraut writes:
> Refactor dlopen() support
Buildfarm member locust doesn't like this much. I've been able to
reproduce the problem on an old Mac laptop running the same macOS release,
viz 10.5.8. (Note that we're not seeing it on earlier or later releases,
which is odd in itself.)
46 matches
Mail list logo
