WIP csv logs

Started by Andrew Dunstanabout 19 years ago5 messagespatches
Jump to latest
#1Andrew Dunstan
andrew@dunslane.net

Attached is my WIP version of the CSV logs patch. It does not include
docs changes.

It fixes the CSV thinko I just posted about, and also implements the
"safe to rotate" scheme I suggested yesterday, at quite a modest cost.
As Tom rightly points out, that does not protect us against interleaving
log lines from different backends, which is an open problem. It does
however protect against rotating in the middle of a log line. It also
incorporates the fix I made two days ago to remove inappropriate Windows
CRLF translation, and some code tidying.

cheers

andrew

Attachments:

csvlog-3.patchtext/x-patch; name=csvlog-3.patchDownload+1011-540
#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Andrew Dunstan (#1)
Re: WIP csv logs

Andrew Dunstan wrote:

Attached is my WIP version of the CSV logs patch. It does not include
docs changes.

It fixes the CSV thinko I just posted about, and also implements the
"safe to rotate" scheme I suggested yesterday, at quite a modest cost.
As Tom rightly points out, that does not protect us against interleaving
log lines from different backends, which is an open problem.

I wonder, if we were to use an LWLock to protect writing to the stderr
pipe, would it be too contentious?

--
Alvaro Herrera Valdivia, Chile ICBM: S 39� 49' 18.1", W 73� 13' 56.4"
"El destino baraja y nosotros jugamos" (A. Schopenhauer)

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Alvaro Herrera (#2)
Re: WIP csv logs

Alvaro Herrera wrote:

Andrew Dunstan wrote:

Attached is my WIP version of the CSV logs patch. It does not include
docs changes.

It fixes the CSV thinko I just posted about, and also implements the
"safe to rotate" scheme I suggested yesterday, at quite a modest cost.
As Tom rightly points out, that does not protect us against interleaving
log lines from different backends, which is an open problem.

I wonder, if we were to use an LWLock to protect writing to the stderr
pipe, would it be too contentious?

That was the first thing I wanted to try. I'll code it up and then
people can test to see if we get a significant performance hit.

cheers

andrew

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#2)
Re: WIP csv logs

Alvaro Herrera <alvherre@commandprompt.com> writes:

I wonder, if we were to use an LWLock to protect writing to the stderr
pipe, would it be too contentious?

Sorry, that's a nonstarter.

1. Not all our processes are connected to shared memory. Even the ones
that are don't necessarily have PGPROCs.

2. If somebody crashes while holding the lock, the entire system
including the postmaster soon freezes up.

3. Having the postmaster take LWLocks is verboten anyway, mainly because
of problem #2.

regards, tom lane

#5Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#4)
Re: WIP csv logs

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

I wonder, if we were to use an LWLock to protect writing to the stderr
pipe, would it be too contentious?

Sorry, that's a nonstarter.

1. Not all our processes are connected to shared memory. Even the ones
that are don't necessarily have PGPROCs.

2. If somebody crashes while holding the lock, the entire system
including the postmaster soon freezes up.

3. Having the postmaster take LWLocks is verboten anyway, mainly because
of problem #2.

Ugh. Well, until this problem is solved I'm not prepared to commit a
patch that purports to provide machine readable logs. The only
non-locking solution I can think of is to have one set of pipes per
backend rather than one set per cluster. That could get pretty ugly,
though, and have all sorts of problems with portability.

I'm starting to wonder if the CSVlog patch needs to be put on hold at
least for 8.4. If we do, I think I should at least commit the piece that
prevents rotation in the middle of a line, and possible even backpatch it.

cheers

andrew