It looks like commit 3bd909b22 did not place GatherPath within
print_path(), preventing complete information for Gather paths from
appearing when OPTIMIZER_DEBUG is in use.
Attached patch fixes the issue.
--
Peter Geoghegan
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimiz
> I wrote:
>> I have not attempted to reverify the files in utils/mb/Unicode against the
>> original Unicode Consortium data, but maybe we ought to do that before
>> taking any further steps here.
>
> I downloaded the mapping files from unicode.org and attempted to verify
> that the Unicode/*.map
Michael Paquier wrote:
> The result of a couple of hours of hacking is attached:
> - 0001 is the refactoring adding PostgresNode and RecursiveCopy. I have
> also found that it is quite advantageous to move some of the routines that
> are synonyms of system() and the stuff used for logging into ano
On Sat, Nov 28, 2015 at 1:32 AM, Teodor Sigaev wrote:
> Hi!
>
> There are two commitfest entries which are linked to the same patch/thread
>
> Move PinBuffer and UnpinBuffer to atomics
> https://commitfest.postgresql.org/7/370/
> and
> Replace buffer manager spinlock with atomic operations
>
I wrote:
> gb18030_to_utf8.map utf8_to_gb18030.map
> Could not find the reference file gb-18030-2000.xml, whose origin is
> unstated anyway.
Ah, scratch that complaint; digging in our git history turned up the
origin of that file, so I double-checked it and then updated the script
with a comment
On Mon, Nov 23, 2015 at 11:44:45AM -0800, Peter Geoghegan wrote:
> On Sun, Nov 8, 2015 at 11:52 AM, Noah Misch wrote:
> >> I'm not following along right now - in order to make cleanups the plan is
> >> to revert a couple commits and then redo them prettyfied?
> >
> > Yes, essentially. Given the
I wrote:
> I have not attempted to reverify the files in utils/mb/Unicode against the
> original Unicode Consortium data, but maybe we ought to do that before
> taking any further steps here.
I downloaded the mapping files from unicode.org and attempted to verify
that the Unicode/*.map files could
On Mon, May 04, 2015 at 02:02:18PM +0900, Michael Paquier wrote:
> Coverity is pointing out that as argtypes = NULL in
> plperl_call_perl_func@plperl.c, we will have a pointer dereference if
> desc->arg_arraytype[i] is not a valid OID, see here:
> + Oid*argtypes = NULL;
> [...
On Thu, Nov 26, 2015 at 10:48:50AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane wrote:
> >> I think we should [ return DEFAULT_PGSOCKET_DIR not NULL ]
>
> > I agree with this change in genera. But I wonder if there's a risk here
> > that we brea
On 11/27/2015 02:18 PM, Michael Paquier wrote:
On Fri, Nov 27, 2015 at 8:17 PM, Tomas Vondra
wrote:
So, what's going on? The problem is that while the rename() is atomic, it's
not guaranteed to be durable without an explicit fsync on the parent
directory. And by default we only do fdatasync o
I'm doing some experimenting with the storage engine and I'd like to use a
C++ static library (that has C headers). I only need this to build on
Ubuntu 64-bit for now.
How do I make postgres build with this library?
What changes do I need to make to the build system files?
I assume headers go in s
2015-11-27 17:54 GMT+01:00 Teodor Sigaev :
> Is this patch in 'Waiting on Author' state actually?
yes
I'll try redesign patch by Peter's proposal
Pavel
>
>
> I don't think it's right to reuse SPIError for this. SPIError is
>>> clearly meant to signal an error in the SPI calls. Of
Is this patch in 'Waiting on Author' state actually?
I don't think it's right to reuse SPIError for this. SPIError is
clearly meant to signal an error in the SPI calls. Of course, we can't
stop users from raising whatever exception they want, but if we're going
to advertise
Magnus Hagander writes:
> Hmm. Good point. I didn't realize they already had to be ready to get a
> non-default path back.
Yeah, if it weren't for that, this would definitely be a hazardous change.
But AFAICS, an app that has a problem with this proposal was broken
already, it just didn't know it
Hi!
There are two commitfest entries which are linked to the same patch/thread
Move PinBuffer and UnpinBuffer to atomics
https://commitfest.postgresql.org/7/370/
and
Replace buffer manager spinlock with atomic operations
https://commitfest.postgresql.org/7/408/
Suppose, one of them
Patch is switched to "ready for committer".
Committed, thank you
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Albe Laurenz writes:
> I agree with your proposed fix, the only thing that makes me feel
> uncomfortable
> is that you get error messages like:
> ERROR: character with byte sequence 0x96 in encoding "WIN1250" has no
> equivalent in encoding "MULE_INTERNAL"
Hm, yeah. It's pretty silly that t
Hi hackers,
This is my proposal for 'pg_dump' utility enhancements which enable backup and
recovery of statistical data stored in the 'pg_statistic' table. Statistical
data is very valuable for the query planner, so support engineers have to
manually generate it using ANALYZE whenever they migr
Seems, patch is ready to commit. But it needs some documentation.
Alexander Korotkov wrote:
On Wed, Sep 30, 2015 at 9:46 AM, Michael Paquier mailto:michael.paqu...@gmail.com>> wrote:
On Sat, Sep 19, 2015 at 8:27 AM, Michael Paquier wrote:
> On Fri, Sep 18, 2015 at 6:25 PM, Michael Paqui
Some comments about patch
1
Documentation isn't very informative
Outputs of
SELECT schedule[:][:] FROM sal_emp WHERE name = 'Bill'
and
SELECT schedule[:2][1:] FROM sal_emp WHERE name = 'Bill';
are the same. Suppose, it's better to have differs ones.
2
# create table xxx (a int[]);
# update xxx se
Hi,
On 11/27/2015 02:28 PM, Greg Stark wrote:
On Fri, Nov 27, 2015 at 11:17 AM, Tomas Vondra
wrote:
I plan to do more power failure testing soon, with more complex
test scenarios. I suspect there might be other similar issues (e.g.
when we rename a file before a checkpoint and don't fsync the
On Fri, Nov 27, 2015 at 11:17 AM, Tomas Vondra
wrote:
> I plan to do more power failure testing soon, with more complex test
> scenarios. I suspect there might be other similar issues (e.g. when we
> rename a file before a checkpoint and don't fsync the directory - then the
> rename won't be repla
On Fri, Nov 27, 2015 at 8:17 PM, Tomas Vondra
wrote:
> So, what's going on? The problem is that while the rename() is atomic, it's
> not guaranteed to be durable without an explicit fsync on the parent
> directory. And by default we only do fdatasync on the recycled segments,
> which may not force
What happens is that when we recycle WAL segments, we rename them and then sync
them using fdatasync (which is the default on Linux). However fdatasync does not
force fsync on the parent directory, so in case of power failure the rename may
get lost. The recovery won't realize those segments actua
Hmm, seems, it will be useful to add two fuctions:
tsvector filter(tsvector, array_of_weigths) - returns tsvector contains lexemes
with given weights
tsvector setweight(tsvector, weigth, array_of_lexemes) - sets given weight for
given lexemes
Stas Kelvich wrote:
Hello.
There is patch that
1 Please, make patch compilable with current master.
cd ../../../src/include/catalog && '/usr/local/bin/perl' ./duplicate_oids
3315
3316
2 lexin = TextDatumGetCString(PG_GETARG_DATUM(1))
lexin_len = strlen(lexin)
Why do you use C-string instead of just text? Suppose, much better:
t = PG_GE
Hi,
I've been doing some power failure tests (i.e. unexpectedly
interrupting power) a few days ago, and I've discovered a fairly serious
case of silent data loss on ext3/ext4. Initially i thought it's a
filesystem bug, but after further investigation I'm pretty sure it's our
fault.
What ha
On Fri, Nov 27, 2015 at 10:02 AM, Magnus Hagander wrote:
> Do you have any examples of lists where it *does* work? LIke, could it be
> because our list-unsubscribe links are mailto: links and not http(s) links
> for example?
>From what I read they prefer mailto links. But apparently they only
dis
On Fri, Nov 27, 2015 at 10:57 AM, Greg Stark wrote:
> On Fri, Nov 27, 2015 at 6:43 AM, Stefan Kaltenbrunner
> wrote:
> >
> > well not changing the subject seems like something we could do without
> > fuss - not changing the body would likely mean we would (again) get a
> > number of people askin
On Thu, Nov 26, 2015 at 4:48 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane wrote:
> >> I think we should [ return DEFAULT_PGSOCKET_DIR not NULL ]
>
> > I agree with this change in genera. But I wonder if there's a risk here
> > that we break some a
On Fri, Nov 27, 2015 at 6:43 AM, Stefan Kaltenbrunner
wrote:
>
> well not changing the subject seems like something we could do without
> fuss - not changing the body would likely mean we would (again) get a
> number of people asking "how do I unsubscribe", but maybe we will have
> to live with th
On Thursday 26 November 2015 19:28:15 you wrote:
> I think you don't understand the point: start with the *right* cmake
> version because you could have to redo (a lot of) your work
Between versions CMake there is no fundamental difference.
On my laptop or desktop is already 3.4.0 (new KDE require
On Fri, Nov 27, 2015 at 10:36 AM, Greg Stark wrote:
> On Thu, Nov 26, 2015 at 11:26 PM, Alvaro Herrera
> wrote:
> > I don't think that's going to be anything but unwelcome noise. What
> > would they do if they became aware of the issue? They could switch
> > providers, but that only works for
On Thu, Nov 26, 2015 at 11:26 PM, Alvaro Herrera
wrote:
> I don't think that's going to be anything but unwelcome noise. What
> would they do if they became aware of the issue? They could switch
> providers, but that only works for so long. As soon as Gmail switches
> to p=reject, we've lost.
On 11 November 2015 at 11:45, Dean Rasheed wrote:
> Thanks for testing. I'll post an updated patch sometime soon.
>
I finally got round to looking at this again, and here is an updated patch.
I've reverted the changes to the CHECKFLOATVAL() checks in the
existing functions, so that can be a sepa
Thanks Rushabh for your review and comments.
On Thu, Nov 26, 2015 at 5:39 PM, Rushabh Lathia
wrote:
> Hi Ashutosh,
>
> I reviewed your latest version of patch and over all the implementation
> and other details look good to me.
>
> Here are few cosmetic issues which I found:
>
> 1) Patch not get
Tom Lane wrote:
> There's a discussion over at
> http://www.postgresql.org/message-id/flat/2sa.dhu5.1hk1yrptnfy.1ml...@seznam.cz
> of an apparent error in our WIN1250 -> LATIN2 conversion. I looked into this
> and found that indeed, the code will happily translate certain characters
> for which th
On Fri, Nov 27, 2015 at 3:42 PM, Michael Paquier wrote:
> I am still investigating for a correct fix, looking at reinit.c the
> code in charge of copying the init fork as the main fork for a
> relation at the end of recovery looks to be doing its job correctly...
Attached is a patch that fixes the
38 matches
Mail list logo
