Re: [HACKERS] 2PC-induced lockup

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 11, 2007 at 12:38:09AM -0400, Tom Lane wrote: > [EMAIL PROTECTED] writes: [...] > > It might make sense then to clear the pg_twophase directory on DB > > startup. > > I fear you have 100% misunderstood the point. The *only* > reason for

Re: [HACKERS] Bgwriter strategies

In the last couple of days, I've been running a lot of DBT-2 tests and smaller microbenchmarks with different bgwriter settings and experimental patches, but I have not been able to produce a repeatable test case where any of the bgwriter configurations perform better than not having bgwriter a

Re: [HACKERS] Bgwriter strategies

On 7/11/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: I was able to reproduce the phenomenon with a simple C program that writes 8k blocks in random order to a fixed size file. I've attached it along with output of running it on my test server. The output shows how the writes start to period

Re: [HACKERS] Bgwriter strategies

Pavan Deolasee escribió: > On 7/11/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > > >I was able > >to reproduce the phenomenon with a simple C program that writes 8k > >blocks in random order to a fixed size file. I've attached it along with > >output of running it on my test server. The out

[HACKERS] doubt

Does postgreSQL support distributive query processing - Get the freedom to save as many mails as you wish. Click here to know how.

Re: [HACKERS] 2PC-induced lockup

[EMAIL PROTECTED] writes: > On Wed, Jul 11, 2007 at 12:38:09AM -0400, Tom Lane wrote: >> [EMAIL PROTECTED] writes: > [...] >> > It might make sense then to clear the pg_twophase directory on DB >> > startup. >> >> I fear you have 100% misunderstood the point. The *only* >> reason for that featu

Re: [HACKERS] Bgwriter strategies

"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > I think you are assuming that the next write of the same block won't > use another OS cache block. I doubt if thats the way writes are handled > by the kernel. Each write would typically end up being queued up in the > kernel > where each write will ha

Re: [HACKERS] 2PC-induced lockup

On Wed, Jul 11, 2007 at 10:43:23AM -0400, Chris Browne wrote: > The right resolution to this is not, a priori, evident yet. _A posteriori_, though, it seems to me the right resolution is "don't do that" ;-) A -- Andrew Sullivan | [EMAIL PROTECTED] Users never remark, "Wow, this software may be

Re: [HACKERS] PQescapeBytea* version for parameters

"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Do we want something like this which provides a PQescapeByteaParam for >> escaping bytea strings before passing them as text-mode parameters in >> PQexecParam? > > Seems a lot easier and more efficient to just pa

[HACKERS] minor compiler warning on OpenBSD

while looking at some other stuff I noticed that we have the following compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -DFRONTEND -I../../../src/interfaces/libpq -I../../../src/incl

Re: [HACKERS] 2PC-induced lockup

Chris Browne wrote: If one locks certain vital system resources, as part of that PREPAREd transaction, that evidently causes some problems, alas... The right resolution to this is not, a priori, evident yet. It's not? I agree with Tom here; this is just one of the numerous things you can do t

Re: [HACKERS] PQescapeBytea* version for parameters

Gregory Stark <[EMAIL PROTECTED]> writes: > Shouldn't it escape ' as \' and not '' if standard_conforming_strings is > false? No. That's always worked and there's no reason to change it. regards, tom lane ---(end of broadcast)-

