I don't find where of code run the like operation for name Type.
can you tell me where compare Like clues with one column of name type ?
I don't find function for this operation in /src/backend/utils/adt/name.c
when I was in debugging mode and get break point on all functions.
thanks.
On 12/14/2013 11:24 AM, Gregory Smith wrote:
>
>
> Things I can already see to work on here are:
>
> -Fix the regression tests
> -Catch up to master again
I've got much of that in the tree:
https://github.com/ringerc/postgres/tree/rls-9.4
--
Craig Ringer http://www.2ndQuad
On 12/14/2013 11:24 AM, Gregory Smith wrote:
> The RLS feature set available with the CF submission is good enough
> for those projects to continue exploring PostgreSQL
You may want to check out the updated writable security-barrier views patch.
http://www.postgresql.org/message-id/52ab112b.602
I got a complain from a user.
If current locale is SJIS, psql does not set client encoding to SJIS.
# localedef -f SHIFT_JIS -i ja_JP /usr/lib/locale/ja_JP.SJIS
$ export LANG=ja_JP.SJIS
$ psql
\encoding
SQL_ASCII <-- This should be SJIS
This is because the encoding map (encoding_match_list) in c
Peter Geoghegan writes:
> I attached two revisions - one of my patch (btreelock_insert_on_dup)
> and one of your alternative design (exclusion_insert_on_dup).
I spent a little bit of time looking at btreelock_insert_on_dup. AFAICT
it executes FormIndexDatum() for later indexes while holding asso
On 12/12/2013 04:36 PM, Tom Lane wrote:
> BTW, on further thought, I'm afraid this is a bigger can of worms than
> it appears. The remarks above presume that the subquery is simple enough
> to be pulled up, which is the case in this example. It might not be too
> hard to make that case work. But
On Dec 13, 2013, at 8:52 AM, Tom Lane wrote:
> Please apply commit 478af9b79770da43a2d89fcc5872d09a2d8731f8 and see
> if that doesn't fix it for you.
It appears to fix it. Thanks!
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Dec 13, 2013, at 1:49 PM, Merlin Moncure wrote:
> Is this an edge case or something that will hit a lot of users?
My understanding (Tom can correct me if I'm wrong, I'm sure) is that it is an
issue for servers on 9.3.2 where there are a lot of query cancellations due to
facilities like stat
On Fri, Dec 13, 2013 at 12:32 PM, Robert Haas wrote:
> On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane wrote:
>> And while we're on the subject ... isn't bgworker_die() utterly and
>> completely broken? That unconditional elog(FATAL) means that no process
>> using that handler can do anything remotel
Andres Freund wrote:
> On 2013-12-12 18:24:34 -0300, Alvaro Herrera wrote:
> > + else if (TransactionIdIsValid(update_xid) && !has_lockers)
> > + {
> > + /*
> > +* If there's a single member and it's an update, pass it back
> > alone
> > +* without creating a
On 12/13/13 1:49 PM, Fabrízio de Royes Mello wrote:
On Fri, Dec 13, 2013 at 5:35 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
>
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= mailto:fabriziome...@gmail.com>> writes:
> > I think the goal of the "make_date/time/timestamp" function series is bu
On 12/13/2013 02:35 PM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
I think the goal of the "make_date/time/timestamp" function series is build
a date/time/timestamp from scratch, so the use of 'make_timestamptz' is to
build a specific timestamp with timezone and don't c
On Fri, Dec 13, 2013 at 5:35 PM, Tom Lane wrote:
>
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
writes:
> > I think the goal of the "make_date/time/timestamp" function series is
build
> > a date/time/timestamp from scratch, so the use of 'make_timestamptz' is
to
> > build a specific timestamp wit
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> I think the goal of the "make_date/time/timestamp" function series is build
> a date/time/timestamp from scratch, so the use of 'make_timestamptz' is to
> build a specific timestamp with timezone and don't convert it.
Yeah; we don't really want
Robert Haas writes:
> It seems to me that we should change every place that temporarily
> changes ImmediateInterruptOK to restore the original value instead of
> making assumptions about what it must have been.
No, that's backwards. The problem isn't that it could be sane to enter,
say, PGSemaph
Stephen Frost writes:
>> Stephen had some legitimate concerns. I don't entirely agree, but they
>> are legitimate concerns, and we don't want to just override them.
The main disturbing concern for me is to do with pg_restore and major
upgrades, where the blob we have in the catalogs might not par
Robert Haas escribió:
> On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane wrote:
> > And while we're on the subject ... isn't bgworker_die() utterly and
> > completely broken? That unconditional elog(FATAL) means that no process
> > using that handler can do anything remotely interesting, like say touch
On Fri, Dec 13, 2013 at 10:14:06AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I'm not totally satisfied with the name of the GUC, wal_log_hintbits.
>
> Me either; at the very least, it's short an underscore: wal_log_hint_bits
> would be more readable. But how about just "wal_log_hi
* Jeff Davis (pg...@j-davis.com) wrote:
> For what it's worth, I think the idea of extension templates has good
> conceptual integrity. Extensions are external blobs. To make them work
> more smoothly in several ways, we move them into the catalog. They have
> pretty much the same upsides and downs
On Fri, Dec 13, 2013 at 1:15 PM, Andres Freund wrote:
> On 2013-12-13 12:54:09 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > I wonder what to do about bgworker's bgworker_die()? I don't really see
>> > how that can be fixed without breaking the API?
>>
>> IMO it should be flushed and bgwor
Heikki Linnakangas escribió:
> I haven't been following this thread in detail, but would it help if
> we implemented a scheme to reduce (auto)vacuum's memory usage? Such
> schemes have been discussed in the past, packing the list of dead
> items more tightly.
Well, it would help some, but it woul
On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane wrote:
> And while we're on the subject ... isn't bgworker_die() utterly and
> completely broken? That unconditional elog(FATAL) means that no process
> using that handler can do anything remotely interesting, like say touch
> shared memory.
Yeah, but f
On 12/13/2013 08:24 PM, Bruce Momjian wrote:
On Wed, Dec 11, 2013 at 10:35:32AM -0800, Josh Berkus wrote:
On 12/11/2013 09:57 AM, Robert Haas wrote:
I don't agree with that assessment. Anything that involves changing
the scheduling of autovacuum is a major project that will legitimately
provok
On Wed, Dec 11, 2013 at 10:35:32AM -0800, Josh Berkus wrote:
> On 12/11/2013 09:57 AM, Robert Haas wrote:
> > I don't agree with that assessment. Anything that involves changing
> > the scheduling of autovacuum is a major project that will legitimately
> > provoke much controversy. Extensive test
On Fri, Dec 13, 2013 at 3:53 PM, Martijn van Oosterhout
wrote:
>
> On Thu, Dec 12, 2013 at 08:50:26PM -0200, Fabrízio de Royes Mello wrote:
> > On Thu, Dec 12, 2013 at 3:11 PM, Pavel Stehule wrote:
> >
> > > Hello
> > >
> > > this patch try to complete a set of functions make_date and
make_timesta
On 2013-12-13 12:54:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I wonder what to do about bgworker's bgworker_die()? I don't really see
> > how that can be fixed without breaking the API?
>
> IMO it should be flushed and bgworkers should use the same die() handler
> as every other backe
Andres Freund writes:
> I wonder what to do about bgworker's bgworker_die()? I don't really see
> how that can be fixed without breaking the API?
IMO it should be flushed and bgworkers should use the same die() handler
as every other backend, or else one like the one in worker_spi, which just
set
On Thu, Dec 12, 2013 at 08:50:26PM -0200, Fabrízio de Royes Mello wrote:
> On Thu, Dec 12, 2013 at 3:11 PM, Pavel Stehule wrote:
>
> > Hello
> >
> > this patch try to complete a set of functions make_date and make_timestamp.
> >
> >
> Could we have the 'make_timestamptz' function too?
Wouldn't th
On Wed, 2013-12-11 at 20:49 +0100, Dimitri Fontaine wrote:
> Robert Haas writes:
> > I strongly agree. PostgreSQL has succeeded because we try not to do
> > things at all until we're sure we know how to do them right.
>
> I still agree to the principle, or I wouldn't even try. Not in details,
>
On 2013-12-13 12:19:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Shouldn't the HOLD_INTERRUPTS() in handle_sig_alarm() prevent any
> > eventual ProcessInterrupts() in the timeout handlers from doing anything
> > harmful?
>
> Sorry, I misspoke there. The case I'm worried about is doing s
Christophe Pettus writes:
> On Dec 13, 2013, at 8:52 AM, Tom Lane wrote:
>> Please apply commit 478af9b79770da43a2d89fcc5872d09a2d8731f8 and see
>> if that doesn't fix it for you.
> Great, thanks. Would the statement_timeout firing invoke this path? (I'm
> wondering why this particular instal
Andres Freund writes:
> On 2013-12-13 11:26:44 -0500, Tom Lane wrote:
>> On closer inspection, I'm thinking that actually it'd be a good idea if
>> handle_sig_alarm did what we do in, for example, HandleCatchupInterrupt:
>> it should save, clear, and restore ImmediateInterruptOK, so as to make
>>
On Dec 13, 2013, at 8:52 AM, Tom Lane wrote:
> Please apply commit 478af9b79770da43a2d89fcc5872d09a2d8731f8 and see
> if that doesn't fix it for you.
Great, thanks. Would the statement_timeout firing invoke this path? (I'm
wondering why this particular installation was experiencing this.)
-
On 2013-12-13 13:39:20 -0300, Alvaro Herrera wrote:
> Here's cache code with LRU superpowers (ahem.)
Heh.
> I settled on 256 as number of entries because it's in the same ballpark
> as MaxHeapTuplesPerPage which seems a reasonable guideline to follow.
Sounds ok.
> I considered the idea of avoid
Christophe Pettus writes:
> Yes, that's what is happening there (I had to check with the client's
> developers). It's possible that the one-minute repeat is due to the
> application reissuing the query, rather than specifically related to the
> spinlock issue. What this does reveal is that al
On 2013-12-13 11:26:44 -0500, Tom Lane wrote:
> On closer inspection, I'm thinking that actually it'd be a good idea if
> handle_sig_alarm did what we do in, for example, HandleCatchupInterrupt:
> it should save, clear, and restore ImmediateInterruptOK, so as to make
> the world safe for timeout ha
On closer inspection, I'm thinking that actually it'd be a good idea if
handle_sig_alarm did what we do in, for example, HandleCatchupInterrupt:
it should save, clear, and restore ImmediateInterruptOK, so as to make
the world safe for timeout handlers to do things that might include a
CHECK_FOR_INT
On 2013-12-13 10:30:48 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-12-13 09:52:06 -0500, Tom Lane wrote:
> >> I think you're probably right:
> >> what should be in the interrupt handler is something like
> >> "if (ImmediateInterruptOK) CHECK_FOR_INTERRUPTS();"
>
> > Yea, that sound
Andres Freund writes:
> On 2013-12-13 09:52:06 -0500, Tom Lane wrote:
>> I think you're probably right:
>> what should be in the interrupt handler is something like
>> "if (ImmediateInterruptOK) CHECK_FOR_INTERRUPTS();"
> Yea, that sounds right. Or just don't set process interrupts there, it
> do
On 2013-12-13 09:52:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Tom, could this be caused by c357be2cd9434c70904d871d9b96828b31a50cc5?
> > Specifically the added CHECK_FOR_INTERRUPTS() in handle_sig_alarm()?
> > ISTM nothing is preventing us from jumping out of code holding a
> > spinloc
On 13 December 2013 15:07, Tom Lane wrote:
> Dean Rasheed writes:
>> I can't think of any practical uses for this kind of query, so I don't
>> think it's worth worrying too much about its results until/unless
>> someone comes up with a real use-case.
>
>> However, given that we currently support
Heikki Linnakangas writes:
> I'm not totally satisfied with the name of the GUC, wal_log_hintbits.
Me either; at the very least, it's short an underscore: wal_log_hint_bits
would be more readable. But how about just "wal_log_hints"?
regards, tom lane
--
Sent via pgsq
Dean Rasheed writes:
> I can't think of any practical uses for this kind of query, so I don't
> think it's worth worrying too much about its results until/unless
> someone comes up with a real use-case.
> However, given that we currently support queries like "select distinct
> * from nocols" (alb
Andres Freund writes:
> Tom, could this be caused by c357be2cd9434c70904d871d9b96828b31a50cc5?
> Specifically the added CHECK_FOR_INTERRUPTS() in handle_sig_alarm()?
> ISTM nothing is preventing us from jumping out of code holding a
> spinlock?
Hm ... what should stop it is that ImmediateInterrup
On 12/13/2013 07:55 AM, Sawada Masahiko wrote:
On Fri, Dec 13, 2013 at 1:51 PM, Dilip kumar wrote:
On 04 December 2013, Sawada Masahiko Wrote
I attached the patch which have modified based on Robert suggestion,
and fixed typo.
I have reviewed the modified patch and I have some comments..
1
On 2013-12-13 08:30:41 -0500, Robert Haas wrote:
> On Thu, Dec 12, 2013 at 1:52 PM, Andres Freund wrote:
> > Puh. I honestly have zero confidence in DBAs making an informed decision
> > about something like this. Honestly, for a replication solution, how
> > often do you think this will be an issu
Hi all
Here's an updated version of the updatable security barrier views patch
that's proposed as the next stage of progressing row-security toward
useful and maintainable inclusion in core.
If updatable security barrier views are available then the row-security
code won't have to play around wit
On Fri, Dec 13, 2013 at 11:44 AM, Simon Riggs wrote:
>
> On 13 December 2013 13:22, Andres Freund wrote:
> > On 2013-12-13 13:09:13 +, Simon Riggs wrote:
> >> On 13 December 2013 11:58, Andres Freund
wrote:
> >> > On 2013-12-13 11:56:47 +, Simon Riggs wrote:
> >> >> On 12 December 2013 2
On 13 December 2013 13:22, Andres Freund wrote:
> On 2013-12-13 13:09:13 +, Simon Riggs wrote:
>> On 13 December 2013 11:58, Andres Freund wrote:
>> > On 2013-12-13 11:56:47 +, Simon Riggs wrote:
>> >> On 12 December 2013 21:58, Fabrízio de Royes Mello
>> >> wrote:
>> >> > Reviewing the
Hello,
The attached patch fixes incorrect message output on the client side. I
guess this problem can happen with any major release. Could you review
this?
[Problem]
When the client's locale differs from the server's message locale, the
messages generated on the server are converted appro
On Fri, Dec 13, 2013 at 7:09 AM, Pavel Stehule
wrote:
>
> I though about it. Then there are two questions
>
> a) Could we have a make_timetz function?
>
> b) What type we use for timezone?
>
I just think in a function that returns the timestamp with timezone based
on the current 'timezone' setti
On Sat, Dec 14, 2013 at 12:12 AM, Andres Freund wrote:
> On 2013-12-13 20:58:24 +1300, David Rowley wrote:
> > On Wed, Dec 11, 2013 at 1:11 PM, Robert Haas
> wrote:
> > This introduced a new compiler warning on the visual studios build:
> > d:\postgres\b\src\backend\utils\cache\relcache.c(3958)
On Thu, Dec 12, 2013 at 1:52 PM, Andres Freund wrote:
> Puh. I honestly have zero confidence in DBAs making an informed decision
> about something like this. Honestly, for a replication solution, how
> often do you think this will be an issue?
If you imagine a scenario where somebody establishes
On 2013-12-13 13:09:13 +, Simon Riggs wrote:
> On 13 December 2013 11:58, Andres Freund wrote:
> > On 2013-12-13 11:56:47 +, Simon Riggs wrote:
> >> On 12 December 2013 21:58, Fabrízio de Royes Mello
> >> wrote:
> >> > Reviewing the committed patch I noted that the "CheckForStandbyTrigger
Hello
I am sending a rebased patch.
Now dump generated with --if-exists option is readable by pg_restore
Regards
Pavel
commit 19f21165343b1aaa6cc21d381b84e3c0ce6e3b46
Author: Pavel Stehule
Date: Fri Dec 13 14:02:46 2013 +0100
--if-exists option for pg_dump
diff --git a/doc/src/sgml/ref
On 13 December 2013 11:58, Andres Freund wrote:
> On 2013-12-13 11:56:47 +, Simon Riggs wrote:
>> On 12 December 2013 21:58, Fabrízio de Royes Mello
>> wrote:
>> > Reviewing the committed patch I noted that the "CheckForStandbyTrigger()"
>> > after the delay was removed.
>> >
>> > If we promo
On Thu, Dec 12, 2013 at 09:18:03PM -0500, Peter Eisentraut wrote:
> On Thu, 2013-12-12 at 12:30 +0200, Marko Kreen wrote:
> > First, if there is explicit wish to keep RC4/SEED in play, I'm fine
> > with "HIGH:MEDIUM:!aNULL" as new default. Clarity-wise, it's still
> > much better than current valu
On 2013-12-13 11:56:47 +, Simon Riggs wrote:
> On 12 December 2013 21:58, Fabrízio de Royes Mello
> wrote:
> > Reviewing the committed patch I noted that the "CheckForStandbyTrigger()"
> > after the delay was removed.
> >
> > If we promote the standby during the delay and don't check the trigg
Hi,
On 2013-12-12 19:35:36 -0800, Christophe Pettus wrote:
> On Dec 12, 2013, at 6:41 PM, Andres Freund wrote:
>
> > Christophe: are there any "unusual" ERROR messages preceding the crash,
> > possibly some minutes before?
>
> Interestingly, each spinlock PANIC is *followed*, about one minute l
On 12 December 2013 21:58, Fabrízio de Royes Mello
wrote:
>
> On Thu, Dec 12, 2013 at 3:42 PM, Fabrízio de Royes Mello
> wrote:
>>
>> On Thu, Dec 12, 2013 at 3:39 PM, Simon Riggs
>> wrote:
>> >
>> > On 12 December 2013 15:19, Simon Riggs wrote:
>> >
>> > > Don't panic guys! I meant UTC offset o
lazy_vacuum_page() does this:
1. START_CRIT_SECTION()
2. Remove dead tuples from the page, marking the itemid's unused.
3. MarkBufferDirty
4. if all remaining tuples on the page are visible to everyone, set the
all-visible flag on the page, and call visibilitymap_set() to set the VM
bit.
5 visi
On 2013-12-13 20:58:24 +1300, David Rowley wrote:
> On Wed, Dec 11, 2013 at 1:11 PM, Robert Haas wrote:
> This introduced a new compiler warning on the visual studios build:
> d:\postgres\b\src\backend\utils\cache\relcache.c(3958): warning C4715:
> 'RelationGetIndexAttrBitmap' : not all control
This is a small patch a bit improving a comment in
src/backend/commands/copy.c.
Thanks,
Best regards,
Etsuro Fujita
copy-comment.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 13 December 2013 01:14, Tom Lane wrote:
> The only thing I've come across that arguably doesn't work is SELECT
> DISTINCT:
>
> regression=# select distinct from pg_database;
> --
> (8 rows)
>
> The reason this says "8 rows" is that the produced plan is just a seqscan
> of pg_database returning
2013/12/12 Fabrízio de Royes Mello
>
> On Thu, Dec 12, 2013 at 3:11 PM, Pavel Stehule wrote:
>
>> Hello
>>
>> this patch try to complete a set of functions make_date and
>> make_timestamp.
>>
>>
> Could we have the 'make_timestamptz' function too?
>
I though about it. Then there are two question
On Fri, Dec 13, 2013 at 5:49 PM, Dilip kumar wrote:
> On Fri, Dec 13, 2013 at 11:25, Sawada Masahiko Wrote
>
>> >> I attached the patch which have modified based on Robert suggestion,
>> >> and fixed typo.
>> >
>> > I have reviewed the modified patch and I have some comments..
>> >
>> > 1. Patch n
On Fri, Dec 13, 2013 at 11:25, Sawada Masahiko Wrote
> >> I attached the patch which have modified based on Robert suggestion,
> >> and fixed typo.
> >
> > I have reviewed the modified patch and I have some comments..
> >
> > 1. Patch need to be rebased (failed applying on head)
> >
> > 2. crc fie
e precision) AND (col2 <=
0.02::double precision))
Total runtime: 1687.047 ms
(8 rows)
Thanks,
Best regards,
Etsuro Fujita
explain-bitmapscan-20131213.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 11, 2013 at 1:11 PM, Robert Haas wrote:
>
> Committed #1 (again). Regarding this:
>
>
This introduced a new compiler warning on the visual studios build:
d:\postgres\b\src\backend\utils\cache\relcache.c(3958): warning C4715:
'RelationGetIndexAttrBitmap' : not all control paths retur
69 matches
Mail list logo
