Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> AndrewSN can't post at the moment, but asked me to post this for him:
> "Knowing the md5 hash is enough to authenticate via the 'md5' method in
> pg_hba.conf, even if you don't know the original password.
If you know the md5 hash, you know eve
So, can I specify the password to pg_connect() as
'md5127349123742342344234'?
Certainly not. We'd hardly be worrying about obscuring the original
password if the encrypted version were enough to get in with.
AndrewSN can't post at the moment, but asked me to post this for him:
"Knowing the m
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> I guess I know (at least part) of what you mean. This is because we rely on
> replay all the xlog no matter it belongs to a committed transaction or not.
> Why? Because a failed transaction is not totally useless since later
> transaction may reply o
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> So, can I specify the password to pg_connect() as
> 'md5127349123742342344234'?
Certainly not. We'd hardly be worrying about obscuring the original
password if the encrypted version were enough to get in with.
regards
Where are we on this? In general I agree with Tom, but I have no time to
do the work. Unless someone has an immediate implementation, I suggest
that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
which is the minimum needed to unbreak Windows builds, while this gets
sorted o
"Hannu Krosing" <[EMAIL PROTECTED]> wrote
>
> Could anybody tell me what is the smallest working page size for
> postgresql ?
>
> I have a table where access is highly random over huge table getting
> usually only one small tuple from each page. One way to get more
> performance could be using sma
I wrote:
> I had forgotten that the Windows build is broken. I'll see what I can
> do with throwing together the cleaner-API function.
Done, but I noticed that the change to createuser has arguably broken
it; at least we need to change the docs. To wit, the docs say
-E
--encrypted
Encrypts
"Tom Lane" <[EMAIL PROTECTED]> wrote
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
>> BEGIN TRANSACTION WITHOUT XLOG;/* forbidden vacuum, PITR etc */
>
>> So during this peroid, if any transaction failed, the only consequence is
>> add invisible garbage data.
>
> No, the likely consequence is
Wow, that is large. I think PL/pgSQL is your best approach. I
recommend you create a schema that users can write into.
---
Ashok Agrawal wrote:
> I don't need ability to sit at a prompt and type stuff.
>
> To be more clea
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> BEGIN TRANSACTION WITHOUT XLOG;/* forbidden vacuum, PITR etc */
> So during this peroid, if any transaction failed, the only consequence is
> add invisible garbage data.
No, the likely consequence is irretrievable corruption of any table or
index
I don't need ability to sit at a prompt and type stuff.
To be more clear, I am attaching one sample code. I would like to
migrate this code using postgres without converting into procedure
or function.
Thanks
Ashok
Bruce Momjian wrote On 12/22/05 15:35,:
> Hannu Krosing wrote:
>
>>?hel kenal p?
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
>
> To make things, is it possible to add a GUC to let user disable *all* the
> xlogs?
>
It may work like this:
BEGIN TRANSACTION WITHOUT XLOG;/* forbidden vacuum, PITR etc */
BEGIN
.../* no xlog during this peroid */
END; /* don't mark this
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
How about:
:= {row|record|variable|'[ROW](' comma separated list of scalar vars
')'}
instead, where the ROW is optional?
If we're going to do this at all (which I'm still agin), I think the ROW
keyword is important to minimi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Where are we on this? In general I agree with Tom, but I have no time to
> do the work. Unless someone has an immediate implementation, I suggest
> that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
> which is the minimum needed t
"Simon Riggs" <[EMAIL PROTECTED]> wrote
>
> No it isn't. All of the WAL bypass logic does *not* operate when PITR is
> active. The WAL bypass logic is aimed at Data Warehouses, which
> typically never operate in PITR mode for performance reasons, however
> the choice is yours.
>
To make things, i
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
So it appears that pg_md5_encrypt is not officially exported from libpq.
Does anyone see a problem with adding it to the export list and the
header file?
Is it different to normal md5? How is this helpful to
Hannu Krosing wrote:
> ?hel kenal p?eval, N, 2005-12-22 kell 18:19, kirjutas Bruce Momjian:
> > Ashok Agrawal wrote:
> > > Hi ,
> > >
> > > Here is the requirements :
> > >
> > > 1. Development & Support team can ONLY have READ Only ACCESS
> > >to PRODUCTION Database. They will NOT have acces
Hi
Could anybody tell me what is the smallest working page size for
postgresql ?
I have a table where access is highly random over huge table getting
usually only one small tuple from each page. One way to get more
performance could be using smaller page size, so the per-tuple read
overhead would
Ühel kenal päeval, N, 2005-12-22 kell 18:19, kirjutas Bruce Momjian:
> Ashok Agrawal wrote:
> > Hi ,
> >
> > Here is the requirements :
> >
> > 1. Development & Support team can ONLY have READ Only ACCESS
> >to PRODUCTION Database. They will NOT have access to create
> >stored procedure &
David Fetter <[EMAIL PROTECTED]> writes:
> How about:
> := {row|record|variable|'[ROW](' comma separated list of scalar
> vars ')'}
> instead, where the ROW is optional?
If we're going to do this at all (which I'm still agin), I think the ROW
keyword is important to minimize ambiguity. If you a
Ashok Agrawal wrote:
> Hi ,
>
> Here is the requirements :
>
> 1. Development & Support team can ONLY have READ Only ACCESS
>to PRODUCTION Database. They will NOT have access to create
>stored procedure & functions in the PRODUCTION on the fly.
>
> 2. During application support, need to
Hi ,
Here is the requirements :
1. Development & Support team can ONLY have READ Only ACCESS
to PRODUCTION Database. They will NOT have access to create
stored procedure & functions in the PRODUCTION on the fly.
2. During application support, need to write script which
uses procedural l
Jim C. Nasby wrote:
> On Sat, Dec 17, 2005 at 04:59:45PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Looking before that, the 64-bit registers are now prefixed with 'r'
> > > > instead of 'e', so what I did was to convert all the long/l assembler
> > > > ins
Trent Shipley wrote:
> On Thursday 2005-12-22 14:28, Lukas Kahwe Smith wrote:
> > Bruce Momjian wrote:
> > > Right, if the cardinality changes, you realize this before execution and
> > > optimize/save the plan again. A further optimization would be to save
> > > _multiple_ plans for a single prep
On Thursday 2005-12-22 14:28, Lukas Kahwe Smith wrote:
> Bruce Momjian wrote:
> > Right, if the cardinality changes, you realize this before execution and
> > optimize/save the plan again. A further optimization would be to save
> > _multiple_ plans for a single prepared plan based on constants an
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> On Thu, 2005-12-22 at 21:18 +0100, Martijn van Oosterhout wrote:
> > Considering "WAL bypass" is code for "breaks PITR"
>
> No it isn't. All of the WAL bypass logic does *not* operate when PITR is
> active. The WAL bypass logic is aimed at Data Warehouses
An interesting article on sorting and comparison count:
http://www.acm.org/jea/ARTICLES/Vol7Nbr5.pdf
Here is the article, the code, and an implementation that I have been
toying with:
http://cap.connx.com/chess-engines/new-approach/algos.zip
Algorithm quickheap is especially interesting because i
On Thu, 2005-12-22 at 21:18 +0100, Martijn van Oosterhout wrote:
> Considering "WAL bypass" is code for "breaks PITR"
No it isn't. All of the WAL bypass logic does *not* operate when PITR is
active. The WAL bypass logic is aimed at Data Warehouses, which
typically never operate in PITR mode for pe
On Thu, 2005-12-22 at 10:40 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Sorry, I missed that.
>
> And you evidently still didn't understand it. Locking both pages does
> not fix the problem, because it doesn't guarantee that there's not a
> concurrent indexscan in flight
On Thu, 22 Dec 2005 08:01:00 +0100, Martijn van Oosterhout
wrote:
>But where are you including the cost to check how many cells are
>already sorted? That would be O(H), right?
Yes. I didn't mention it, because H < N.
> This is where we come back
>to the issue that comparisons in PostgreSQL are
On Thu, Dec 22, 2005 at 11:18:22AM +0100, Martijn van Oosterhout wrote:
> On Thu, Dec 22, 2005 at 10:52:58AM +0100, REYNAUD Jean-Samuel wrote:
> > Hi
> >
> > I've just tried it, and it works. So it's a good work-around.
> >
> > Though, is it a wanted feature to have a function being performed on
Bruce Momjian wrote:
Right, if the cardinality changes, you realize this before execution and
optimize/save the plan again. A further optimization would be to save
_multiple_ plans for a single prepared plan based on constants and
choose one of the other, but that is beyond where we are willing
We need invalidation anyway, so I don't see why an intermediate step
makes sense.
---
Jim C. Nasby wrote:
> Well, not just rows; total tuples, both base heap and index. ISTM that
> would be a better metric than just plain ro
On Thu, Dec 22, 2005 at 10:14:15PM +0100, Lukas Smith wrote:
> Ok, just so I understand this correctly. In the mentioned case the
> cardinality does not really change in regards to the table stats, its
> just thatI happen to use a value that has a different selectivity and
> therefore I may need
Well, not just rows; total tuples, both base heap and index. ISTM that
would be a better metric than just plain rows read out of base or rows
returned.
Depending on how far down this road we want to go, this would allow for
detecting what parameter values require different query plans, and then
us
Bruce Momjian wrote:
It is an issue for all databases. We gave a TODO about it:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Ok, just so I unders
Lukas Smith wrote:
> Bruce Momjian wrote:
>
> >> Maybe I am mixing up separate concepts (are bound variables and prepared
> >> statements different concepts?) here. I also do not really understand if
> >> that means that oracle does not store a query plan for a prepared query
> >> or if it just
On Thu, Dec 22, 2005 at 09:55:14PM +0100, Lukas Smith wrote:
> Bruce Momjian wrote:
>
> >>Maybe I am mixing up separate concepts (are bound variables and prepared
> >>statements different concepts?) here. I also do not really understand if
> >>that means that oracle does not store a query plan f
On Thu, Dec 22, 2005 at 10:18:16AM +0100, Pavel Stehule wrote:
> Hello
>
> Now, statements EXECUTE INTO and SELECT INTO allow using list of scalars.
> FORe and FORs allow only ROW o RECORD VARIABLE. I'll plan and I did it
> enhance this stmts:
>
> := FOR IN {SELECT | EXECUTE} ... LOOP
> := {
Bruce Momjian wrote:
Maybe I am mixing up separate concepts (are bound variables and prepared
statements different concepts?) here. I also do not really understand if
that means that oracle does not store a query plan for a prepared query
or if it just does some special handling in case it kno
Lukas Smith wrote:
> Jim C. Nasby wrote:
>
> > Now, if both of these are done using a prepared statement, it's going to
> > look like:
> >
> > SELECT * FROM queue WHERE status='?';
> >
> > If the first one to run is the queue processing one, the planner will
> > probably choose the index. This m
Jim C. Nasby wrote:
Now, if both of these are done using a prepared statement, it's going to
look like:
SELECT * FROM queue WHERE status='?';
If the first one to run is the queue processing one, the planner will
probably choose the index. This means that when we're searching on 'N',
there will
On Thu, Dec 22, 2005 at 12:37:51PM -0600, Jim C. Nasby wrote:
> I do think this needs to be something that is made either completely
> transparent or must be specifically enabled. As described, I believe
> this would break PITR, so users should have to specifically request that
> behavior (and they
Oh, OK, so you are logging prepared queries where the plan generates a
significantly different number of rows from previous runs. I am not
sure why that is better, or easier, than just invalidating the cached
plan if the cardinality changes.
-
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> We already do something similar for page deletions. Empty pages are not
> deleted right away, but they are marked with BTP_DEAD, and then deleted
> on a subsequent vacuum. Or something like that, I don't remember the
> exact details.
Right, and the re
On Thu, 2005-12-22 at 12:12 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Currently, CTAS optimization requires a heap_sync during ExecEndPlan. It
> > would be easy enough to extend this so that it also works for INSERT,
> > UPDATE and DELETE.
>
> If you tried to do it that
On Wed, Dec 21, 2005 at 11:00:31PM -0500, Bruce Momjian wrote:
> > Track normal resource consumption (ie: tuples read) for planned queries
> > and record parameter values that result in drastically different
> > resource consumption.
> >
> > This would at least make it easy for admins to identify
Martijn van Oosterhout wrote:
> The downsides are probably that it's a pain to make it work
> concurrently and requires writing each index page at least twice. But
> it's a thought...
We already do something similar for page deletions. Empty pages are not
deleted right away, but they are marked
BTW, this should also probably be moved over to -hackers...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of b
On Thu, Dec 22, 2005 at 02:31:33PM +, Simon Riggs wrote:
> Having just optimized COPY to avoid writing WAL during the transaction
> in which a table was first created, it seems worth considering whether
> this should occur for INSERT, UPDATE and DELETE also.
>
> It is fairly common to do data
Simon Riggs <[EMAIL PROTECTED]> writes:
> Currently, CTAS optimization requires a heap_sync during ExecEndPlan. It
> would be easy enough to extend this so that it also works for INSERT,
> UPDATE and DELETE.
If you tried to do it that way you'd break the system completely. Not
all updates go thro
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> := FOR IN {SELECT | EXECUTE} ... LOOP
> := {row|record|comma separated list of scalar vars}
This part seems all right to me.
> := ':='
> := {row|record|variable|'ROW(' comma separated list of scalar vars
> ')'}
As I already said on -patches,
On Thu, Dec 22, 2005 at 10:40:24AM -0500, Tom Lane wrote:
> And you evidently still didn't understand it. Locking both pages does
> not fix the problem, because it doesn't guarantee that there's not a
> concurrent indexscan in flight from one to the other. If you move items
> from one page to the
Simon Riggs <[EMAIL PROTECTED]> writes:
> Sorry, I missed that.
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from one to the other. If you move items
from one page to the
Having just optimized COPY to avoid writing WAL during the transaction
in which a table was first created, it seems worth considering whether
this should occur for INSERT, UPDATE and DELETE also.
It is fairly common to do data transformation using INSERT SELECTs and
UPDATEs. This is usually done w
--- Karel Zak <[EMAIL PROTECTED]> escreveu:
I have a patch like this. But this was for 7.4.x. I have to take a look
at it.
> That's important point. How resolve this problem Oracle? Maybe we can
> say (in docs) that with non-English locales it works with days/months
> names as in FM (fill) mode.
Is it possible to just not replicate the internal tsearch tables ?
Dave
On 21-Dec-05, at 4:37 PM, Dave Cramer wrote:
Thanks, that might be easier than first thought.
Dave
On 21-Dec-05, at 2:04 PM, Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
Is it possible to add the old signatur
On Thu, Dec 22, 2005 at 10:53:39AM +, Simon Riggs wrote:
> IMHO the problem is the deletion of the xlog file, not the error
> message.
>
> If you *did* lose an xlog file, would you not expect the system to come
> up anyway? You're saying that you'd want the system to stay down because
> of thi
On Mon, 2005-12-19 at 17:17 +0900, OKADA Satoshi wrote:
> Tom Lane wrote:
>
> >OKADA Satoshi <[EMAIL PROTECTED]> writes:
> >
> >
> >>The loss of log was simulated by deleting the latest xlog file.
> >>
> >>
> >
> >What does that have to do with reality? Postgres is very careful not to
> >u
On Wed, 2005-12-21 at 19:07 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > While we scan, if we found two adjacent pages, both of which have less
> > than (say) 40% rows, we could re-join or "unsplit" those pages together.
>
> Curiously enough, this has been thought of before
On Thu, Dec 22, 2005 at 10:52:58AM +0100, REYNAUD Jean-Samuel wrote:
> Hi
>
> I've just tried it, and it works. So it's a good work-around.
>
> Though, is it a wanted feature to have a function being performed on
> each row before the offset ?
Well, saying offset 5000 pretty much means to calcul
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row before the offset ?
Le mercredi 21 décembre 2005 à 13:41 -0600, Jim C. Nasby a écrit :
> Have you tried
>
> SELECT *, test_func(idkeyword)
> FROM (
Hello
Now, statements EXECUTE INTO and SELECT INTO allow using list of scalars.
FORe and FORs allow only ROW o RECORD VARIABLE. I'll plan and I did it
enhance this stmts:
:= FOR IN {SELECT | EXECUTE} ... LOOP
:= {row|record|comma separated list of scalar vars}
:= ':='
:= {row|record|v
Jim C. Nasby wrote:
On Wed, Dec 21, 2005 at 05:43:38PM -0500, Bruce Momjian wrote:
Rick Gigger wrote:
It seems to me like there are two classes of problems here:
1) Simply invalidating plans made with out of date statistics.
2) Using run-time collected data to update the plan to something mo
On Wed, 2005-12-21 at 23:50 -0500, Tom Lane wrote:
> Manuel Sugawara writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> I thought to_char already had i18n behavior. What exactly are you
> >> thinking of changing?
>
> > The modifiers that are suitable to localize. Month and day names comes
> >
65 matches
Mail list logo