Re: [HACKERS] minor compiler warning on OpenBSD

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > while looking at some other stuff I noticed that we have the following > compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler: > initdb.c:2187: warning: `%x' yields only last 2 digits of year in some > locales Yeah, mine complains a

Re: [HACKERS] doubt

Narasimha Rao P.A wrote: Does postgreSQL support distributive query processing No. Get the freedom to save as many mails as you wish. Click here to know how. -- === The

Re: [HACKERS] PQescapeBytea* version for parameters

Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > Shouldn't it escape ' as \' and not '' if standard_conforming_strings is > > false? > > No. That's always worked and there's no reason to change it. '' is more standard than \' so we always use ''. -- Bruce Momjian <[EMAIL PROT

[HACKERS] Need help with autoconf

Hi! I'm trying to write an autoconf macro to figure out if the function krb5_free_unparsed_name exists (because it exists in MIT but not Heimdal), to fix a rather nasty bug in our Kerberos implementation. However, I'm failing :( I'm simply using AC_CHECK_FUNC([krb5_free_unparsed_name]) which wo

Re: [HACKERS] Need help with autoconf

Magnus Hagander <[EMAIL PROTECTED]> writes: > I'm simply using > AC_CHECK_FUNC([krb5_free_unparsed_name]) > which works fine on unix, but breaks on win32. Because autoconf tries the > function with no parameters, which doesn't work due to win32 decorations. Doesn't work why? We have dozens of oth

Re: [HACKERS] 2PC-induced lockup

On Wed, Jul 11, 2007 at 04:44:12PM +0100, Heikki Linnakangas wrote: > FWIW, deleting the files from pg_twophase is safe when the system is > shut down. Is it safe for the PREPAREd TRANSACTIONs? I assume not. That is, in Peter's presumably experimental case, it might be ok to delete the files, b

Re: [HACKERS] 2PC-induced lockup

Andrew Sullivan wrote: On Wed, Jul 11, 2007 at 04:44:12PM +0100, Heikki Linnakangas wrote: FWIW, deleting the files from pg_twophase is safe when the system is shut down. Is it safe for the PREPAREd TRANSACTIONs? I assume not. That is, in Peter's presumably experimental case, it might be ok

Re: [HACKERS] Need help with autoconf

Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> I'm simply using >> AC_CHECK_FUNC([krb5_free_unparsed_name]) >> which works fine on unix, but breaks on win32. Because autoconf tries the >> function with no parameters, which doesn't work due to win32 decorations. > > Doesn't work w

Re: [HACKERS] Need help with autoconf

Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Magnus Hagander <[EMAIL PROTECTED]> writes: >>> I'm simply using >>> AC_CHECK_FUNC([krb5_free_unparsed_name]) >>> which works fine on unix, but breaks on win32. Because autoconf tries the >>> function with no parameters, which doesn't

Re: [HACKERS] 2PC-induced lockup

On Wed, Jul 11, 2007 at 06:15:12PM +0100, Heikki Linnakangas wrote: > It's effectively the same as manually issuing a ROLLBACK PREPARED. It > will brake the atomicity of the global transaction, if some branches of > that global transaction in other resource managers have already been > committed

Re: [HACKERS] 2PC-induced lockup

Heikki Linnakangas wrote: > It's not? I agree with Tom here; this is just one of the numerous > things you can do to screw up your database as a superuser. Why would > you LOCK the pg_auth table, or any other system table for that > matter, in the first place? Let alone in a distributed transaction

Re: [HACKERS] 2PC-induced lockup

Peter Eisentraut wrote: Heikki Linnakangas wrote: It's not? I agree with Tom here; this is just one of the numerous things you can do to screw up your database as a superuser. Why would you LOCK the pg_auth table, or any other system table for that matter, in the first place? Let alone in a dist

Re: [HACKERS] 2PC-induced lockup

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> Heikki Linnakangas wrote: >>> It's not? I agree with Tom here; this is just one of the numerous >>> things you can do to screw up your database as a superuser. Why would >>> you LOCK the pg_auth table, or any other system t

Re: [HACKERS] 2PC-induced lockup

Andrew Sullivan <[EMAIL PROTECTED]> writes: > On Wed, Jul 11, 2007 at 06:15:12PM +0100, Heikki Linnakangas wrote: >> It's effectively the same as manually issuing a ROLLBACK PREPARED. > But how do you know which file to delete? You don't. In extremis you could probably throw together some inspec

Re: [HACKERS] 2PC-induced lockup

Heikki Linnakangas wrote: > Why does the application LOCK pg_auth? It does it with NOWAIT to determine if some other connection had already locked it (because it was modifying some roles) in order not to lock up the program. This (or something like it, because this doesn't work, after all) is

Re: [HACKERS] 2PC-induced lockup

Andrew Sullivan wrote: On Wed, Jul 11, 2007 at 06:15:12PM +0100, Heikki Linnakangas wrote: It's effectively the same as manually issuing a ROLLBACK PREPARED. It will brake the atomicity of the global transaction, if some branches of that global transaction in other resource managers have alread

Re: [HACKERS] 2PC-induced lockup

On Wed, Jul 11, 2007 at 09:26:34PM +0100, Heikki Linnakangas wrote: > > The xid is encoded in the filename. If you can't start up the database > and look at pg_locks, you can't do much other than guess. So then in this sort of case, it isn't _really_ safe to delete those files, because the commi

Re: [HACKERS] minor compiler warning on OpenBSD

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> while looking at some other stuff I noticed that we have the following >> compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler: >> initdb.c:2187: warning: `%x' yields only last 2 digits of year in some >> locales >

Re: [HACKERS] "Running readonly queried on PITR slaves" statusupdate

On Tue, 2007-07-10 at 02:41 +0200, Florian G. Pflug wrote: > After struggling with understanding xlog.c and friends far enough to > be able to refactor StartupXLOG to suit the needs of concurrent recovery, > I think I've finally reached a workable (but still a bit hacky) solution. Sounds like gre

Re: [HACKERS] 2PC-induced lockup

