Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > It seems to me the only rational way to approach this is to have a per-table > > flag that sets that table to be non-logged. Essentially changing a table's > > behaviour to that of a temporary table except that othe

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

> In many cases you could use temporary tables, but sometimes you might want > multiple processes or multiple transactions to be able to see the data. Could always implement GLOBAL TEMP tables that have the ability to use these kinds of shortcuts. -- ---(end of broadcast

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

Greg Stark <[EMAIL PROTECTED]> writes: > It seems to me the only rational way to approach this is to have a per-table > flag that sets that table to be non-logged. Essentially changing a table's > behaviour to that of a temporary table except that other transactions can see > it. But what's the po

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

"Greg Stark" <[EMAIL PROTECTED]> wrote > > But I don't see turning on and off the WAL on a per-transaction basis to > be > useful. Every transaction in the system is affected by the WAL status of > every > other transaction working with the same tables. It doesn't serve any > purpose > to have

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

Tom Lane <[EMAIL PROTECTED]> writes: > Qingqing Zhou <[EMAIL PROTECTED]> writes: > > I revised the idea with MINIMAL XLOG (instead of WITHOUT XLOG) like the > > below. I think in this way, we can always gaurantee its correctness and > > can always improve it. > > I think the entire idea is a was

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

On Fri, 23 Dec 2005, Tom Lane wrote: > Qingqing Zhou <[EMAIL PROTECTED]> writes: > > I revised the idea with MINIMAL XLOG (instead of WITHOUT XLOG) like the > > below. I think in this way, we can always gaurantee its correctness and > > can always improve it. > > I think the entire idea is a wast

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

Qingqing Zhou <[EMAIL PROTECTED]> writes: > I revised the idea with MINIMAL XLOG (instead of WITHOUT XLOG) like the > below. I think in this way, we can always gaurantee its correctness and > can always improve it. I think the entire idea is a waste of time anyway. If we have the COPY case covere

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

> > Torn pages (partial page write) are still a problem. I revised the idea with MINIMAL XLOG (instead of WITHOUT XLOG) like the below. I think in this way, we can always gaurantee its correctness and can always improve it. To Use It -- A "BEGIN TRANSACTION MINIMAL XLOG/END" block is a

Re: [HACKERS] [PATCHES] default resource limits

Tom Lane wrote: daveg <[EMAIL PROTECTED]> writes: I don't understand the motivation for so many connections by default, it seems wasteful in most cases. I think Andrew is thinking about database-backed Apache servers ... Some quick checks say that CVS tip's demand for shared memory

Re: [HACKERS] PLs and domain constraints

Neil Conway <[EMAIL PROTECTED]> writes: > For #2, I'm not sure where the right place to check domain constraints > is. I was thinking about adding the check to the fmgr function call > logic[1], but the domain checking code needs an ExprContext in which to > evaluate the constraint, which wouldn

[HACKERS] PLs and domain constraints

I'd like to take a look at fixing the fact that procedural languages do not check the constraints associated with domain types. I think there are two separate issues: (1) In PL/PgSQL, we need to check domain constraints whenever we assign a new value to a variable of a domain type. (2) When

Re: [HACKERS] Questions related to xlog

On Fri, 23 Dec 2005, Tom Lane wrote: > > Yeah, the non-transaction-controlled distinction is really not very > useful. I believe Vadim put it in originally because he wanted to go to > a REDO/UNDO approach, in which it would've been important to tell the > difference, but we never did that (and

Re: [HACKERS] Questions related to xlog

Qingqing Zhou <[EMAIL PROTECTED]> writes: > (1) > In RecordTransactionCommit(): > * (If it made no transaction-controlled XLOG entries, its XID appears > * nowhere in permanent storage > We have this in XLogInsert(): > /* Insert record header */ > record->xl_xid = GetCurren

Re: [HACKERS] Oracle PL/SQL Anonymous block equivalent in postgres

It's implemented in the server with extensions for psql to support it.On 12/23/05, Bruce Momjian wrote:Jonah H. Harris wrote:> I know this is a tech forum and as such, I don't generally plug products too > much.  However, EnterpriseDB has anonymous PL/SQL if you need it.In

Re: [HACKERS] Oracle PL/SQL Anonymous block equivalent in postgres

Jonah H. Harris wrote: > I know this is a tech forum and as such, I don't generally plug products too > much. However, EnterpriseDB has anonymous PL/SQL if you need it. Interesting. The posting is certainly appropriate. I know Command Prompt and GreenPlum have been using this "loophole". :-)

[HACKERS] Questions related to xlog

I have several questions in understanding xlog code: (1) In RecordTransactionCommit(): * (If it made no transaction-controlled XLOG entries, its XID appears * nowhere in permanent storage We have this in XLogInsert(): /* Insert record header */ record->xl_xid =

Re: [HACKERS] where is the output

On Fri, Dec 23, 2005 at 02:19:09PM +0100, ohp@pyrenet.fr wrote: > But I'd still like to know in that case (the same goes for C I guess) > where stdout is. > Why isn't it connected by default to the input of whatever connected by > dbconnect? >From the COPY documentation: When STDIN or STDOUT

[HACKERS] Fixing row comparison semantics

I've gotten interested again in the issue of row comparisons, eg (a, b, c) >= (1, 2, 3) We've discussed this before, the most comprehensive thread being http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php but nothing's gotten done. Unless someone's already working on this

Re: [HACKERS] postmaster and postgres options assimilation

Peter Eisentraut <[EMAIL PROTECTED]> writes: > -S > postmaster: silent mode > postgres: work_mem > Renaming the postgres side of -N, -o, -p, and -s might not really do > any harm, but the -S option used to be very popular on the postgres > command-line via -o from the postmaster, so I'm af

[HACKERS] postmaster and postgres options assimilation

I've looked at the issue of assimilating the options of postmaster and postgres, which has been mentioned now and then over the years. Basically, we have five conflict cases that need to be resolved by breaking one or the other, namely: -N postmaster: max_connections postgres: do not e

Re: [HACKERS] kerberos/SSPI (was: Client-side password encryption)

> > ODBC and Kerberos works just fine, if you use the 8.1 ODBC > driver. I > > use it all the time :) > > That's what I had heard, I just havn't gotten it working yet > myself. :) Believe me when I say that I *really* want to have > it working though; this postgres->pam->libpam-krb5 nonsense

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

* Magnus Hagander ([EMAIL PROTECTED]) wrote: > ODBC and Kerberos works just fine, if you use the 8.1 ODBC driver. I use > it all the time :) That's what I had heard, I just havn't gotten it working yet myself. :) Believe me when I say that I *really* want to have it working though; this postgres->

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