Andrew Sullivan wrote: On Wed, Jul 11, 2007 at 09:26:34PM +0100, Heikki Linnakangas wrote: The xid is encoded in the filename. If you can't start up the database and look at pg_locks, you can't do much other than guess. So then in this sort of case, it isn't _really_ safe to delete those files

Re: [HACKERS] 2PC-induced lockup

On Tue, 2007-07-10 at 10:41 -0400, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > The following command sequence appears to lock up the database system: > > BEGIN; > > LOCK pg_authid; > > PREPARE TRANSACTION 'foo'; > > \q > > > After that you can't connect anymore, even in sing

Re: [HACKERS] 2PC-induced lockup

On Wed, 2007-07-11 at 22:33 +0100, Heikki Linnakangas wrote: > Andrew Sullivan wrote: > > On Wed, Jul 11, 2007 at 09:26:34PM +0100, Heikki Linnakangas wrote: > >> The xid is encoded in the filename. If you can't start up the database > >> and look at pg_locks, you can't do much other than guess. >

Re: [HACKERS] [GENERAL] Count(*) throws error

On Wed, 2007-07-11 at 17:42 -0400, Tom Lane wrote: > "Jasbinder Singh Bali" <[EMAIL PROTECTED]> writes: > > I'm using the following statement in my plpgsql function > > > SELECT INTO no_rows COUNT(*) FROM tbl_concurrent; > > > I have decalred no_rows int4 and initialized it to zero > > > Running

Re: [HACKERS] 2PC-induced lockup

"Simon Riggs" <[EMAIL PROTECTED]> writes: > I'd be much more comfortable if LOCK TABLE caused a message to the log > if it is executed on any system table. Enabled by "set training_wheels = on", perhaps? This is really pretty silly to be getting worked up about. The command in question wouldn't

Re: [HACKERS] [GENERAL] Count(*) throws error

"Simon Riggs" <[EMAIL PROTECTED]> writes: > Seems like we could be slightly more friendly without too much bother: > at least only substitute after the VALUES clause in INSERT. Surely you jest. regards, tom lane ---(end of broadcast)---

Re: [HACKERS] minor compiler warning on OpenBSD

Stefan Kaltenbrunner wrote: > Tom Lane wrote: > > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >> while looking at some other stuff I noticed that we have the following > >> compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler: > >> initdb.c:2187: warning: `%x' yields only last

Re: [HACKERS] doubt

On Wed, 11 Jul 2007, Narasimha Rao P.A wrote: Does postgreSQL support distributive query processing Not internally. It's possible in some situations to split queries up across multiple nodes using add-on software. pgpool-II, available at http://pgfoundry.org/projects/pgpool/ provides an im

Re: [HACKERS] minor compiler warning on OpenBSD

Alvaro Herrera <[EMAIL PROTECTED]> writes: > My local manpage for strftime says that we can get around this warning > by overloading it with something like > size_t > my_strftime(char *s, size_t max, const char *fmt, > const struct tm *tm) > { > return strftime(s, max, fmt, tm); >

Re: [HACKERS] [GENERAL] Count(*) throws error

"Simon Riggs" <[EMAIL PROTECTED]> writes: > Seems like we could be slightly more friendly without too much bother: Actually, rather than get into that sort of AI-complete project, it strikes me that the most useful response is user education. There ought to be a section in the plpgsql documentati

[HACKERS] "tuple concurrently updated" during index deletion

On cvs head, I can get "tuple concurrently updated" if two separate transactions are both trying to drop the same index: 8< contrib_regression=# create table t(f1 int); CREATE TABLE contrib_regression=# create index idx1 on t(f1); CREATE INDEX contrib_regre

Re: [HACKERS] "tuple concurrently updated" during index deletion

Joe Conway <[EMAIL PROTECTED]> writes: > On cvs head, I can get "tuple concurrently updated" if two separate > transactions are both trying to drop the same index: This seems related to the discussions we had awhile back about how deletion needs to take locks *before* it starts doing anything. ht

Re: [HACKERS] "tuple concurrently updated" during index deletion

On 7/11/07, Tom Lane <[EMAIL PROTECTED]> wrote: Notice that recursiveDeletion() tries to clean out pg_depend before it actually deletes the target object, and in the current code that object-specific subroutine is the only thing that takes any sort of lock. In the past 4-6 months, we've seen 4

Re: [HACKERS] 2PC-induced lockup

Tom Lane wrote: "Simon Riggs" <[EMAIL PROTECTED]> writes: I'd be much more comfortable if LOCK TABLE caused a message to the log if it is executed on any system table. Enabled by "set training_wheels = on", perhaps? This is really pretty silly to be getting worked up about. The command in qu