-Original Message- From: Stephen Frost [mailto:[EMAIL PROTECTED] Sent: Fri 12/23/2005 2:42 PM To: Martijn van Oosterhout Cc: Greg Stark; Tom Lane; Christopher Kings-Lynne; Andrew Dunstan; Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas Pflug; Dave Page Subject: Re: [HACKERS] [pg

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

> There's also Kerberos, which I'm happy to say seems to be > getting more and more use. I'd really like to get ODBC > Kerberos working, at least with MIT kerberos and then maybe > someday (if I can manage to get it > working...) setup some cross-realm stuff with the Windows AD and SSPI > (iir

[HACKERS] Spaces in directory names

There are some TODO items about allowing spaces in directory names in various places. I spent the connection-less time on the train today experimenting with several scenarios. This is the status: Installing into a directory containing spaces in names works as of a CVS head a few weeks ago. T

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

Stephen Frost wrote: Is it actually doing challenge-response where the challenge is different each time? The docs say: AuthenticationMD5Password The frontend must now send a PasswordMessage containing the password encrypted via MD5, using the 4-character salt specified in the

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

* Martijn van Oosterhout (kleptog@svana.org) wrote: > On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote: > > * Martijn van Oosterhout (kleptog@svana.org) wrote: > > > This isn't the first time this has been explained, but: > > > > > > With password encryption you essentially have two o

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote: > * Martijn van Oosterhout (kleptog@svana.org) wrote: > > This isn't the first time this has been explained, but: > > > > With password encryption you essentially have two options: > > > > - Server knows password, use challenge-respon

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

On 23 Dec 2005 09:12:52 -0500, Greg Stark <[EMAIL PROTECTED]> wrote: > > Tom Lane <[EMAIL PROTECTED]> writes: > > > 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 v

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

* Martijn van Oosterhout (kleptog@svana.org) wrote: > On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote: > > Eh? Just because you know everything the postmaster does doesn't mean you > > can't be stopped. In the traditional unix password file scheme the crypt > > string is public knowledge

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote: > Eh? Just because you know everything the postmaster does doesn't mean you > can't be stopped. In the traditional unix password file scheme the crypt > string is public knowledge but it's not enough to log in. You need the > original pass

Re: [HACKERS] [pgadmin-hackers] Client-side password encryption

Tom Lane <[EMAIL PROTECTED]> writes: > 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 pa

Re: [HACKERS] Oracle PL/SQL Anonymous block equivalent in postgres

I know this is a tech forum and as such, I don't generally plug products too much.  However, EnterpriseDB has anonymous PL/SQL if you need it. On 12/22/05, Bruce Momjian wrote: Wow, that is large.  I think PL/pgSQL is your best approach.  Irecommend you create a schema that

Re: [HACKERS] where is the output

On Wed, 21 Dec 2005, Michael Fuhr wrote: > Date: Wed, 21 Dec 2005 13:23:24 -0700 > From: Michael Fuhr <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: pgsql-hackers list > Subject: Re: [HACKERS] where is the output > > On Wed, Dec 21, 2005 at 07:16:28PM +0100, ohp@pyrenet.fr wrote: > > Not sure it'

Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and

On Thu, 2005-12-22 at 17:36 -0500, Stephen Frost wrote: > * 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